Yogesh Sahu (Backend-Associate Consultant L2- Development)

Understanding Account Abstraction on Ethereum for Smart Contract Wallets

A novel concept in blockchain, account abstraction aims to improve and harmonize user account functionality in decentralized systems. Contract wallets, also known as smart contract accounts, can replace traditional externally held accounts thanks to account abstraction and smart contract development. A contract wallet can be controlled by a single key, multiple keys, or even a complex system encoded into the contract itself. This opens up numerous possibilities and benefits for Ethereum and other blockchain networks. Account abstraction allows for more flexible and secure management of contract wallets compared to traditional externally held accounts. For more about blockchain, Ethereum, and smart contracts, visit our smart contract development services.

In the Ethereum network, two types of accounts currently exist:

Externally Owned Accounts (EOAs): controlled by private keys and typically of specific people or organizations.

Contract Accounts: smart contracts whose code is run according to predetermined logic.

Account abstraction seeks to unify the two types of Ethereum accounts:
 

This implies that smart contracts can now manage and carry out transactions on behalf of users rather than exclusively depending on private keys (as with EOAs), providing users with more flexibility and opening the door to new features like customizable security models, automated and gasless transactions, meta-transactions, and improved privacy. These developments streamline user interactions and increase the Ethereum ecosystem's potential.

Also, Read | How to Create an NFT Rental Marketplace using ERC 4907

Why do we need Account Abstraction ?

The current configuration of the Ethereum network has several drawbacks:

Security Risks: Due to their binary structure, private keys can be lost or stolen, which can result in an irreversible loss of money.
User Experience: For new users who could find wallet security and gas principles confusing, EOAs demand private keys and gas costs in Ether, which causes friction.Hazards to Security: Due to their binary structure, private keys can be lost or stolen, which can result in an irreversible loss of money.
Limited Features: Advanced features like multi-signature wallets and daily transaction restrictions cannot be implemented on EOAs due to their lack of programmability.

By addressing these problems, account abstraction seeks to enhance the functionality, security, and usability of the network.

Also, Read | A Guide to Implementing NFT Royalties on ERC-721 & ERC-1155

Approaches to Implement Account Abstraction:

Protocol-Level Changes

It entails modifying the Ethereum protocol to allow native wallets for smart contracts. Consensus is required for this strategy throughout the Ethereum network.

Layer 2 Solutions

Layer 2 networks provide the ability to offload transaction processing and implement unique transaction validation procedures.

ERC 4337 (Ethereum Request for Comments)

It suggests implementing account abstraction just at the application level, eliminating the need for protocol modifications.

Also, Read | How to Create and Deploy a Token Bound Account | ERC-6551

What is ERC 4337?

A new transaction handling mechanism called UserOperation objects is introduced in ERC 4337. By signing UserOperation objects, which bundlers aggregate and transmit to the network, users avoid submitting transactions straight to the Ethereum blockchain. Without relying on the current transaction flow, this method enables smart contract wallets to safely start transactions.  

Implementation of ERC 4337:

A number of essential elements are involved in the Solidity implementation of ERC 4337 (Account Abstraction), which combined allow for flexible and intuitive interactions with smart contracts. These are the primary elements to pay attention to:

1. UserOperation Struct

Purpose: Represents a single user operation with all necessary information.
  
Key Fields:

sender: The address of the user or wallet executing the operation.
nonce: To prevent replay attacks and track the order of operations.
callData: The encoded data for the function call.
gasLimit: The maximum amount of gas that can be used for the operation.
maxFeePerGas & maxPriorityFeePerGas: Control over gas fees.

You may also like | How to Create an ERC 721C Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract UserOperationExample {
    
    struct UserOperation {
        address sender;            // Address of the user sending the operation
        uint256 nonce;            // Unique nonce to prevent replay attacks
        bytes callData;           // Encoded data for the function call
        uint256 gasLimit;         // Maximum gas limit for the operation
        uint256 maxFeePerGas;     // Maximum fee per gas unit the user is willing to pay
        uint256 maxPriorityFeePerGas; // Max priority fee per gas
    }

    // Example function to demonstrate the use of UserOperation
    function exampleFunction(UserOperation calldata userOp) external {
        // Validate the user operation (you would typically check nonce, gas limits, etc.)
        require(userOp.sender != address(0), "Invalid sender");
        require(userOp.gasLimit > 0, "Gas limit must be greater than zero");

        // Here you would implement the logic to execute the operation
        (bool success, ) = userOp.sender.call{gas: userOp.gasLimit}(userOp.callData);
        require(success, "Operation failed");
        
        // You could also emit an event here for tracking purposes
    }
}

