Author: Ash Li, Noah Ho

ERC-6551 protocol is gradually heating up in the community, bringing huge potential for expansion to NFTs. ERC-6551 creates a unique contract wallet for each NFT through Token Bond Account (TBA), enabling it to hold assets and record related behaviors. This creates possibilities for identity verification of non-fungible tokens (NFTs) and composite NFTs. Upon further exploration, it is revealed that ERC-6551 actually provides a fully functional wallet for NFTs, with the "key" being the NFT itself. This article will review the development history of NFT standards and cover previous attempts to expand NFTs. Given that the core of TBA is the contract wallet, a brief introduction to the contract wallet will also be provided. Finally, we will delve into the implementation details of the protocol and its potential application prospects.

I. History and Current Status of NFT Standards

NFT, as a special form of cryptocurrency and digital art asset, provides a new digital medium for artworks and expands the application scenarios of blockchain technology. Unlike traditional fungible tokens, each NFT is unique and associated with specific metadata, such as artworks, game props, music, and other electronic data. Therefore, NFTs can serve as ownership certificates for electronic data, available for people to collect or trade. On May 3, 2014, digital artist Kevin McCoy created the first known NFT artwork "Quantum." It consists of pixelated octagons in various shapes, presented in a psychedelic manner. However, it wasn't until the emergence of ERC-721 (Ethereum Request for Comments 721) that NFTs truly had a unified standard, providing convenience for developers in different projects.

ERC-721

The development history of ERC-721 is closely linked to CryptoPunks. CryptoPunks was introduced in 2017, featuring 10,000 unique 24x24 pixel art characters. Its success attracted widespread attention from developers and the community, making more people realize the huge potential of NFTs. Subsequently, it became a blueprint for numerous NFT projects and led to the establishment of the ERC-721 standard. The standard was founded by Dieter Shirley, the CTO of CryptoKitties. In January 2018, William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs jointly proposed the ERC-721 standard. This non-fungible token standard implemented token-related ABI in smart contracts, laying the foundation for creating, managing, and transferring unique digital assets on Ethereum, opening a new chapter for artists, collectors, and the digital art market.

The main features of ERC-721 are as follows:

• Uniqueness: Unlike ERC-20 tokens (which are fungible, with each token being identical to others), each ERC-721 token is unique.
• Ownership and transfer: This token standard allows for determining the owner of any given token and permits the owner or approved individuals to transfer tokens.
• Metadata association: It allows for associating metadata with each token, which may include images, descriptions, or other relevant attributes.

To ensure its status as a standard, ERC-721 defined the following key methods and events:

balanceOf(), ownerOf(), approve(), getApproved(), setApprovalForAll(), isApprovedForAll(), transferFrom(), and safeTransferFrom(), among others.

As well as events like Transfer() and Approval().

In summary, the ERC-721 standard provides a mechanism for unique assets on Ethereum, ensuring the uniqueness and ownership of each asset, and allowing them to be verified, traded, and managed. ERC-721 has achieved explosive success in the field of digital art and collectibles. While it has brought many famous projects to the NFT application, it still has some limitations, such as the inability to act as an agent or directly associate with other on-chain assets. To address these issues, the community has proposed a series of extensions and new standards, with the most representative being EIP-3664 and EIP-3525.

ERC-3664

As early as May 2021, the DRepublic team proposed the EIP-3664, an NFT property extension protocol. This proposal cleverly addresses the limitations of mainstream NFT standards such as ERC-721 or ERC-1155 in terms of property expressiveness, difficulty in merging NFTs, and centralized property storage.

Specifically, EIP-3664 does not require modifications to existing ERC-721 and ERC-1155 standards. It dynamically adds properties to NFTs through the use of callback functions of the IERC721Receiver or IERC1155Receiver interfaces in the minting process, or by overwriting the minting process. With this protocol, an NFT can attach an unlimited number of properties without restrictions.

In EIP-3664, all properties implement the IERC3664 interface. The basic properties include ID, name, symbol, URI address, balance, and a few other basic fields used to describe the metadata of the NFT. Through EIP-3664, the extension of NFT properties becomes more flexible and customizable. It provides a standardized way to implement the functionality of NFT properties and seamlessly integrates with the existing NFT ecosystem.

ERC-3525

EIP-3525 introduces semi-fungible tokens (SFT), which can be seen as assets between fungible tokens (FT) and non-fungible tokens (NFT). Similar to NFTs, SFT tokens can be fully transferred from one wallet address to another. However, similar to FTs, SFT allows for the partial transfer of value between different tokens. For example, it is possible to transfer only a portion of the "usage period" of a piece of land to another piece of land. Undoubtedly, SFT surpasses FT in customization and NFT in efficiency.

