Hire the Best Javascript Developer

Understanding Account Abstraction on Ethereum for Smart Contract WalletsA 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 4907Why 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-1155Approaches to Implement Account Abstraction:Protocol-Level ChangesIt entails modifying the Ethereum protocol to allow native wallets for smart contracts. Consensus is required for this strategy throughout the Ethereum network.Layer 2 SolutionsLayer 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-6551What 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 StructPurpose: 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 contract2. EntryPoint ContractPurpose: 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 Tokenization3. User Wallet ContractPurpose: 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 Transfer4. Gas Payment MechanismPurpose: 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 WalletPurpose: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 TokenA recent breakthrough: EIP-4337Since 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 tokenConclusion 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.

NFT Rental Marketplace Development using ERC 4907For a predetermined period, NFT owners can lease their tokens to third parties via ERC 4907. This functionality allows different players or users to temporarily use the NFTs in various applications, such as virtual real estate or gaming.The roles involved in this process include the Owner, who possesses the NFT; the User, who has the NFT in their wallet but is unable to sell or transfer it; and the "expires" function, which automatically ends usage without any further action required.A controller or operator role is assigned to oversee a large number of NFTs. While they can perform certain usage operations, individuals in these roles are unable to approve or transfer the NFT, unlike the owner.As an extension of ERC-721, the ERC 4907 standard introduces the dual roles of "owner" and "user" at the application layer. With an automatic "expires" mechanism that enforces the user's time-limited role, ERC 4907 simplifies NFT rentals. Thanks to this innovative feature, NFTs are automatically rentable; owners no longer need to manually revoke user privileges, saving time and avoiding additional on-chain transactions.The main challenge arises in usage rights management, making it essential to establish a unified standard to facilitate collaboration across all applications.You may also like | Why ERC-7007 is the Next Big Thing in BlockchainReal-world Applications and CollaborationsIt's becoming more and more common in the world of digital assets for non-fungible tokens (NFTs) to use the new Ethereum token standard, ERC 4907. In order to facilitate the temporary transfer of usage rights while maintaining ownership, it creates a new "user role" that is distinct from the "owner role." This is advantageous for subscription or rental models.In order to enable NFT rentals, Double Protocol has incorporated ERC 4907, allowing asset owners to lease without forfeiting ownership. This expands the utility of NFT and opens up new revenue streams. By including ERC 4907-based rental options, their relationship with Shardeum, a scalable smart contract platform, improves this strategy even further and fosters an NFT ecosystem that is more widely available.These collaborations highlight the real-world applications and transformative potential of ERC 4907, leading to a more dynamic digital asset market. As these partnerships develop, they promise significant changes in the landscape of NFTs and digital ownership.You may also like | How to Implement an On-Chain NFT AllowlistERC 4907 Use CasesGamingPlayers can rent rare in-game items or characters temporarily, allowing for access to premium content without a full purchase.Virtual Real EstateUsers can rent virtual plots of land or properties in metaverse platforms for specific events or time periods.Art and CollectiblesArtists can rent their works for exhibitions or shows, allowing more people to experience the art without ownership.Also, Explore | NFT ETFs | A Beginner's Guide to Investing in Digital AssetsRenting NFTs is a reasonable approachThe blockchain used the actual world as a source for the concept of renting. Instead of paying money to use something that the other party has, one party wants it but cannot afford to own it or doesn't need it. People adore the thought of living off the returns from their assets, exactly like in the real world. Rentable NFTs' primary concept is that they are a passive revenue source.What Advantages Does ERC 4907 Bring?Market LiquidityERC 4907 will enhance NFT renting and enable related derivatives across various use cases, such as gaming, art, and music. As the Metaverse and Web3 expand, more people will opt to rent NFTs instead of buying assets, increasing market liquidity over time.Easy Third-party IntegrationERC 4907, which establishes a single standard, will enhance collaboration and assist Ethereum's cross-platform ecosystem. This standard improves communication between all parties engaged in utility NFT leases for gaming, the metaverse, and membership cards by simplifying integration and reducing development costs.Moreover, third-party protocols employing ERC 4907 may oversee NFT usage rights without needing permission from the initial issuer. Others can swiftly do their own tasks when a project gives users this position. A PFP NFT, for instance, may be included in a platform that permits short-term rentals and simultaneously offers "rent-to-own" options via a mortgage platform without the original project's permission.Backward CompatibilityBy introducing an extended function set, the ERC 4907 standard can achieve full ERC-721 compatibility. Furthermore, there are a lot of parallels between the new functions provided in this standard and the current ERC-721 functionalities. This makes it possible for developers to embrace the new standard swiftly and simply. Future and current NFTs produced as standard ERC-721 can be wrapped to be compatible with ERC 4907 or upgraded to ERC 4907.Also, Read | How to Create a Compressed NFT on SolanaNeed of ERC 4907Renting Out AssetsOwners can lease their digital assets while maintaining ownership according to ERC 4907, which permits NFTs to be rented out. For asset holders, this means additional revenue prospects.Increased Digital Assets' ValueThis standard increases the functionality of NFTs and encourages their wider use across a range of industries, including gaming and virtual real estate, by allowing them to be rented.Innovative UsesIn the NFT space, the standard fosters innovation by creating opportunities for new applications including digital art exhibitions, virtual events, and game rentals.Also, Check | A Step-by-Step Tutorial of Building a Cross Chain NFT BridgeThings to Take Into Account When Implementing ERC 49071. In situations when the rental mechanism is not thoroughly monitored, users may take advantage of it. For example, they may rent an NFT for a very little time in order to swiftly transfer it without the owner's permission.2. Legal concerns may arise from renting digital assets, particularly if the NFTs include copyrighted content or other intellectual property. Users might have to make sure local laws are followed.Also, Discover | NFT-Based Loyalty Programs: Revamping Customer EngagementDetails of the ERC 4907 Interface:// function setUser(uint256 tokenId, address user, uint64 expires) external Main Purpose: Assigns a user to an NFT along with an expiration time. Parameter: tokenId: Unique Identifier of NFT user: the address of new user who can Use NFT exepires: duration until which the user can access the NFT Access-Control : Usually callable from an authorised address or the NFT owner. This guarantees that user access can only be modified byauthorised entities. // function userOf(uint256 tokenId) external view returns (address); Purpose: identifies the NFT's engaged user. Parameters: tokenId:Unique Identifier of NFT. Returns: The user's address. It returns the zero address (address(0)) in the event that the user has expired or if no user is allocated. // function userExpires(uint256 tokenId) external view returns (uint256); Purpose: retrieves the NFT user's expiration timestamp. Parameters: tokenId:Unique Identifier of NFT. Returns: The Unix timestamp indicating the expiration date of the user's access. There is no user when the value is 0. // Event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires); Purpose: Emitted whenever a user is assigned or updated for an NFT. Parameters: tokenId: unique identifier of the NFT. user: Address of the new User. expires: The new expiration timestamp. Significance: Real-time tracking of user assignments is made possible by this event for both front-end apps and external services. Also, Read | NFT Domains | Revolutionizing Ownership in the Digital LandscapeERC 4907 Implementation// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; // ERC721 Implementation contract MyERC721Token { struct Token { address owner; address approved; } // Mapping from token ID to token information mapping(uint256 => Token) private _tokens; // Mapping from owner to number of tokens mapping(address => uint256) private _balances; // Mapping from owner to operator approvals mapping(address => mapping(address => bool)) private _operatorApprovals; // Counter for token IDs uint256 private _tokenIdCounter; // Events event Transfer(address indexed from, address indexed to, uint256 indexed tokenId); event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId); event ApprovalForAll(address indexed owner, address indexed operator, bool approved); // Mint a new NFT function mint(address to) public { require(to != address(0), "Cannot mint to zero address"); uint256 tokenId = _tokenIdCounter++; _tokens[tokenId] = Token(to, address(0)); _balances[to]++; emit Transfer(address(0), to, tokenId); } // Get the balance of an owner function balanceOf(address owner) external view returns (uint256) { require(owner != address(0), "Owner address cannot be zero"); return _balances[owner]; } // Get the owner of a specific token function ownerOf(uint256 tokenId) public view returns (address) { address owner = _tokens[tokenId].owner; require(owner != address(0), "Token does not exist"); return owner; } // Approve another address to transfer the specified token function approve(address to, uint256 tokenId) external { address owner = ownerOf(tokenId); require(msg.sender == owner, "Not the token owner"); _tokens[tokenId].approved = to; emit Approval(owner, to, tokenId); } // Get the approved address for a specific token function getApproved(uint256 tokenId) public view returns (address) { require(_tokens[tokenId].owner != address(0), "Token does not exist"); return _tokens[tokenId].approved; } // Approve or revoke permission for an operator to manage all tokens function setApprovalForAll(address operator, bool approved) external { require(operator != msg.sender, "Cannot approve oneself"); _operatorApprovals[msg.sender][operator] = approved; emit ApprovalForAll(msg.sender, operator, approved); } // Check if an operator is approved to manage all tokens of the owner function isApprovedForAll(address owner, address operator) external view returns (bool) { return _operatorApprovals[owner][operator]; } // Transfer ownership of a token function transferFrom(address from, address to, uint256 tokenId) external { require(msg.sender == from || msg.sender == getApproved(tokenId) || _operatorApprovals[from][msg.sender], "Not authorized"); require(_tokens[tokenId].owner == from, "Incorrect owner"); require(to != address(0), "Cannot transfer to zero address"); // Call before transfer hook _beforeTokenTransfer(from, to, tokenId); // Transfer the token _tokens[tokenId].owner = to; _tokens[tokenId].approved = address(0); _balances[from]--; _balances[to]++; emit Transfer(from, to, tokenId); } // Internal function to clear approval when transferring function _clearApproval(uint256 tokenId) internal { if (_tokens[tokenId].approved != address(0)) { delete _tokens[tokenId].approved; } } // Internal hook to be overridden function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal virtual {} } // Interface for ERC 4907 interface IERC4907 { event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires); function setUser(uint256 tokenId, address user, uint64 expires) external; function userOf(uint256 tokenId) external view returns (address); function userExpires(uint256 tokenId) external view returns (uint256); } // ERC 4907 Implementation contract ERC4907 is MyERC721Token, IERC4907 { // Custom errors error CanNotRentToZeroAddress(); error NotOwnerOrApproved(); error InvalidExpire(); struct TenantInfo { address tenant; uint64 expires; } mapping(uint256 => TenantInfo) internal _tenants; constructor() { // Minting initial tokens for (uint256 i = 1; i <= 10; i++) { mint(msg.sender); // Minting 10 NFTs } } function setUser(uint256 tokenId, address tenant, uint64 expires) public override { if (ownerOf(tokenId) != msg.sender && getApproved(tokenId) != msg.sender) { revert NotOwnerOrApproved(); } if (tenant == address(0)) { revert CanNotRentToZeroAddress(); } if (expires <= block.timestamp) { revert InvalidExpire(); } TenantInfo storage ref = _tenants[tokenId]; ref.tenant = tenant; ref.expires = expires; emit UpdateUser(tokenId, tenant, expires); } function userOf(uint256 tokenId) public view override returns (address) { TenantInfo storage ref = _tenants[tokenId]; if (ref.expires >= block.timestamp) { return ref.tenant; } else { return address(0); } } function userExpires(uint256 tokenId) public view override returns (uint256) { return _tenants[tokenId].expires; } // Override the transfer function to clear tenant info on transfer function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal override { super._beforeTokenTransfer(from, to, tokenId); TenantInfo storage ref = _tenants[tokenId]; if (from != to && ref.tenant != address(0)) { delete _tenants[tokenId]; emit UpdateUser(tokenId, address(0), 0); } } } ConclusionWith the release of ERC 4907, which provides a flexible framework designed specifically for the growing NFT rental industry, non-fungible tokens (NFTs) have evolved tremendously. Its dual-role strategy not only makes rights allocation more clear but also lays the foundation for a range of partnerships and applications. This innovation comes at a perfect time, as it tackles the intricacy of the leasing space and keeps up with the exponential growth of digital assets.ERC 4907 represents an evolution in the NFT space by introducing rental functionalities, and providing new opportunities for monetization and interaction with digital assets. It opens the door to innovative business models and use-cases across various industries, enhancing the utility of NFTs beyond mere ownership.The NFT environment is about to change as ERC 4907 redefines digital asset leasing and develops popularity across several ecosystems. A future of innovation and fluidity in digital asset management is promised by the protocol, which also offers increased security, operational efficiency, and a multitude of opportunities. As a major protagonist in the story of digital innovation, ERC 4907 solidifies its position by setting new standards that not only predict future trends but also meet present needs. Need assistance with developing your NFT project, connect with our skilled blockchain and NFT developers to get started.References:https://github.com/tronprotocol/tips/blob/master/tip-4906.mdhttps://ethereum-magicians.org/t/eip-6884-delegatable-utility-tokens-derived-from-origin-nfts/13837/https://github.com/ethereum/ERCs/blob/master/ERCS/erc-7507.md/https://github.com/ethereum/web3.py/issues/1351https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.solhttps://forum.openzeppelin.com/t/error-verifying-erc721-in-etherscan-file-import-callback-not-supported-with-github-imports/4198https://soliditydeveloper.com/erc-1155https://medium.com/coinmonks/erc-721-tokens-b83d7fc3e740https://ethereum.stackexchange.com/questions/117365/executing-view-read-functions-on-gnosis-safe-with-raw-encoded-data/https://www.kaleido.io/blockchain-blog/how-to-create-and-deploy-an-erc-721-tokenhttps://github.com/OpenZeppelin/openzeppelin-contracts/issues/3659https://hips.hedera.com/hip/hip-376