Authors: Ash Li, Noah Ho
Discussions around the ERC-6551 protocol have been gaining momentum in the community, as this standard brings tremendous expansion potential for NFTs. Through the mechanism of token-bound accounts (TBAs), ERC-6551 creates a unique contract wallet for each NFT, enabling it to hold assets and record relevant behaviors. This creates possibilities for non-fungible token (NFT) identity verification and composable NFTs. Upon deeper examination, we find that ERC-6551 effectively provides NFTs with a fully-functional wallet, whose "key" is the NFT itself. This article will review the standard development process of NFTs and cover past attempts at NFT extension. As the core of TBA lies in contract wallets, we will also briefly introduce contract wallets. Finally, we will delve into the implementation details of this protocol and its potential application prospects.
I. History and Current State of NFT Standards
As a specialized form of cryptocurrency and digital art asset, NFTs provide a new digital medium for artworks while expanding the application scenarios of blockchain technology. Different from traditional fungible tokens, each NFT is unique and associated with specific metadata such as artworks, game items, music and other electronic files. Therefore, NFTs can serve as certificates of ownership for electronic data, enabling people to collect or trade them. On May 3, 2014, digital artist Kevin McCoy created the first known NFT work titled "Quantum", comprised of various pixelated octagons presented psychedelically. However, it wasn't until the emergence of ERC-721 that NFTs truly gained a unified standard, providing developers with convenience in various project applications.
ERC-721
The development history of ERC-721 is closely intertwined with CryptoPunks. CryptoPunks debuted in 2017 and included 10,000 unique 24x24 pixel art characters. Its success in attracting widespread attention from developers and the community helped more people recognize the immense potential of NFTs. It thereafter became the blueprint for many NFT projects and spurred the formulation of the ERC-721 standard. This standard was created 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 the ABI related to tokens in smart contracts, laying the foundation for creating, managing and transferring unique digital assets on Ethereum and opening a new chapter for artists, collectors and the digital art market.
Here are the key features of ERC-721:
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 standard allows determining the owner of any given token and allows the owner or approved individuals to transfer the token.
Metadata association: It allows metadata to be associated with each token, which may include the token's image, description, or other relevant attributes.
To ensure it functions as a standard, ERC-721 defines the following core methods and events:
Methods like balanceOf( ), ownerOf( ), approve( ), getApproved( ), setApprovalForAll( ), isApprovedForAll( ), transferFrom( ), and safeTransferFrom( )
Events like Transfer( ) and Approval( )
In summary, ERC-721 provides a mechanism for unique assets on Ethereum to ensure each asset's uniqueness and ownership while allowing them to be verified, traded, and managed. As the standard for non-fungible tokens, ERC-721 achieved explosive success in digital arts and collectibles.
However, while it brought many famous projects to NFT applications, some limitations still exist, such as they cannot serve as proxies for operations or directly associate with other on-chain assets. To address these issues, the community proposed a series of extensions and new standards, among which EIP3664 and EIP3525 are most representative.
ERC-3664
As early as May 2021, the DRepublic team proposed the EIP-3664 NFT attribute extension protocol. This proposal cleverly addressed limitations such as insufficient attribute expression, difficulty in merging NFTs, and centralized attribute storage in mainstream NFT standards such as ERC-721 or ERC-1155.
Specifically, EIP-3664 does not require modifying existing ERC-721 and ERC-1155 standards. It dynamically adds attributes to NFTs through callback functions of IERC721Receiver or IERC1155Receiver interfaces in the NFT minting method. Attributes can also be added by overriding the minting process. Using this protocol, an NFT can attach an unlimited number of arbitrary attributes.
In EIP-3664, all attributes implement the IERC3664 interface. Basic attributes include ID, name, symbol, URI address, balance, etc. for describing NFT metadata. Through EIP-3664, NFT attribute extension becomes more flexible and customizable. It provides a standardized implementation for NFT attributes while seamlessly integrating with existing NFT ecosystems.
ERC-3525
EIP-3525 introduces semi-fungible tokens (SFTs), which can be regarded as assets between fungible tokens (FTs) and non-fungible tokens (NFTs). Like NFTs, SFT tokens can be fully transferred from one wallet address to another. But like FTs, SFTs allow transferring only a portion of value between different tokens. For example, only a portion of the "usage years" can be transferred from one piece of land to another. Undoubtedly, SFTs surpass FTs in customizability and surpass NFTs in efficiency.
ERC3525 allows for the creation of multi-level SFT structures, similar to Russian nesting dolls, enabling more complex virtual worlds and defining interaction rules between different levels. By using ERC3525, NFTs can carry arbitrary digital currencies. This means that tokens with economic value can be embedded within NFTs, enabling richer functionality and interaction. For example, an SFT can contain a value-carrying NFT, which in turn can nest other tokens. Through ERC3525, developers can define the rules and logic of SFTs through smart contracts, customizing specific behavioral and transaction rules. These features make ERC3525 one of the important standards in the NFT space, providing developers and projects with more creative opportunities.
II. ERC-6551
Introduction
To enhance the expandability and practicality of NFT, the ERC-6551 proposal aims to confer each NFT with the same rights and benefits as an Ethereum user. This means that in addition to holding assets, NFTs can also record transaction histories, greatly expanding their application scope. Under this proposal, NFT holders can create a dedicated contract wallet called a TBA (Token Bond Account) for their NFT to perform various on-chain operations. This is achieved by defining a unified registry - Registry. This registry specially allocates a unique and fixed smart contract account address for all NFTs, ensuring the control over the account remains entirely in the hands of the NFT holder. Notably, this proposal is fully compatible with existing ERC-721 or ERC-1155 standards without any modifications required, while also adapting to most Ethereum account infrastructure.
This innovation provides NFTs with the same functionalities as Ethereum accounts, opening up many new application scenarios for NFTs. For example, complex real-world assets such as RPG game characters, vehicles composed of various components, diversified investment portfolios, or even membership cards can all be converted into NFT form through this proposal. In addition, this proposal is not only compatible with all existing on-chain asset standards but also provides extensibility for future new asset standards.
As mentioned earlier, ERC-6551 allows creating a dedicated on-chain interaction wallet for each NFT. This wallet differs from those commonly used on platforms like Metamask - it is actually a smart contract wallet, i.e. a smart contract deployed on the Ethereum network. Before delving into its implementation approach, let's first understand the key differences between these two types of wallets.
Contract Account
An Ethereum account is an entity that has 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 an Ethereum account:
nonce: A counter used to track the number of transactions sent from an external account or contracts created by a contract account. Each account can only execute a transaction with a given nonce to prevent replay attacks, where signed transactions are repeatedly broadcast and re-executed.
balance: Keeps track of the Wei amount owned by this address. Wei is the base unit of Ether.
codeHash: This hash represents the account's code on the Ethereum Virtual Machine (EVM). Contract accounts have programmable code snippets that can perform different operations. If the account receives a message call, this EVM code is executed. Unlike other account fields, it cannot be modified. All code snippets are stored under their respective hashes in the state database for later retrieval. This hash value is called the codeHash. For externally owned accounts, the codeHash field is the hash of an empty string.
storageRoot: The storage root. A 256-bit Keccak256 hash that encodes the contents of the account's storage (mapping of 256-bit integers to 256-bit values), encoded as a Merkle Patricia Trie, as a mapping from 256-bit integer keys to RLP-encoded 256-bit integer values. This Trie hashes the encoding of the contents of storage for this account, defaulting to empty.
Ethereum accounts are divided into two types: externally owned accounts (controlled by private keys), and contract accounts.
Externally Owned Accounts (EOA): Controlled by private keys, with an empty codeHash. These accounts can send and receive cryptocurrencies and interact with smart contracts. Wallets like Metamask fall into this category.
Contract Accounts (CA): Have no private keys, with a non-empty codeHash. They are smart contracts deployed on the Ethereum network, controlled through interactions with external accounts.
Standard contract wallets exist in CAs, like ERC4337 Account Abstraction Wallets, and Native AA type wallets on networks like ZkSync and StarkNet where there are no traditional transactions - all accounts are contract accounts. Currently wallet ownership and signing issues exist, such as difficulty protecting private keys, users losing all assets when private keys are lost, signing algorithm low permission high risk issues, and settlement only available through ETH single cryptocurrency.
ERC4337 can help Ethereum progress towards account abstraction without changing consensus layer protocols, by implementing account abstraction upgrades through smart contracts, updating the original entire transaction initiation process all the way to its inclusion in the blockchain with the introduction of UserOperation describing the structure of transactions sent by users, and Bundler bundles these in-memory transactions to lower user transaction costs, enabling multi-signature scenarios more fully, and upgrading social recovery functions.
Implementation
Under the ERC-6551 standard, the holder of an NFT can deploy a new smart contract, i.e. TBA, on the Ethereum network or other blockchains supporting EVM through interactions with the Register Contract. Ownership of the TBA belongs to the holder of the NFT, and will change along with the transfer of the NFT. Only the holder of the NFT can control this TBA. The code, i.e. rules of the TBA come from calls to the Implementation Contract.
The following diagram illustrates how ERC-6551 works: Suppose a user is the holder of NFT Contract A's #123 and Contract B's #456. The User Account interacts with the permissionless Register Contract (Register Contract) by inputting NFT information and the implementation contract address, thereby creating a TBA. When the User Account calls the register contract, entering the NFT information of Token #123 and address of Implementation A (0x321...), the contract wallet Account A (0x123...) will be created. Its ownership belongs to the holder of NFT Token #123, and its functionality and rules come from the stipulations of Implementation A. When the User Account again calls the register contract and changes the input, another TBA will be generated. However, for a specific NFT and implementation contract, there can only be a uniquely corresponding single TBA.
The creation and behavior of TBA is entirely dependent on the register contract and implementation contract. The rules in these contracts determine the characteristics and functionality of TBA. EIP-6551 provides code templates for these contracts. We will explore these templates in more depth later. However, these templates are not the only option - their code determines how TBAs are deployed and functions implemented. This provides developers with broad extensibility. For example, the register contract can stipulate which NFTs are eligible to register using that register contract. The implementation contract can define the functionality and rules of TBA, such as setting daily transaction limits or specifying asset types it can hold.
Implementation Contract
All TBAs created by the register contract can choose the implementation contract they want to use for the account. The implementation contract records the functionality and rules of the smart contract account. It must provide at least the following functions:
executeCall( ): Used to execute arbitrary smart contract functions that interact with external contracts. For example, to sell contained assets in an account bound to an NFT, you may need to call functions in the Uniswap contract. The executeCall( ) allows representing the smart contract account to make that function call, enabling buying/trading any assets desired.
token( ): A read-only view function that returns the identifier of the NFT bound to this account. It returns the chainID (whether the NFT is on mainnet, Polygon, Optimism etc.), the NFT contract address and NFT token ID.
owner( ): Returns the address of the owner controlling the NFT bound to this account. In the above example, this would be the User Account address.
nonce( ): Returns the current nonce for this smart contract wallet. Each successful transaction increments the nonce by 1, initializing at 0.
Lastly, while not a function call, the implementation contract for a token-bound account must have a receive() function to enable directly receiving native assets (like ETH) to its address.
Registry Contract
Here is a Registry smart contract written in Solidity:
This code indicates that the parameters required to create an account for a specific NFT include the implementation address of the executing contract, the chainId of the target chain, the tokenContract corresponding to the NFT contract, the tokenId corresponding to the NFT's ID, and the obfuscation value salt. Creating an NFT account using Fast Dapp's Demo only requires inputting the NFT contract address and ID, as the remaining fields are automatically generated. The steps involved are relatively simple.
The ERC-6551 proposal introduces a new token standard that represents a disruptive upgrade to the original NFT standard. ERC-6551 utilizes a permissionless registry that is compatible with existing ERC-721 NFTs. The registry is a smart contract that serves as a factory and directory for Token-Bound Accounts (TBAs). Anyone can create a TBA for an ERC-721 token by calling functions on the registry and paying a small fee. The smart contract of the registry has two functions:
createAccount( ): Creates 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 associated with a given ERC-721 NFT, along with its implementation.
Potential Applications
Since the Azuki incident, the allure of single static image NFTs has significantly diminished, leading to a decline in the value of many top-tier projects. However, NFTs with high interactivity and combinability might be the key to market recovery. From blockchain games, music, DID to the metaverse, these domains are brimming with endless potential.
NFTs are not just assets; they also possess their own on-chain identity and container attributes, allowing them to interact with decentralized applications (Dapps). This means that all interactions with the NFT are recorded directly onto the NFT itself, rather than the account of its holder. Moreover, since NFTs operate based on smart contracts, their behaviors and interactions can be defined and controlled through contract rules, offering both flexibility and security.
The ERC-6551 protocol has brought about a revolutionary change in the NFT domain, shifting the focus from user wallets to the NFTs themselves, paving the way for new possibilities in trading, gaming, traceability, and governance. As NFTs continue to evolve, this protocol will usher 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 for the packaging and trading of multiple assets within a single NFT. For instance, a music album NFT might contain several song NFTs, or an art collection NFT might encompass multiple artwork NFTs. This not only systematizes collections but can also reduce Gas Fee during transactions.
Investment Portfolios: NFTs can act as asset management tools, enabling users to store and manage various Tokens within a single TBA. Furthermore, NFT holders can authorize third-party managers to trade assets and clearly define the manager's permissions in the smart contract, ensuring asset security.
NFT Identity Management: NFTs can record all their on-chain activities, establishing them as genuine on-chain identities. Users can utilize a single ENS wallet to represent themselves and employ different TBAs to represent their roles in various communities or applications.
Modular NFTs: A primary NFT can generate a TBA to store its component NFTs. For example, in a game, a character NFT might be equipped with various gear NFTs. This not only makes the realization of the metaverse more feasible but can also be combined with AI to create more lifelike NPC characters.
In conclusion, the future of NFTs is filled with boundless possibilities. From asset management to identity verification, and modular game design, they are set to play a pivotal role in the digital world.