ERC-3525

ERC-3525 allows for the construction of multi-layered SFT structures, similar to Russian nesting dolls, to achieve a more complex virtual world and define interaction rules between different levels. By using ERC-3525, NFTs can carry any digital currency. This means that NFTs can embed tokens with economic value, enabling richer functionality and interaction. For example, an SFT can contain an NFT carrying value, and the NFT can in turn nest other tokens. Through ERC-3525, developers can define rules and logic for SFTs through smart contracts, customizing specific behavioral and transaction rules. These features make ERC-3525 one of the important standards in the NFT field, providing developers and projects with more creative space.

II. ERC-6551

Introduction

To enhance the expansiveness and practicality of NFTs, the ERC-6551 proposal aims to endow each NFT with the same rights as Ethereum users. This means that NFTs can not only hold assets but also record transaction history, greatly expanding their application scope. Under this proposal, NFT holders can create a dedicated contract wallet called Token Bond Account (TBA) for their NFTs to perform various on-chain operations. This is achieved through the definition of a unified registry—Registry. This registry is specifically designed to allocate unique and fixed smart contract account addresses for all NFTs, ensuring complete control of the account lies with the NFT holder. It is worth noting that this proposal is fully compatible with existing ERC-721 or 1155 standards, requiring no modifications, and also adapts to most Ethereum account-supporting infrastructures.

This innovation provides NFTs with the same functionality as Ethereum accounts, opening up numerous new application scenarios for NFTs. For example, complex real-world assets such as characters in role-playing games, cars composed of multiple components, diversified investment portfolios, and even loyalty cards can be transformed into NFT form through this proposal. Furthermore, this proposal is not only compatible with all existing on-chain asset standards but also provides extension possibilities for future new asset standards.

As mentioned above, ERC-6551 allows for the creation of a wallet dedicated to on-chain interactions for each NFT. This wallet differs from the wallets we commonly use on platforms like Metamask—it is actually a contract wallet, deployed as a smart contract on the Ethereum network. Before delving into its implementation details, let's first understand the main differences between these two types of wallets.

Contract Accounts

An Ethereum account is an entity that holds a balance of Ether (ETH) and can send transactions on the Ethereum network. Accounts can be controlled by users or deployed as smart contracts.

There are 4 fields in Ethereum accounts:

• nonce: A counter that shows the number of transactions sent by external accounts or the number of contracts created by contract accounts. Each account can only execute a transaction with a given nonce to prevent replay attacks.
• balance: The balance of Wei held by the address. Wei is the unit of Ether.
• codeHash: The hash representing the account's code on the Ethereum Virtual Machine (EVM). Contract accounts have programmable code snippets that can perform various operations. If the account receives a message call, this EVM code is executed. Unlike other account fields, it cannot be changed. All code snippets are stored under the corresponding hash in the state database for subsequent retrieval. This hash is called codeHash. For all external accounts, the codeHash field is the hash of an empty string.
• storageRoot: The hash of the storage. The 256-bit hash of the Merkle Patricia trie root encodes the account's storage content (a mapping of 256-bit integer values) and is encoded as a trie, mapping 256-bit Keccak hashes to integer keys for 256-bit integer values encoded for RLP. This trie encodes the hash of the account's storage content and is empty by default.

Ethereum accounts are divided into 2 types: Externally Owned Accounts (EOA) controlled by private keys, and Contract Accounts (CA) without private keys, containing codeHash. They can send and receive cryptocurrency and interact with smart contracts. The commonly used Metamask wallet belongs to the EOA category.

Under the ERC-6551 standard, NFT holders can interact with the Register Contract to deploy a new smart contract, i.e., TBA, on the Ethereum network or other EVM-supporting blockchains. The ownership of TBA belongs to the NFT holder and changes with the transfer of the NFT. Only the NFT holder can control this TBA. The code of TBA, i.e., its rules, comes from the call to the Implementation Contract.

The following diagram illustrates how ERC-6551 works: Assuming a user is the holder of an NFT, their User Account has two NFTs, Contract A #123 and Contract B #456. The User Account interacts with the permissionless registry, i.e., the Register Contract, inputting NFT information and the address of the Implementation Contract to create TBA. When the User Account calls the Register Contract, inputting the NFT information for Token #123 and the address of Implementation A (0x321…), the contract wallet Account A (0x123…) is created. Its ownership belongs to the holder of NFT Token #123, and its functionality and rules come from the specifications of Implementation A. When the User Account calls the Register Contract again and changes the input, another TBA is generated. However, for a specific NFT and Implementation Contract, only a unique corresponding TBA can exist.

