Interpretation of the latest Final ERC-6147: A minimalist semi-mandatory NFT ownership separation standard

Author: Shisi Jun

On March 7, 2023, the Ethereum Improvement Proposal EIP-6147 proposed by 10K Universe has been moved to the final version!

This standard is an extension of ERC-721, separating the ownership and transfer rights of NFTs and SBTs, and defining a new "Guardian" role that can set expiration times, making NFTs more flexible for anti-theft, lending, leasing, and SBTs.

This article will systematically discuss the implementation mechanism of ERC-6147 and compare it with previous NFT leasing protocols such as ERC-4907 and ERC-5055, to comprehensively analyze and comment on this protocol and its suitable application scenarios!

1. Background

NFTs have become a well-discussed topic, leveraging the immutable characteristics of the blockchain and the automated operation of contracts to achieve on-chain asset confirmation and management. I have also written several articles on standard protocols, leasing expansion protocols, and various mainstream models of NFT trading markets.

If we were to argue the advantages of NFTs, it could fill several pages, but to argue their disadvantages, it can be summed up in one word: liquidity!

Of course, you might question how the dilemma of insufficient liquidity relates to the implementation of property separation standards?

In my view, the liquidity dilemma of NFTs does not primarily stem from the NFT protocol itself, but rather from the non-fungible mechanism of IDs and the limited ID range. Even the nearly infinite ERC20 tokens can lack liquidity, right? More importantly, liquidity itself arises from the pricing demands of financial products; how to give NFTs intrinsic value becomes a protocol that relies on value rather than just market operations.

What affects the usage value of NFTs is also the NFT protocol itself.

1.1. Property Coupling: High-value NFTs Tend to Favor Safe Havens

Currently, there are many cases of NFT theft, yet existing anti-theft solutions, such as transferring NFTs to cold wallets, make their use inconvenient.

Moreover, in current NFT lending, NFT owners need to transfer their NFTs to the NFT lending contract, losing their usage rights during the lending period. This is a property coupling issue, which is quite different from the situation in real life where purchasing property does not require the owner to relinquish their usage rights when mortgaging for liquidity under non-risk conditions.

A recent memory is the attack during the APE airdrop, where attackers used flash loans combined with NFTX to execute the attack.

For further reading on the incident analysis: Can EIP-5058 Prevent NFT Projects from Running Away?

In this entire incident, the only ones harmed were the users who staked their monkeys, who lost out on a massive airdrop while trying to earn a meager time interest.

Similarly, the property coupling issue also applies to SBTs.

For SBTs, the mainstream view currently holds that SBTs are non-transferable, which binds them to Ethereum addresses. However, when a user's address private key is leaked or lost, recovering the SBT becomes a complex task without corresponding standards. SBTs essentially achieve the separation of NFT ownership and transfer rights. When the wallet holding the SBT is stolen or becomes unavailable, the SBT should be recoverable.

For example, if a university issues SBTs based on diplomas to its graduates, and later discovers that a graduate has committed academic misconduct or harmed the university's reputation, it should have the ability to revoke the SBT for that diploma.

1.2. Property Separation Cases: Controlling the Mandatory Dimension is Challenging

In the past, I have interpreted several attempts at property separation solutions, such as ERC-4907 and ERC-5058. The biggest challenge is inevitably measuring the degree of enforceability; this is not an issue with the solutions themselves, but rather a philosophical issue inherent in the solutions.

1.2.1. Simple Philosophy of ERC-4907: Defining Vision and Leaving the Rest to Consensus

In July 2022, the NFT leasing market Double Protocol submitted the rentable NFT standard "EIP-4907," which passed the final review by the Ethereum development team, becoming the 30th ERC standard to achieve "Final" status.

The code is extremely simple, consisting of only 72 lines, and using this standard adds:

• 1 event (to notify off-chain applications)
• 3 methods (to implement on-chain data management functions)

In principle, 4907 simply adds a data object UserInfo, introducing the dimension of "user" beyond the concept of ownership. However, its enforceability is limited; as long as the NFT is transferred, the rental authorization can be forcibly terminated.

For further reading:

• Interpretation of the 721 leasing protocol: How Does Ethereum's New Standard EIP-4907 Achieve NFT Leasing?

• Interpretation of the 1155 leasing protocol: NFT Leasing Proposal EIP-5006 Enters Final Review!

1.2.2. Zero-Trust Philosophy of ERC-5058: Code is Law

It essentially manages the locked state of NFTs, allowing project parties to provide locking and transferring functions in NFT projects that inherit 5058, and can also implement more functions such as royalties.

It encapsulates several methods: only after user permission and project party execution will it be fully locked.

Users can call:

• lockApprove (authorize locking a single NFT)
• setLockApprovalForAll (authorize locking all NFTs under that address)

Project party contract calls:

