ERC6551: When NFTs Meet Contract Wallets

Author: Ash Li, Noah Ho

The discussion around the ERC-6551 protocol in the community is gradually heating up, as this protocol brings tremendous expansion potential for NFTs. ERC-6551 creates a unique contract wallet for each NFT through Token Bond Accounts (TBA), enabling them to hold assets and record related activities. This opens up possibilities for the authentication of non-fungible tokens (NFTs) and composite NFTs. Upon deeper exploration, we can find that ERC-6551 actually provides NFTs with a fully functional wallet, and the "key" to this wallet is the NFT itself. This article will review the historical development of NFT standards and cover previous attempts to expand NFTs. Given that the core of TBA is contract wallets, we will also provide a brief introduction to contract wallets. Finally, we will delve into the implementation details of this protocol and its potential application prospects.

I. History and Current Status of NFT Standards

NFTs, as a special type of cryptocurrency and digital art asset, provide a new digital carrier for artworks and expand the application scenarios of blockchain technology. Unlike traditional fungible tokens, each NFT is unique and associated with specific metadata, such as electronic materials like artworks, game items, and music. Therefore, NFTs can serve as proof of ownership for electronic data, allowing people to collect or trade them. On May 3, 2014, digital artist Kevin McCoy created the first known NFT artwork, "Quantum." It is a pixelated octagon composed of various shapes and 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, facilitating their application across various projects for developers.

ERC-721

ERC-721 is closely linked to the development of CryptoPunks. Launched in 2017, CryptoPunks consists of 10,000 unique 24x24 pixel art images. Its success attracted widespread attention from developers and the community, making more people aware of the immense potential of NFTs. Subsequently, it became the blueprint for many NFT projects and led to the establishment of the ERC-721 standard, 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 and identical to each other), each ERC-721 token is unique.
• Ownership and Transfer: This token standard allows for the identification of the owner of any given token and permits the owner or approved individuals to transfer the token.
• Metadata Association: Allows metadata to be associated with each token, which may include images, descriptions, or other relevant attributes.

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

Methods such as balanceOf(), ownerOf(), approve(), getApproved(), setApprovalForAll(), isApprovedForAll(), transferFrom(), and safeTransferFrom().

And events such as 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. As the standard for non-fungible tokens, ERC-721 has achieved explosive success in the fields of digital art and collectibles. Importantly, it defines the framework for NFTs. However, despite bringing many notable projects to NFT applications, it still has some limitations, such as the inability to act as proxies or directly associate with other on-chain assets. To address these issues, the community has proposed a series of extensions and new standards, among which EIP-3664 and EIP-3525 are the most representative.

ERC-3664

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

Specifically, EIP-3664 does not require modifications to existing ERC-721 and ERC-1155 standards. It dynamically adds attributes to NFTs by using the callback functions of the IERC721Receiver or IERC1155Receiver interfaces in the minting method of NFTs. Alternatively, it can also be done by rewriting the minting process. With this protocol, an NFT can attach an unlimited number of attributes.

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

ERC-3525

EIP-3525 introduces semi-fungible tokens (SFT), which can be seen as assets that lie 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, like FT, SFT allows for the transfer of only a portion of the value between different tokens. For example, one can transfer only a portion of the "usage years" of land to another piece of land. Undoubtedly, SFT surpasses FT in customization and outperforms NFT in efficiency.

ERC-3525 allows for the construction of multi-level SFT structures, similar to Russian nesting dolls, enabling more complex virtual worlds and defining interaction rules between different levels. By using ERC-3525, NFTs can carry any digital currency. This means that tokens with economic value can be embedded within NFTs, achieving richer functionalities and interaction methods. For example, an SFT can contain an NFT with value, and within that NFT, other tokens can be nested. Through ERC-3525, developers can define the rules and logic of SFTs through smart contracts, customizing specific behavioral and trading rules. These features make ERC-3525 one of the important standards in the NFT field, providing developers and project parties with more creative space.

II. ERC-6551