Also, Discover | How to Create and Deploy an ERC404 token contract

2. EntryPoint Contract

Purpose: Central contract that receives user operations and executes them.
  

Key Functions:
 

executeUserOperation: Validates and executes the user operation, checking the sender's nonce, ensuring gas limits, and processing the call data.
Security Checks: Implement checks to prevent issues like underflow/overflow, invalid addresses, and ensure gas payment.
 

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract EntryPoint {
    event UserOperationExecuted(address indexed sender, bytes callData);
    event UserOperationFailed(address indexed sender, bytes callData, string reason);

    // This mapping tracks the nonce for each user to prevent replay attacks
    mapping(address => uint256) public nonces;

    function executeUserOperation(UserOperation calldata userOp) external {
        // Validate the user operation
        require(userOp.sender != address(0), "Invalid sender");
        require(userOp.nonce == nonces[userOp.sender], "Invalid nonce");
        require(userOp.gasLimit > 0, "Gas limit must be greater than zero");

        // Update the nonce
        nonces[userOp.sender]++;

        // Execute the operation
        (bool success, bytes memory returnData) = userOp.sender.call{gas: userOp.gasLimit}(userOp.callData);

        if (success) {
            emit UserOperationExecuted(userOp.sender, userOp.callData);
        } else {
            emit UserOperationFailed(userOp.sender, userOp.callData, _getRevertMsg(returnData));
        }
    }

    // Helper function to extract revert reason
    function _getRevertMsg(bytes memory returnData) internal pure returns (string memory) {
        if (returnData.length < 68) return "Transaction reverted silently";
        assembly {
            returnData := add(returnData, 0x04)
        }
        return abi.decode(returnData, (string));
    }
}

Also, Discover | ERC 3643 A Protocol for Real World Asset Tokenization

3. User Wallet Contract

Purpose: Acts as the user's wallet to create and submit user operations.

Key Functions:

submitUserOperation: Collects user operation parameters and sends them to the Entry Point.
Nonce Management: Increments the nonce after a successful operation to prevent replay attacks.
 

	// SPDX-License-Identifier: MIT
	pragma solidity ^0.8.0;

	import "./EntryPoint.sol"; // Import the EntryPoint contract

	contract UserWallet {
    	address public entryPoint; // Address of the EntryPoint contract
    	uint256 public nonce; // Nonce for tracking user operations

    	constructor(address _entryPoint) {
        entryPoint = _entryPoint; // Set the EntryPoint contract address
    	}

    	// Function to submit a user operation
    	function submitUserOperation(
        	bytes calldata callData,
        	uint256 gasLimit,
        	uint256 maxFeePerGas,
        	uint256 maxPriorityFeePerGas
   	 ) external {
        // Create the UserOperation struct
        UserOperation memory userOp = UserOperation({
            sender: address(this),
            nonce: nonce,
            callData: callData,
            gasLimit: gasLimit,
            maxFeePerGas: maxFeePerGas,
            maxPriorityFeePerGas: maxPriorityFeePerGas
        });

        // Submit the user operation to the Entry Point
        EntryPoint(entryPoint).executeUserOperation(userOp);
        
        // Increment the nonce for the next operation
        nonce++;
    }

    // Example function to demonstrate a callable function from the wallet
    function exampleFunction(uint256 value) external {
        // Implementation of the function logic
    }
}

Also, Check | A Guide to Gasless ERC20 Token Transfer

4. Gas Payment Mechanism
 

Purpose: Determines how the gas for executing user operations is paid.
 

Considerations:
 