• lockFrom (lock a user's NFT)
• unlockFrom (unlock a user's NFT)

The definition of the locking period is also highly enforceable, almost solely based on the initial set time.

When a project party (third party) locks an NFT, it must specify the block height at which the lock expires, which must be greater than the current block height. Once the lock expires, the NFT is automatically released and can be transferred.

The project is still in draft stage, possibly due to the high enforceability and the high costs of mutual operations between users and project parties.

For further reading: Can EIP-5058 Prevent NFT Projects from Running Away?

Having discussed the non-enforceable 4907 and the fully enforceable 5058, we arrive at the theme of this article: the latest ERC-6147, which has passed the Ethereum Foundation's review and is confirmed as Final. Although its original title is: "Guard of NFT/SBT, an Extension of ERC-721," based on my series of leasing research experiences, it should be more aptly called "Semi-Enforceable NFT Property Separation Standard."

2. Operation Mechanism of ERC-6147

The overall code of this protocol is also very concise and highly reusable, belonging to the extension standard of ERC721. However, it is important to note that if it is used, the transfer operation may differ from the conventional 721 logic, and improper operation may easily lead to phishing. Let's discuss how.

For further reading: 【Source Code Interpretation】What Exactly is the NFT You Bought?

2.1. What is Guard? Who Can Control It?

First, ERC-6147 defines a role called Guard, which is quite similar to the UserInfo in 4907.

Only the current owner address of the NFT and addresses with withholding permissions can set the Guard through changeGuard. The source code shows several details when setting the Guard to prevent accidental locking, so the Guard cannot be set to the zero address.

Once set successfully, anyone can query the current Guard information for a specific NFT ID through the guardInfo method. It also adopts a timestamp-based design similar to 4907, so it can automatically expire without a second on-chain transaction. Who can remove the Guard's identity? Only the Guard themselves and time (expiration) can.

2.2. What Can Guard Do?

First, it has the right to enforce transfer. For NFTs with a set Guard, when performing transferFrom, it will check whether the transaction initiator is the Guard address; only then can the transfer occur.

? Please pay special attention 1:

For NFTs with a set Guard, the original holder will only have ownership rights and no transfer rights (i.e., usage rights). Other DApps can still query that the original user is the owner of this NFT, but the original user cannot initiate a transfer.

Therefore, for NFTs with a set Guard, signatures on trading platforms like OpenSea and X2Y2 are valid (but actual transfers cannot occur because protocols like Seaport execute transfers through withholding authorization).

For further reading on the trading market operation mechanism:

• X2Y2's 100,000 NFT Orders: Analyzing How Many Users Actually Did Not Collect Royalties?

• Explaining the Newcomer in the NFT Market: SudoSwap's AMM Mechanism - Innovations, Challenges, and Limitations

• 【Contract Interpretation】CryptoPunk: The World's First Decentralized NFT Trading Market

? Please pay special attention 2:

If the Guard directly transfers the NFT using the native transferFrom or safeTransferFrom methods, the Guard setting will not be automatically cleared. Of course, if the Guard transfers the NFT to themselves, that is fine, but if they transfer it to another user, they can use the Guard's setting to transfer it again.

Therefore, if you subsequently use the Guard, it is more important to verify whether the transferAndRemove method is used. This method will directly clear the Guard information after the transfer.

Moreover, the Guard essentially represents a higher degree of control, similar to a house lease; at the moment of mortgage, it essentially belongs to the bank, but the bank will only execute actions like auctions under certain social conditions (such as default). Since it is a type of financial collateral, the Guard's rights can also be transferred using the changeGuard method.

The design principle of transferRemove is to adapt to different scenarios.

For example, in anti-theft situations, if the NFT is in a hot wallet and the hot wallet is stolen, but the cold wallet remains safe, it is sufficient to transferFrom to another secure address.

Or during leasing, the Guard can call transferFrom to transfer to a new leasing address, achieving the lease.

Additionally, for social recovery of SBTs, transferring the SBT to a new address does not affect the non-transferable nature of the SBT.

2.3. What Can Guard Not Do?

From the source code, it can be seen that the Guard can only be set by the holder and the Approve authorizer at the time of granting, but the Guard cannot set withholding.

On one hand, this is because there is no need to consider the withholding authorizer anymore, as the transfer rights of the NFT are essentially restricted to the Guard. On the other hand, the Guard cannot set Approve to prevent scenarios where the user, after returning the transfer rights, uses approve to transfer the NFT away, which would violate the original intent and be difficult for the user to detect.

3. Conclusion

Let's present an overview of the types of NFT assets on Ethereum filled with financial attributes and a bit of worldly statistics.

With over 300,000 NFT transactions daily and more than 200,000 various NFT contracts, these totals reflect the financial value brought about by asset confirmation.

However, at any time, financial attributes need to gradually rely on intrinsic value. We can see NFTs confirming social relationships through Lens, NFTs serving as game assets in various Gamefi, and content creation leveraging crowdfunding through Mirror.

In just over 8 years since Ethereum's inception, the total number of EIP proposals has reached over 6,500.

Compared to the equally significant 4907, 6147 is more focused on optimizing compatibility.

For instance, in 4907, the user role requires active recognition from the project; if a game does not consider the user role and only considers the owner, 4907 is not applicable. However, 6147 only requires recognition of the owner, regardless of whether the game project and NFT itself support leasing. Currently, most application protocols still only recognize the owner, which is also why 4907 has not significantly changed the status quo since its inception; only by adapting to the trends of the times can it gradually shine.

Additionally, 6147 introduces the concepts of "manageable SBTs" and "effective SBTs." Current SBT proposal designs focus too much on the "non-transferable" characteristic proposed by Vitalik, while neglecting potential management scenarios for NFTs, such as social recovery or reclaiming SBTs (for example, academic misconduct requiring degree revocation, or a DAO member causing harm in the community requiring revocation of their SBT permissions).