Introduction

To enhance the scalability and practicality of NFTs, the ERC-6551 proposal aims to grant each NFT the same rights as Ethereum users. This means that NFTs can not only hold assets but also record transaction histories, greatly expanding their application scope. Under this proposal, NFT holders can create a dedicated contract wallet called TBA (Token Bond Account) for their NFTs to perform various on-chain operations. This is achieved by defining a unified registry—Registry. This registry allocates unique and fixed smart contract account addresses for all NFTs and ensures that the control of these accounts remains entirely with the NFT holders. Notably, this proposal is fully compatible with existing ERC-721 or 1155 standards and requires no modifications, while also adapting to most infrastructures that support Ethereum accounts.

This innovation provides NFTs with the same functionalities as Ethereum accounts, opening up numerous new application scenarios for NFTs. For instance, complex real-world assets, such as characters in role-playing games, cars composed of multiple parts, diversified investment portfolios, and even membership cards, can be transformed into NFTs through this proposal. Furthermore, this proposal is not only compatible with all existing on-chain asset standards but also offers expansion 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, meaning it is a smart contract deployed on the Ethereum network. Before delving into its implementation, let’s first understand the main differences between these two types of wallets.

Contract Accounts

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.

In Ethereum, accounts have four fields:

• 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 one transaction with a given random number to prevent replay attacks, which refer to broadcasting and repeatedly executing signed transactions.
• balance: A balance accounting model that indicates the amount of Wei owned by this address. Wei is the smallest denomination of Ether.
• codeHash: This hash represents the account code on the Ethereum Virtual Machine (EVM). Contract accounts have programmed 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 changed. All code snippets are stored under the corresponding hash in the state database for subsequent retrieval. This hash value is called codeHash. For externally owned accounts, the codeHash field is the hash of an empty string.
• storageRoot: Storage hash. The 256-bit hash of the Merkle Patricia trie root node encodes the storage content of the account (mapping of 256-bit integer values) and is encoded as a Trie, mapping 256-bit Keccak hashes of integer keys to RLP-encoded 256-bit integer values. This Trie encodes the hash of the storage content for this account, which is empty by default.

Ethereum accounts are divided into two types: external accounts (user-managed private keys) and contract accounts.

1. Externally Owned Accounts (EOA): Controlled by private keys, with an empty codeHash. These accounts can send and receive cryptocurrencies and interact with smart contracts. The Metamask wallet we commonly use falls into this category.
2. Contract Accounts (CA): No private key, with a non-empty codeHash. It is a smart contract deployed on the Ethereum network, controlled by interacting with the contract through external accounts.

Within CAs, there are standard contract wallets, such as ERC-4337 account abstraction wallets, and native AA-type wallets, such as ZkSync and StarkNet, where there are no traditional transactions, and all accounts are contract accounts. Currently, wallets face issues of ownership and signing rights, such as the difficulty in protecting private keys, where users lose all assets if they lose their private keys, and the problem of limited signing algorithms with high permissions, as well as the issue of transaction fees being settled in only one currency, ETH.

Without changing the consensus protocol layer, ERC-4337 can help Ethereum move towards account abstraction. It can achieve an upgrade of account abstraction through smart contracts, updating the entire process from initiating a transaction to its inclusion in the blockchain, introducing UserOperation, which describes the structure of transactions sent on behalf of users. Bundlers will package these transactions in the memory pool, reducing users' transaction costs, and making multi-signature scenarios more complete, thus upgrading functionalities such as social recovery.

Implementation

Under the ERC-6551 standard, NFT holders can deploy a new smart contract, namely TBA, on the Ethereum network or other EVM-compatible blockchains by interacting with the Register Contract. The ownership of TBA belongs to the NFT holder and will change 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 of the Implementation Contract.