You might want to allow users to pay gas fees in tokens or implement a mechanism for sponsor payments (where another entity pays the gas).
 

	// SPDX-License-Identifier: MIT
	pragma solidity ^0.8.0;

	import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

	contract EntryPoint {
    	event UserOperationExecuted(address indexed sender, bytes callData);
    	event UserOperationFailed(address indexed sender, bytes callData, string reason);

    	mapping(address => uint256) public nonces;

    	// Function to execute user operation with gas payment
    	function executeUserOperation(
        UserOperation calldata userOp,
        address paymentToken,
        uint256 paymentAmount
    	) external payable {
        require(userOp.sender != address(0), "Invalid sender");
        require(userOp.nonce == nonces[userOp.sender], "Invalid nonce");
        require(userOp.gasLimit > 0, "Gas limit must be greater than zero");

        // Validate gas payment
        if (paymentToken == address(0)) {
            // Pay with Ether
            require(msg.value >= paymentAmount, "Insufficient Ether sent");
        } else {
            // Pay with ERC-20 token
            require(IERC20(paymentToken).transferFrom(msg.sender, address(this), paymentAmount), "Token transfer failed");
        }

        nonces[userOp.sender]++;

        (bool success, bytes memory returnData) = userOp.sender.call{gas: userOp.gasLimit}(userOp.callData);

        if (success) {
            emit UserOperationExecuted(userOp.sender, userOp.callData);
        } else {
            emit UserOperationFailed(userOp.sender, userOp.callData, _getRevertMsg(returnData));
        }
    }

    function _getRevertMsg(bytes memory returnData) internal pure returns (string memory) {
        if (returnData.length < 68) return "Transaction reverted silently";
        assembly {
            returnData := add(returnData, 0x04)
        }
        return abi.decode(returnData, (string));
    }
}

5. Account Abstraction Wallet
 

Purpose:
 

To manage user actions, an Entry Point contract communicates with the Abstracted Account Wallet, which functions as a user-defined wallet. By offering a means of verifying and carrying out these procedures, it guarantees that activities may only be carried out by authorized users.
 

   // SPDX-License-Identifier: UNLICENSED
   pragma solidity ^0.8.9;

   import "./library/UserOperation.sol";
   import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

   contract AbstractedAccountWallet {

    using ECDSA for bytes32;

    uint256 public constant SIG_VALIDATION_FAILED = 1;
    uint256 public constant NONCE_VALIDATION_FAILED = 2;
    uint256 public constant VALIDATION_SUCCESS = 0;

    address public owner;
    uint256 public nonce;
    address public entryPoint;

    // Events for logging important actions
    event ExecutedOperation(address indexed sender, uint256 value, bytes data);

    constructor(address _entryPoint) {
        owner = msg.sender;
        nonce = 0;
        entryPoint = _entryPoint;
    }

    // Modifier to check if the caller is the owner of the contract
    modifier onlyOwner() {
        require(msg.sender == owner, "You are not the owner");
        _;
    }

    modifier onlyEntryPoint() {
        require(
            msg.sender == entryPoint,
            "Only EntryPoint can call this function"
        );
        _;
    }

    // Function to validate a user-defined operation
    function validateOp(
        UserOperation calldata op,
        uint256 requiredPayment
    ) public returns (uint256) {
        // Send requiredPayment to EntryPoint
        if (requiredPayment != 0) {
            payable(entryPoint).transfer(requiredPayment);
        }

        // Check nonce
        require(op.nonce == nonce++, "Invalid nonce");

        // Check signature
        if (
            owner !=
            getHash(op).toEthSignedMessageHash().recover(
                // op.signature[32:]

                op.signature
            )
        ) {
            return SIG_VALIDATION_FAILED;
        } else {
            // return uint256(bytes32(op.signature[0:32]));
            return VALIDATION_SUCCESS;
        }
    }

 
    function getHash(
        UserOperation memory userOp
    ) public view returns (bytes32) {
        return
            keccak256(
                abi.encode(
                    bytes32(block.chainid),
                    userOp.sender,
                    userOp.nonce,
                    keccak256(userOp.initCode),
                    keccak256(userOp.callData),
                    userOp.callGasLimit,
                    userOp.verificationGasLimit,
                    userOp.preVerificationGas,
                    userOp.maxFeePerGas,
                    userOp.maxPriorityFeePerGas,
                    keccak256(userOp.paymasterAndData),
                    entryPoint
                    // uint256(bytes32(userOp.signature[0:32]))
                )
            );
    }
}

You may also like | How to Create an ERC 721 NFT Token

A recent breakthrough: EIP-4337
 

Since the account abstraction effort moved to a different strategy, which was unveiled in EIP-4337 in late 2021, both EIP-2938 and EIP-3074 are presently dormant. Building on the idea of a smart contract wallet is the goal of the new strategy.