The creation and behavior of TBAs depend entirely on the Register Contract and the Implementation Contract. The rules in these contracts determine the characteristics and functionality of TBAs. EIP-6551 provides code templates for these contracts. We will delve into these templates in the following sections. However, these templates are not the only choice, and their code determines the deployment and functionality of TBAs, providing developers with extensive extension possibilities. For example, the Register Contract can specify which NFTs are eligible to be registered using the register contract. The Implementation Contract can define the functionality and rules of TBAs, such as setting the daily transaction limit for TBAs or specifying the types of assets they can hold.

Implementation Contract

All TBAs created through the Register Contract can choose the Implementation Contract they wish to use for the account. The Implementation Contract records the functionality and rules of the smart contract account. The Implementation Contract must provide at least the following functions:

• executeCall(): A function for executing any smart contract function that interacts with external contracts. For example, to sell assets contained in an account bound to an NFT, you may need to call a function in the Uniswap contract. executeCall() allows you to make this function call on behalf of the smart contract account, enabling you to buy/sell/exchange any assets you desire.
• token(): A read-only view function that returns the identifier of the NFT that owns the account bound to this token. It returns the chain ID (whether the NFT is on the main network, Polygon, Optimism, etc.), the NFT contract address, and the NFT token ID.
• owner(): Returns the address of the owner controlling the NFT-bound account. In the example above, this would be the User Account's address.
• nonce(): Returns the current nonce of this smart contract wallet. Each successful transaction increments the nonce by 1, with an initial value of 0.

Finally, although not a function call, the Implementation Contract bound to the token account must have a receive() function to be able to receive native assets (such as ETH) directly to its address.

Register Contract

Below is the Registry smart contract written in Solidity language:

// Code for the Registry smart contract

This code demonstrates that the parameters required to create an account for a specific NFT include implementation() for the implementation contract address, chainId() for the target chain's ID, tokenContract() for the corresponding NFT contract, tokenId() for the corresponding NFT ID, and a salt value. Using the Fast Dapp's Demo, creating an NFT account only requires entering the NFT contract address and ID, with the remaining fields generated automatically, making the process relatively simple.

The ERC-6551 proposal is a revolutionary token standard in the NFT field, representing a disruptive upgrade to the original NFT standard. ERC-6551 uses a permissionless registry compatible with existing ERC-721 NFTs. This registry is a smart contract serving as a factory and directory for TBAs. Anyone can create a TBA for any ERC-721 token by calling functions on the registry and paying a small fee. The smart contract of the registry has two functions:

• createAccount(): Deploys a new token-bound account for a given ERC-721 NFT and a specific implementation.
• account(): A read-only view function that returns the address of the token-bound account for a given ERC-721 NFT, given its implementation.

Potential Applications

Since the Azuki incident, the appeal of single static image NFTs has significantly decreased, leading to a decline in the value of many top projects. However, NFTs with high interactivity and composability may be the key to the market's recovery. From blockchain games, music, DID to the metaverse, these areas are full of endless potential.

NFTs are not just assets; they also have their own on-chain identity and container properties, allowing interaction with decentralized applications (Dapps). This means that all interactions with NFTs are directly recorded on the NFT itself, rather than in the account of its holder. Additionally, since NFTs are based on smart contracts, their behavior and interactions can be defined and controlled through contract rules, providing flexibility and security.

The ERC-6551 protocol has brought revolutionary changes to the NFT field, shifting the focus from user wallets to the NFTs themselves, providing new possibilities for transactions, gaming, traceability, and governance. As NFTs continue to evolve, this protocol will lead us into a more personalized, interactive, and meaningful digital era.

Consider the following four potential application directions:

• Asset Bundling: NFTs can serve as asset containers, allowing multiple assets to be bundled and traded within a single NFT. For example, a music album NFT may contain multiple song NFTs, or an art collection NFT may contain multiple art piece NFTs. This not only makes collecting more systematic but also reduces gas fees during transactions.
• Portfolio Management: NFTs can serve as asset management tools, allowing users to store and manage multiple tokens in a single TBA. Additionally, NFT holders can authorize third-party managers to trade assets and clearly define the manager's permissions in smart contracts, ensuring the security of assets.
• NFT Identity Management: NFTs can record all their on-chain activities, making them a true on-chain identity. Users can represent themselves using a single ENS wallet and use different TBAs to represent their roles in different communities or applications.
• Modular NFTs: The main NFT can generate TBAs for storing its component NFTs. For example, in a game, a character NFT may be equipped with various equipment NFTs. This not only makes the metaverse more feasible but also allows for integration with AI to create more realistic NPC characters.

In conclusion, the future of NFTs is full of endless possibilities. From asset management to identity verification, and modular game design, they will play a crucial role in the digital world.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。