The following illustration demonstrates how ERC-6551 works: Suppose a user is the holder of an NFT, and their User Account owns NFT #123 of Contract A and NFT #456 of Contract B. The User Account interacts with the permissionless registry, i.e., the Register Contract, inputs the NFT information and the address of the Implementation Contract, thereby creating TBA. When the User Account calls the Register Contract, it inputs the NFT information for Token #123 and the address of Implementation A (0x321 …), and the contract wallet Account A (0x123 …) will be created. Its ownership belongs to the holder of NFT Token #123, and its functionalities and rules are derived from the provisions of Implementation A. When the User Account calls the Register Contract again and changes the input, another TBA will be generated. However, for a specific NFT and Implementation Contract, only one unique corresponding TBA can exist.

The creation and behavior of TBA entirely depend on the Register Contract and the Implementation Contract. The rules within these contracts determine the characteristics and functionalities of TBA. EIP-6551 provides code templates for these contracts. We will delve deeper into these templates in subsequent sections. However, these templates are not the only options; their code determines how TBA is deployed and how functionalities are realized. This offers developers extensive possibilities for expansion. For example, the Register Contract can set which NFTs are eligible to use the contract for registration. The Implementation Contract can define the functionalities and rules of TBA, such as setting a daily transaction limit for TBA or specifying the types of assets it can hold.

Implementation Contract

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

executeCall(): A function used to execute any smart contract function that interacts with external contracts. For example, to sell the assets contained in the account bound to the NFT, you may need to call a function in the Uniswap contract.

• executeCall() allows you to make that 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 owned by this token-bound account. It returns the chain ID (whether the NFT is on the mainnet, Polygon, Optimism, etc.), the NFT contract address, and the NFT token ID.
• owner(): Returns the address of the owner controlling the NFT of this token-bound account. In the above example, this would be the address of the User Account.
• nonce(): Returns the current nonce of this smart contract wallet. Each successful transaction increments the nonce by 1, starting from an initial value of 0.

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

Register Contract

Below is the Registry smart contract written in Solidity:

This code indicates that the parameters required to create an account for a specific NFT include the implementation() contract address, chainId() target chain ID, tokenContract() corresponding NFT contract, tokenId() corresponding NFT ID, and a salt for obfuscation. According to the Fast Dapp demo, creating an NFT account only requires inputting the NFT contract address and ID, while the other fields are automatically generated, making the process relatively simple.
The ERC-6551 proposal is a brand new token standard, representing a disruptive upgrade to the original NFT standard. ERC-6551 utilizes a permissionless registry that is compatible with existing ERC-721 NFTs. This registry is a smart contract that serves 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 diminished, leading to a decline in the value of many top projects. However, NFTs with high interactivity and composability may be key to the market's recovery. From blockchain games, music, DID to the metaverse, these fields are filled with endless potential.

NFTs are not just assets; they also possess their own on-chain identity and container attributes, enabling interaction with decentralized applications (Dapps). This means that all interactions with NFTs will be directly recorded on the NFTs themselves, rather than on their holders' accounts. Furthermore, since NFTs are based on smart contracts, their behaviors and interactions can be defined and controlled through contract rules, providing flexibility and security.

The ERC-6551 protocol brings revolutionary changes to the NFT space, shifting the focus from user wallets to the NFTs themselves, offering 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 include multiple artwork NFTs. This not only systematizes collections but can also reduce gas fees during transactions.
• Portfolio: NFTs can act as asset management tools, allowing users to store and manage various tokens within a single TBA. Additionally, NFT holders can authorize third-party managers to trade assets and clearly define the managers' permissions in smart contracts, ensuring asset security.
• NFT Identity Management: NFTs can record all their on-chain activities, making them a true on-chain identity. Users can represent themselves with a single ENS wallet and use different TBAs to represent their roles in different communities or applications.
• Modular NFTs: Main NFTs can generate TBAs for storing their component NFTs. For example, in a game, a character NFT may be equipped with various equipment NFTs. This not only makes the realization of the metaverse more feasible but can also combine with AI to create more realistic NPC characters.

In summary, the future of NFTs is filled with infinite possibilities. From asset management to identity verification, to modular game design, they will play a key role in the digital world.