Analyze the three popular Ethereum standards: EIP-6969, ERC-721C and ERC-6551

Every standard has the potential to form or change a business.

Written by: David

In the past week, we have seen at least 3 intensively discussed Ethereum-related standards from various sources. These standards are EIP-6969, ERC-721C, and ERC-6551, each with a different purpose and potential impact.

Every standard has the potential to form or change a business, so its importance is self-evident. Knowing ahead also helps to spot new trends and trends at the moment.

However, one of the characteristics of the encryption world is that the information is too fragmented and sudden, coupled with limited energy, you may not be able to deeply understand the technical characteristics of each standard and its possible impact. Therefore, Deep Tide aims to summarize, interpret and compare these standards, and lead you to understand them comprehensively in an easy-to-understand manner.

1.EIP6969: Good for smart contract creators and L2 ecology?

EIP-6969 is a proposal that first appeared around May 8th. It proposes a general protocol designed to achieve contract protection revenue (CSR). This proposal can be seen as an improved version of the previous EIP-1559.

In other words: the protocol hopes to allow creators of smart contracts to get a share of the gas fees generated by users using the contracts.

The co-author of the proposal @owocki also mentioned that he hopes to use this mechanism to motivate smart contract developers to promote the development of the Ethereum L2 ecosystem, while Ethereum's L1 does not want to implement this proposal in order to maintain L1 neutrality.

The author's interpretation is that if this incentive mechanism can be implemented in Ethereum L1, there will inevitably be a lot of smart contracts that want to generate volume, which will cause congestion. Overall, the disadvantages outweigh the advantages, so it may be a better choice to put it on L2.

However, to fully understand this EIP-6969 proposal, it is necessary to understand the operating principle and composition of Ethereum's current gas fee. This involves the previous EIP-1559.

EIP-1559 and the London hard fork of Ethereum took effect in August 21, stipulating that the transaction fees paid by users have different destinations:

1. Burn: A portion of transaction fees in each block will be burned. This portion of the fee is permanently removed from the supply, reducing the total supply of ether.
2. Base Fee: A portion of the transaction base fee paid by users will be distributed to miners as block rewards. In EIP-1559, a portion of the base fee is rewarded to miners for continued participation in block creation and transaction processing.
3. Max Priority Fee: The maximum priority fee paid by the user is as part of the additional fee. This part of the fee goes directly to the miners as their transaction rewards. The maximum priority fee is actively set by the user, which can be used to increase the processing priority of the transaction, thereby attracting miners to process the transaction first.

Obviously, EIP-1559 does not really consider the interests of contract developers. In fact, Ethereum is a public chain, and you can regard the supply side as two parts:

• Verifier (original miner) + contract developer. The former essentially provides a credible ledger, while the latter provides a variety of applications. Therefore, it is reasonable to give the latter a share of the pie in theory.
• If EIP-6969 can be real-time, then the gas fee may be broken down into: burning + base fee + priority fee + fee paid to the contract developer.

In summary, there are connections and differences between EIP-6969 and EIP-1559. EIP-1559 is a protocol improvement proposal focusing on the transaction fee mechanism, which aims to provide more stable and predictable transaction fees and manage network congestion. Similarly, on the basis of maintaining the advantages of EIP-1559, EIP-6969 further aligns the incentive mechanism between the contract creator and the network by introducing the contract creator's revenue mechanism, and promotes the participation and reward of the contract creator.

We can use the following table to clearly show the function and impact of EIP-6969, as well as its origin with EIP-1559:

Note that we believe that the main risk of this new protocol is that if developers of incentive contracts can receive gas fees, will it lead to more garbage contracts? Therefore, there are actually contract security risks and the risk of occupying public resources on the entire public chain.

2. ERC-721C: On-chain NFT royalties

ERC-721C was proposed by Limit Break, which is an improvement to the ERC-721 non-fungible token (NFT) standard on Ethereum. Its primary goal is to give NFT creators more control and customization over their NFT collections and how royalties are handled.

*Deep Tide Note: Limit Break is a free game development studio that introduced the concept of Creator Token in January 2021. Version 1.1 of the ERC721-C standard will go live in May 2023, which implements many of the creator token concepts. @huntersolaire_ also tweeted out the details of the standard. *

