The brief history of NFT standarts
Everything started with the ERC-20 standard, introducing fungible tokens such as BNB or USDT in 2015. But this standard doesn't allow creation of unique tokens. This innovation took a lot of time.
Check out our website and please join our community!
In January 2018, ERC-721 was introduced by Dieter Shirley, William Entriken, Jacob Evans, Nastassia Sachs, and Benny Giang. It is appropriately the leading standard of a unique token today. With this standard, it is possible to trace all transactions around the NFT, from its transfer between owners to its current value on the market. Even though ERC-721 standard is built on the principle of the ERC-20 standard, the critical difference is ERC-721 standard comes with a transaction history.
Later in June 2018 the EIP-1155 was proposed. Unlike the ERC-721 standard, which allows creation and transfer of a single token at a time, the ERC-1155 standard allows faster creation and transfer of a multitude of tokens at the same time. It was often called the "next generation of multi-token standard". This standard deployed by Enjin simultaneously brings together fungible and non-fungible tokens. Currently, based on public data, ERC-721 is 10x more popular than ERC-1155 (based on data from Polygon and Binance total contracts data).
Next, 2020 year marked the emergence of Dynamic NFTs, which revolutionized the technology in the NFT industry. dNFT is a form of ERC-721 integrated with 3rd party infrastructure, allowing to update NFTs according to custom rules. Chainlink boosted dNFT for games providing its oracles as 3rd party infrastructure. Also, such noteworthy projects as Owl Protocol, OG Protocol, and Pandora are building infrastructure for dNFTs applications. For example, Owl Protocol is building a workshop for Dynamic NFTs that allows anyone to create, deploy, and manage engaging NFT utilities and mechanics such as crafting, combining, breeding, lootboxes, and more.
And recently (again 3 years later), Benny Giang and Steve Jang introduced the new Ethereum Proposal - EIP-6551 (token bound accounts). Benny also was part of the team that established the ERC-721 standard and contributed to creating CryptoKitties.
But what is ERC-6551?
In one sentence, ERC-6551 (a token bound account) is "an interface and registry for smart contract accounts owned by ERC-721 tokens" — linking smart contract accounts (and wallets) to the NFTs that own them.
Additionally using ERC-4337, smart accounts allow users to personalize their experience by storing assets and making transactions. Additionally, token-bound accounts provide a secure and transparent record of all on-chain activities that cannot be altered.
It's easy to grasp the concept of "what it is" by analyzing potential use cases and examples. For instance, we can contrast the experiences of a Web3 Fund Manager before and after the integration of ERC-6551.
Web3 Fund Manager Life Before ERC-6551
John is a savvy investor who has created an automated investment portfolio composed of multiple fungible assets, including ETH, DAI, and UNI. He uses a smart contract to manage his portfolio, automatically rebalancing his holdings based on predefined rules.
When John decides to sell his automated investment portfolio, he has to manually transfer each asset to the new owner. The new owner does not receive any transaction history or other information related to the portfolio, such as past rebalancing actions or yield earned.
Web3 Fund Manager Life After ERC-6551
John mints an NFT representing his automated investment portfolio. With the implementation of ERC-6551, a unique Ethereum account is bound to this NFT, effectively giving it its own wallet. All the assets in his portfolio, including ETH, DAI, and UNI, are held by the NFT's bound account.
The smart contract managing the portfolio operates on behalf of the NFT, performing actions such as rebalancing and yield farming. All transaction history and other information related to the portfolio are associated with the NFT's bound account.
When John decides to sell his automated investment portfolio, he simply transfers the NFT. The new owner receives the NFT along with all associated assets and the entire transaction history. This provides a complete record of the portfolio's performance and actions, offering total transparency to the new owner.
Why could it be a game changer?
The standard set by ERC-721 has made NFTs more accessible and opened up various possibilities for digital assets on the blockchain. However, these NFTs have certain limitations:
- Their primary use is to show proof of ownership for assets on or off the chain.
- They are mainly static and cannot be modified in any way, which may restrict innovation.
- They cannot act as on-chain agents and interact with other assets or contracts independently.
- Due to their static JSON metadata, they need more flexibility in maintaining Uniform Resource Identifier codes, security, and efficiency.
However, the introduction of ERC-4337 and ERC-6551 can change this and enable NFTs to be more than just static assets while retaining the advantages of ERC-721. Moreover, merging these technologies with dNFTs could also significantly increase flexibility and boost NFT adoption across various use cases, for example:
- For RWA: create a car NFT which owns each critical part of the car for sale as a standalone NFT. Now you can sell the whole car as one transaction with all associated components.
- For Games: you can buy and sell all achievements and inventory of a character. dNFTs could help here with off-chain tournament results.
- For Indentifiactions: with token bound accounts, NFTs can now own wallets and their assets, allowing for the creation of on-chain identities and reputations. These NFTs can interact with dApps independently from the wallets that hold them.
- For DeFi Lending: credit scoring could become much more accessible. You could create a single account that owns everything relevant to your credit scoring (DAOs participations, Pools participations NFTs, other Lending NFTs), aggregating information from different dApps.
This is just a tiny piece of the puzzle. The Web3 community is known for their creativity and will likely come up with fresh ideas in no time.
Current examples of ERC-6551 implementation
Stapleverse was the first to utilize ERC-6551 in a large-scale project, introducing the future of digital street culture with the launch of Sapienz. This groundbreaking project featured token-bound accounts, setting a new standard in the industry.
In Sapienz, users are given a customizable character to modify using cosmetics. These cosmetics can be unlocked by holding certain NFTs. Once unlocked, the cosmetics become attached to the user's Sapienz, which has its own inventory in the form of token bound accounts.
FuturePrimitive has built Tokenbound - a suite of open-source tools that allow developers to easily integrate ERC-6551 accounts into their applications.
Other enthusiasts have started to build the first self-made projects. Check this great tweet about the Garage project.
Technical and security challenges
Now, let's shift our focus to some nerdy topics. First of all, the current status of EIP-6551 is DRAFT which means it could be changed in the future, and you should use it carefully.
The system outlined in this proposal has two main components:
- A permissionless registry for deploying token bound accounts
- A standard interface for token bound account implementations
The following diagram illustrates the relationship between ERC-721 tokens, ERC-721 token owners, token bound accounts, and the Registry.
The Registry serves as a single entry point for projects wishing to utilize token bound accounts and has several essential requirements:
- The Registry SHALL deploy each token bound account as an ERC-1167 minimal proxy with immutable constant data appended to the bytecode in the structure presented in EIP.
- Each token bound account proxy SHALL delegate execution to a contract that implements the IERC6551Account interface.
- The Registry SHALL deploy all token bound account contracts using the create2 opcode so that the account address for every ERC-721 token is deterministic.
- The Registry SHALL implement the IERC6551Registry interface presented in the proposal.
Account interface requires:
- All token bound accounts SHOULD be created via the Registry.
- All token bound account implementations MUST implement ERC-165 interface detection.
- All token bound account implementations MUST implement ERC-1271 signature validation.
- All token bound account implementations MUST implement the proposed IERC6551Account interface.
After analyzing the proposal, we have identified several technical and security challenges:
1.Backward Compatibility
Numerous articles claim that ERC-6551 is entirely compatible with any ERC-721 implementation. However, this statement is only partially accurate. The EIP-6551 mentioned that non-fungible token contracts that do not implement an ownerOf method, such as Cryptopunks, are incompatible with this proposal in one click.
2.Usage of Proxy
Adding a new layer of delegation and complexity increases the attack surface.
3.Potential frauds
The most common scenario will be when an account holder withdraws assets from a token-bound account before selling the token. The EIP-6551 recommends solving this problem on a marketplace level. But this could substantially slow down the adoption of ERC-6551, if marketplaces like OpenSea decide to not spend additional resources on anti-fraud mechanics like:
- linking the current token bound account nonce or a list of asset commitments to the marketplace order.
- submitting orders via an external smart contract that validates the order signature
- implementing a locking mechanism that prevents asset extraction from the account while locked
This is a great area for 3rd party providers and auditors to come up.
4.Ownership infinity cycles
If a token-bound account contains an ownership loop, like transferring a ERC-721 token to its own account, all assets in the account may become unreachable. This poses a difficult challenge in preventing such loops as it requires an infinite search space. Sadly, the responsibility of solving this issue falls on the application developers, which may reduce its adoption among users.
To sum up, ERC-6551 demands careful attention in its implementation compared to the traditional ERC-721. Having a reliable smart contract security partner while updating or constructing your Web3 project is essential due to the constantly evolving Solidity environment. We are here to assist you in navigating these challenges. Let's discuss further and stay updated by joining our Twitter and Telegram!
Check out our website and please join our community!