However, remember that we already mentioned that the lack of proper infrastructure makes smart contract wallets challenging to use? Nevertheless, EIP-4337 seeks to address that without altering the L1 protocol in the process.

The proposal introduces a higher-level mempool that operates with a new object called UserOperations. Instead of traditional transactions, users will send UserOperations to this mempool. Validators then select these UserOperations, bundle them into a transaction, and submit them to a specialized smart contract called the EntryPoint contract. This contract manages transaction execution and validator rewards.

The method outlined in EIP-4337 simplifies the process for developers to create custom smart contract wallets.

Also, Know | Create a Simple Dividend ERC20 token

Conclusion of Account Abstraction Using ERC 4337:
 

Account abstraction and ERC 4337 are two progressive approaches to Ethereum's development. This strategy is well-positioned to promote the wider use of blockchain technology and decentralised apps by giving priority to user experience, flexibility, and security, so making them more accessible and useful for regular users. The ideas and applications resulting from ERC 4337 will probably influence the direction of decentralised finance in the future and beyond as the ecosystem develops. In case you are looking to build your project using emerging ERC standards, connect without our skilled Solidity developers to get started. 

In the world of decentralized finance (DeFi), yield-bearing vaults have become a popular mechanism for users to earn passive income on their crypto assets. These vaults typically involve the pooling of funds, which are then deployed into various DeFi protocols to generate yields. In this tutorial, we'll explore how to build an ERC-4626 token contract for such yield-bearing vaults. For more things related to DeFi, explore our deFi development services

Understanding ERC-4626:
 

ERC-4626 is a proposed standard for yield-bearing tokens in Ethereum, introduced to address the specific needs of tokens associated with yield-generating strategies. Unlike traditional ERC-20 tokens, ERC-4626 tokens are designed to represent ownership in a yield-bearing vault and may entitle holders to a share of the yields generated by the underlying assets.

Also, Read | A Comprehensive Guide to ERC-6551 Token Standard

Prerequisites:
 

Before diving into the implementation, make sure you have a basic understanding of Solidity, Ethereum smart contracts, and the ERC-20 token standard. You should also be familiar with concepts related to DeFi, such as liquidity provision, yield farming, and smart contract security.

Implementation:
 

We'll start by outlining the key features of our ERC-4626 token contract:

ERC-20 Compatibility: Our contract will extend the ERC-20 standard, allowing it to interact seamlessly with existing Ethereum wallets and decentralized exchanges (DEXs).

Vault Management: We'll incorporate functionality to allow a designated manager to control the vault's operations, including depositing and withdrawing assets, as well as updating parameters such as the yield-generating strategy.

Deposit and Withdrawal: Users should be able to deposit their assets into the vault to participate in yield generation and withdraw their holdings at any time.

Yield Generation: While the specifics of yield generation will vary depending on the chosen strategy, our contract will provide hooks for integrating with external DeFi protocols or custom logic.

You may also like | ERC-1155 | An Introduction to Multi Token Standard Development

//SPDX-License-Identifier: MIT
pragma solidity 0.8.7;
import "https://github.com/Rari-Capital/solmate/blob/main/src/tokens/ERC20.sol";

interface IERC20{
   function transferFrom(address A, address B, uint C) external view returns(bool);
   function approve() external view returns(uint256);
   function decimals() external view returns(uint256);
   function totalSupply() external view returns(uint256);
   function balanceOf(address account) external view returns(uint256);
   function transfer(address D, uint amount) external ;
}

interface IERC4626 { 
   function totalAssets() external view returns (uint256); 
}

contract vault is IERC4626, ERC20 {

   event Deposit(address caller, uint256 amt);
   event Withdraw(address caller, uint256 amt, uint256 per);
   ERC20 public immutable  token;
   
   mapping(address => uint256) shareHolder;
   constructor(ERC20 _token, string memory _name, string memory _symbol )
    ERC20(_name, _symbol, 18) {
       token = _token;
   }
   
   function deposit(uint256 _amount) public{
       require (_amount > 0, "Deposit less than Zero");
       token.transferFrom(msg.sender, address(this), _amount);
       shareHolder[msg.sender] += _amount;
       _mint(msg.sender, _amount);
       emit Deposit(msg.sender,  _amount);
   }

   function totalAssets() public view override returns(uint256) {
       return token.balanceOf(address(this));
   }    
   
   function redeem(uint256 _amount, address receiver ) internal  returns (uint256 assets) {
       require(shareHolder[msg.sender] > 0, "Not a share holder");
       shareHolder[msg.sender] -= _amount;
       uint256 per = (10 * _amount) / 100;
       
       _burn(msg.sender, _amount);
       assets =_amount + per;
       emit Withdraw(receiver, assets, per);
       return assets;
   }
   
   //  allow msg.sender to withdraw his deposit plus interest
   function withdraw(uint256 _amount, address receiver) public  {
       uint256 payout = redeem(_amount, receiver);
       token.transfer(receiver, payout);
   }
}