Limit Break's official "Creator Token Transfer" library shows that ERC721-C is currently available on Ethereum and Polygon. It is also supported on Ethereum’s Sepolia testnet and Polygon’s Mumbai testnet.

From the name of Creator Token, ERC721-C is obviously more for creators, so this agreement is more about the protection of royalties.

Speaking version: Under the current ERC-721 standard, royalties are actually just a commercial agreement, not enforceable on the chain. ERC-721C was proposed to solve this problem, making royalties a smart contract rule that can be enforced on the blockchain.

With ERC721-C some possible uses include:

1. Shared royalties: Instead of letting NFT creators get all NFT royalties alone, they can be distributed to NFT creators and holders to reward early adopters.
2. Only minters have royalties: NFT miners can be the only royalty earners, not the creators themselves.
3. Conditional royalty payment: Whether to pay royalties for certain NFT transactions can be determined according to different conditions. For example, an ERC-721C contract could be configured so that royalties are only paid if the secondary sale price is higher than the original minting price.
4. Transferable royalties: NFT creators can issue an independent NFT to the holder, granting the holder the right to royalty income. For example, when one mints "NFT X", an NFT named "NFT Y" is also issued, which is entitled to all royalties generated by "NFT X".

The introduction of ERC-721C will have an important impact on the NFT industry:

1. Provides greater creator control: ERC-721C increases creator control over their NFT designs and makes royalties an on-chain enforceable contract rule, bringing greater autonomy and Protection.
2. Promote fair royalty distribution: Through the programmable royalty function, creators can design different royalty distribution mechanisms, such as the example above.
3. Reduce the influence of the market platform: Since the royalty logic is embedded in the smart contract, the creator will be able to directly control the royalty setting, reducing the control and intervention of the market platform on the royalty.

A table summarizing ERC-721C:

3.ERC-6551: When NFT is also an account

ERC-6551 enhances the functionality and value of NFT by empowering NFT smart contract wallets.

The co-author of the protocol is @BennyGiang, a founding member of Dapper Labs, a team that has worked on the ERC-721 token standard and early projects such as CryptoKitties.

The problem with regular ERC-721 NFTs is their limited scope. They can only be owned and transferred, not other assets such as tokens or other NFTs. Additionally, they cannot interact with other smart contracts, nor can they change or evolve in response to external factors or user input.

ERC-6551 addresses the functional limitations of regular ERC-721 NFTs by introducing the concept of smart contract wallets for NFTs. Through the combination of registry and proxy contract, NFT itself can hold other assets, interact with other smart contracts and accounts, and achieve richer functions and interactivity.

Therefore, you can specifically understand that the token (NFT) following ERC-6551 will operate as a smart contract wallet. This means that ERC-6551 can hold and trade tokens and other NFTs like ordinary smart contract wallets, and can interact with other smart contracts and accounts such as decentralized exchanges (DEX), lending platforms, game environments, etc. interact.

This way of operating NFTs as smart contract wallets results in so-called "Token-Bound Accounts" (TBAs), which are created via permissionless registries compatible with existing ERC-721 NFTs. and management.

To briefly summarize, the possible benefits and problems of ERC-6551 are:

EIP and ERC, stupidly confused?

After writing this, I still think of an old-fashioned question, what is the difference between EIP and ERC?

Both EIP (Ethereum Improvement Proposal) and ERC (Ethereum Request for Comments) are proposal standards related to Ethereum, but they do have differences.

EIP is an improvement proposal standard for the Ethereum network, which is used to describe proposals for improvements and new features to the Ethereum protocol. Once the EIP is adopted and agreed to, it will become part of the Ethereum protocol and be implemented on the Ethereum network. EIP describes changes at the protocol level, such as improving blockchain mechanisms, virtual machine rules, consensus algorithms, etc.;

In contrast, ERC is Ethereum’s token standard used to describe the interface and functionality of token contracts. ERC defines basic standards for token contracts to ensure the interoperability of tokens on the Ethereum network. ERC is a specification for token contracts, describing functions such as token transfer, balance query, and metadata.

Therefore, although both EIP and ERC are standardization mechanisms of the Ethereum community, they focus on different areas. EIP focuses on the improvement of the protocol level, while ERC focuses on the standardization of token contracts. Therefore, EIP will not directly transform into ERC, they are independent concepts.