This contract provides basic functionality for depositing and withdrawing tokens from the vault. Users can deposit assets into the vault by calling the deposit function and withdrawing their holdings using the withdraw function. The contract also allows the owner to update the address of the yield-generating token.

Also, Explore | ERC-4337: Ethereum's Account Abstraction Proposal

Conclusion:

In this tutorial, we've explored the concept of building an ERC-4626 token contract for yield-bearing vaults in Ethereum. While the provided contract is a simplified example, it serves as a foundation that can be expanded upon to incorporate more sophisticated yield generation strategies and additional features.

When deploying such contracts to the Ethereum mainnet or any other blockchain, it's essential to thoroughly test the code, conduct audits, and ensure robust security measures are in place to protect users' funds.

By leveraging the power of smart contracts and DeFi protocols, developers can create innovative financial products that enable users to earn passive income and participate in the growing ecosystem of decentralized finance.

Interested in developing your project using one of the ERC standards, connect with our Ethereum developers to get started. 

References:

ERC-4626 Proposal: https://ethereum.org/developers/docs/standards/tokens/erc-4626 

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

contract Chatbot {

struct Message {

address sender;

string content;

}

Message[] public chatHistory;

event MessageSent(address sender, string content);

function sendMessage(string memory message) public {

Message memory newMessage = Message(msg.sender, message);

chatHistory.push(newMessage);

emit MessageSent(msg.sender, message);

}

function getChatHistoryLength() public view returns (uint) {

return chatHistory.length;

}

function getMessage(uint index) public view returns (address, string memory) {

require(index < chatHistory.length, "Invalid message index");

Message memory message = chatHistory[index];

return (message.sender, message.content);

}

}

const { ethers } = require("ethers");

const contractABI = require("./Chatbot.json"); // Contract ABI

const contractAddress = "0x002D7EF6B4Bd982eD4D05D56744401fbeC7703f4";

const provider = new ethers.JsonRpcProvider(

"https://sepolia.infura.io/v3/API_KEY"

);

const contract = new ethers.Contract(contractAddress, contractABI, provider);

async function contractEvents() {

contract.on("MessageSent", async (param1, param2, pair, amount, event) => {

const chatBotPrivateKey =

"";

const chatBotWallet = await connectWallet(chatBotPrivateKey);

await sendResponse(param1, param2, chatBotWallet);

});

}

async function connectWallet(walletPrivateKey) {

try {

const wallet = new ethers.Wallet(walletPrivateKey, provider);

const connectedWallet = wallet.connect(provider);

console.log("Wallet connected:", connectedWallet.address);

return connectedWallet;

} catch (error) {

console.error("Failed to connect with wallet:", error);

return null;

}

}

async function sendMessage(message, wallet) {

try {

const contractWithSigner = contract.connect(wallet);

const transaction = await contractWithSigner.sendMessage(message);

await transaction.wait();

console.log("Message sent to the blockchain:", transaction.hash);

} catch (error) {

console.error("Failed to send the message:", error);

}

}

async function sendResponse(param1, param2, chatBotWallet) {

if (param1 !== "0x06C2479D95AEe2C66e3369440A92EC0AA2885Ea0") {

if (param2.includes("Hello") || param2.includes("Hii")) {

try {

const contractWithSigner = contract.connect(chatBotWallet);

const transaction = await contractWithSigner.sendMessage(

"Hello! How can I assist you today?"

);

await transaction.wait();

console.log("Message sent to the blockchain:", transaction.hash);

} catch (error) {

console.error("Failed to send the message:", error);

}

} else {

try {

const contractWithSigner = contract.connect(chatBotWallet);

const transaction = await contractWithSigner.sendMessage(

"I'm sorry, but I'm having trouble understanding your message. It seems to be a random string of characters. If you have any specific questions or need assistance with something, please let me know, and I'll be happy to help!"

);

await transaction.wait();

console.log("Message sent to the blockchain:", transaction.hash);

} catch (error) {

console.error("Failed to send the message:", error);

}

}

}

}

async function main() {

const walletPrivateKey =

""; // Replace with your private key

const wallet = await connectWallet(walletPrivateKey);

if (wallet) {

await contractEvents();

await sendMessage("Hello, blockchain!", wallet);

}

}

main();

Smart contract development plays a crucial role in oracle development and enables the seamless integration of real-world data into blockchain networks. With smart contracts, oracles can securely and autonomously retrieve and verify external data. Let's explore the process of developing an oracle using an Ethereum smart contract.

Oracle Development Using Ethereum Smart Contracts

Oracles were created to enhance the possibilities of collaboration on blockchains. They establish connections between blockchains and external systems, enabling access to data from off-chain sources. Oracles act as a trusted source of information for the blockchain, providing secure gateways to off-chain systems. This allows smart contract applications to verify external events and trigger actions on external services.

Oracles essentially function as a link between two environments: the on-chain environment representing the blockchain network and the off-chain environment representing external systems in the real world.

Suggested Post | Blockchain Oracles | Making Smart Contracts Talk to the World

To get the address _address(Price feed contract address) of  click here
 

Deploy the contract from the Deployment tab in Remix and run the function.

This code represents a Solidity smart contract called EthPrice that retrieves the latest price of Ethereum (ETH) using a Chainlink price feed.

Here's a breakdown of the code:

• The contract starts with SPDX-License-Identifier, which specifies the license under which the code is released.
• The pragma statement defines the version range of Solidity that the contract is compatible with.
• The import statement imports the AggregatorV3Interface from the Chainlink library. This interface provides functions to interact with Chainlink price feed contracts.
• The EthPrice contract has an internal variable ethFeed of type AggregatorV3Interface. It will be used to interact with the Chainlink price feed.
• The ethHash variable stores the keccak256 hash of the string "ETH". This can be used as an identifier or key for Ethereum.
• The constructor function is used to initialize the contract. It takes an _address parameter representing the address of the Chainlink price feed contract. It assigns the provided address to ethFeed.
• The getEthPrice function is a view function that retrieves the latest ETH price from the Chainlink price feed. It returns the price as an int.
  • Inside the function, a tuple is defined to store the return values of the latestRoundData function from the ethFeed contract.
  • The latestRoundData function fetches the latest round data from the Chainlink price feed.
  • The price value is extracted from the tuple and returned.

In summary, the EthPrice contract interacts with a Chainlink price feed to retrieve the latest price of Ethereum (ETH) and provides a function getEthPrice to access this price from other contracts or externally.

Interested in Oracle development using smart contracts? Connect with our smart contract developers to get started. 

Touted as an Ethereum killer, NEAR Protocol is a decentralized blockchain app development platform. It aims to make it easier and user-friendly for developers to develop dApp. Its native token is NEAR, which users use to pay transaction fees and storage on the NEAR platform.

NEAR Protocol is the best example of a third-generation digital ledger. It focuses on solving scalability issues. To promote decentralized finance, it rewards the network to build and deploy dApps in the ecosystem.

The two distinct parts of the NEAR Protocol

- Native token named NEAR

- Smart Contracts

They manage the on-chain storage. Modification of data.

Interactions with Smart Contract-(s):-

We can interact with the contracts that we deploy as well as that others deploy.

How to create a Smart Contract on NEAR Protocol 

https://wallet.testnet.near.org and select the ‘create account’ option. Then, insert the testnet account name that you wish to use

Pre-requisites

• Rust toolchain
• A NEAR account
• NEAR command-line interface (near-cli)

Set up requirements

Using the Rust environment create a NEAR account and then install near-cli.

• Install Rust toolchain
• Install the Rustup

Install the Rustup:

Configure the current shell

Insert the following command into the configuration of your current shell:

source $HOME/.cargo/env

Add the wasm target to the blockchain network

Repository Creation

Editing Cargo.toml

Test the code

Test the smart contract code via cargo,

You will then receive output in the form of:

Compile the code

Deploying smart contracts

You will deploy it using the near-cli testnet of your NEAR account.

You will then receive output in the form of:

If you want more information on how to get started with NEAR blockchain-based dApp development, you may connect with our skilled blockchain developers.