Glimpsing the Future of NFTs through the Upcoming EIP Proposal

Author: zf857.eth, R3PO

The full name of EIP is Ethereum Improvement Proposals, and anyone in the Ethereum community can create an EIP. The guidelines for writing Ethereum Improvement Proposals are provided in EIP-1. The creators of Ethereum Improvement Proposals are responsible for building consensus within the community and documenting differing opinions.

Historically, most creators of Ethereum Improvement Proposals are usually application or protocol developers, as submitting a high-level Ethereum Improvement Proposal requires strong technical skills. After initial review, EIPs are numbered sequentially and discussed through the review process shown in the figure below.

There are many types of EIPs, including Core, Networking, Interface, ERC, Meta, and Informational. Each category addresses different issues. The well-known ERC-20, ERC-721, and ERC-1155 belong to application-level standard protocols, and the vast majority of NFT industry applications revolve around these mainstream protocols.

EIPs serve as a chronicle of Ethereum, documenting all developmental threads from its inception to the present, while also possessing the foresight to predict the direction of the entire Ethereum ecosystem. A small change in an EIP may contain enormous opportunities that could disrupt the entire industry. This article will focus on EIPs related to NFTs that are currently in the Last Call and recent Final stages.

EIP-4955 Metadata Standard Extension

This EIP proposes to standardize the pattern of NFT metadata, adding a new field called namespaces to the JSON schema of EIP-721 and EIP-1155 standard NFTs. The main code is shown in the figure below:

EIP-4955 adopts a direct extension of EIP-721 metadata, with the idea of backward compatibility. This allows existing projects that cannot modify metadata responses (schema) to create a new smart contract that returns updated metadata schemas based on tokenId. Given that most projects on Ethereum use non-upgradable contracts, if this EIP requires a complete reimplementation of these contracts, it would necessitate redeployment, wasting both time and money. By utilizing the existing metadata fields of EIP-721, the number of necessary changes can be minimized.

Many projects require custom NFT attributes. Each project may have its own way of rendering NFTs, thus needing different metadata values. For example, metaverse projects like Decentraland or The Sandbox need different 3D models to render NFTs based on each project's visuals/engine. NFT projects like Cryptopunks and Bored Apes can create the required 3D models for each project.

With the new field namespaces, each project or vendor can directly call NFT assets through namespaces (as shown in the code above), allowing developers to avoid naming conflicts when using multiple NFT metadata within a single smart contract or application. The NFT metadata will enable wallets, marketplaces, metaverses, and other NFT-related applications to interoperate with any NFT.

This proposal is very useful for NFT markets that need to support multiple metadata schemas. Even if multiple sellers use different metadata schemas, this EIP will allow market operators to ensure that metadata keys are unique while freely storing specific JSON data. The proposed solution can even have broader applications, such as in large GameFi and metaverse scenarios where numerous NFTs can present different attributes through custom metadata, while avoiding naming conflicts, greatly enhancing the interoperability of NFTs.

NFT Leasing Use Extension from EIP-4907 to EIP-5006

EIP-5006 is a proposal put forward by the NFT leasing market Double Protocol, targeting a leasing standard for ERC-1155 type NFTs. This standard is an extension of the ERC-1155 standard. The proposal suggests adding an additional new field user in the NFT metadata, which can be granted the address of the asset user instead of the owner.

As early as June 29 last year, EIP-4907, also launched by the NFT leasing market Double Protocol, was officially approved by Ethereum, becoming the first ERC standard for rentable NFTs. EIP-4907, as an extension of ERC-721, adds a UserInfo variable that includes the user address and the user expiration time (userExpires). When the time exceeds the rental period, the rental relationship is terminated. The main code is shown in the figure below:

Unlike the simple extension of EIP-4907 for ERC-721, EIP-5006, based on the special data structure of ERC-1155 (which itself is a multi-token management standard, allowing its ID to correspond to multiple addresses and token quantities), adds UserRecord and usableBalance functions for convenient batch management of leasing statuses. The main code is shown in the figure below:

Core Value of EIP-4907 and EIP-5006 Standards

Both ERC-721 and ERC-1155 standard tokens require this new utility. That is, the "user" of the token may differ from the owner of the token (as in leasing). Therefore, it is necessary to set different roles for "owner" and "user," so that the "user" cannot take actions that the owner can take (e.g., transferring ownership). The introduction of EIP-4907 and EIP-5006 clarifies the rights allocation of NFTs, which is beneficial for addressing the liquidity shortage of NFTs.

With the dual roles of "owner" and "user," the separation of ownership and usage rights of NFTs can be achieved, which is a key infrastructure for solving the liquidity shortage of NFTs, providing technical support for on-chain use cases such as leasing. It becomes very easy to manage what NFT lenders and borrowers can and cannot do with NFTs (in other words, their rights).

For example, regarding the right to transfer ownership, the project only needs to check whether the address taking that action is the owner's address or the user's address. If it is the user, the transaction is blocked. Additionally, the owner can control who the user is, and other projects can easily allocate their rights to the owner or user.

At the same time, based on permissionless interoperability, this standard makes it easier for third-party protocols to manage the usage rights of NFTs without needing permission from the NFT issuer or NFT application. Once a project adopts the additional user role, any other project can directly interact with these functions and implement their own transaction types.

For instance, PFP NFTs using this standard can be integrated into a leasing platform where users can rent NFTs for 30 days, while also being integrated into a mortgage platform where users can use NFTs and ultimately purchase ownership of the NFTs through installment payments. All of this can be done without needing permission from the original PFP project.

The introduction of EIP-4907 and EIP-5006 will undoubtedly further clarify the direction of expanding the application value of NFTs, leading to more diverse gameplay, application scenarios, and derivatives. For example, the popularization of renting NFTs will enrich the gameplay of the GameFi ecosystem and significantly improve capital turnover rates.

Massive foundational players in large GameFi projects like Axie, who can genuinely contribute online time, need a low-trust-cost method (non-mandatory transfer leasing) to rent equipment or resource rights in the game. Many NFTs will become more practical. For instance, virtual land in the metaverse can be "used," and NFTs representing game assets can be "used" in the game. In some cases, the owner and user may not always be the same.

An NFT owner may lease it to a "user." A "user" should be able to take actions on the NFT that differ from those of the "owner" (e.g., a "user" typically cannot sell ownership of the NFT). In these cases, having separate roles to identify whether an address represents the "owner" or the "user," and managing the permissions for executing actions accordingly, is very meaningful.

EIP-5007 Assigning Time Attributes to NFTs

This proposal suggests adding a new attribute to the ERC-721 token standard, including start time and end time. This makes time management for NFTs on-chain simpler and more efficient. Some NFTs have clear usage periods, during which they cannot be used.

For traditional NFTs that do not contain time information, if you want to mark a token as invalid or enable it at a specific time, you need to actively submit a transaction—this process is clearly both cumbersome and costly. Additionally, the inconsistent interfaces of time functions can pose difficulties for third-party development platforms. By introducing these functions (startTime, endTime), automatic enabling and disabling of NFTs on-chain can be achieved. The main code is shown in the figure below:

This functionality can also bring many new use cases for NFTs, such as access services mediated by NFTs or subscription content applications based on NFTs, as EIP-5007 will allow developers to automatically revoke access to services or content after a set period. Furthermore, the protocol's extension can also be applied to digital art or collectibles, where the value of NFTs may decrease over time. The ability to specify expiration dates can help prevent NFTs from becoming "stale" or devalued over time.

It is also worth mentioning that if the expiration date is not executed correctly, or if a malicious actor attempts to tamper with the expiration date field, the proposed solution may pose security issues. Therefore, we believe that additional measures may be needed to ensure the expiration date is executed correctly and that NFT owners are not unfairly locked out of their assets.

EIP-5496 Multi-Right Management Extension for NFTs

EIP-5496 proposes an extension to the EIP-721 token standard, allowing for multi-right management of NFTs. This proposal defines an interface that extends EIP-721 to provide rights that can be shared among multiple people. Rights can be on-chain (voting rights, permission to claim airdrops) or even off-chain (discount coupons for online stores, discounts at local restaurants, access to airport lounges).

Each NFT may contain many rights, and the holders of these rights can transfer them to others. Rights can be non-shareable or shareable. Shareable rights can be cloned and copied, and providers can adjust details based on the propagation path. Expiration dates can also be set for each privilege. The main code is shown in the figure below:

The specific rights data management process uses two structures for double nesting. First, PrivilegeRecord is defined, which stores the user address (address user) and expiration time (expiresAt) as two fields. Then, PrivilegeStorage is defined, which stores the latest expiration time (LastExpiresAt) and binds the rights ID to PrivilegeRecord using mapping.

This rights ID approach is very clever; once rights are identified by ID, verifying rights becomes very convenient. There is no need to match and verify rights word by word; you only need to verify the rights ID. The content of rights can change frequently, so placing rights content off-chain while keeping the rights ID on-chain means that when the project changes rights, it does not incur gas fees.

However, after rights are identified by ID, the issue arises that it is not intuitive to see what rights this NFT actually has. A third-party product may still be needed to create a separate rights content setting and query function to index the corresponding ID. The main code is shown in the figure below:
This protocol can achieve real-time and effective management of rights attached to NFTs. Many NFTs serve not only as profile pictures or art collectibles; they may have real utility in different scenarios.

For example, a fashion store may offer discounts to its NFT holders; DAO member NFT holders can vote on proposals regarding how to use their treasury; a DApp may create an airdrop event to attract a specific group, such as some blue-chip NFT holders to claim; grocery stores can issue their membership cards (as NFTs) on-chain, granting certain privileges when members shop at the grocery store, and so on.

As issuers empower rights to NFTs, there may be many possibilities, and NFT holders may not necessarily want to use their rights. The traditional EIP-721 protocol only supports recording the ownership and transfer process of NFTs, while the rights of NFTs are not recorded on-chain. The extension of EIP-5496 will allow merchants/projects to write rights on-chain, grant them to specific groups, and rights holders can independently manage each right, thus providing rights management capabilities for both the project side and holders, unlocking the value of NFTs in the utility of rights and promoting the possibility of large-scale practical applications of NFTs.

EIP-5606 Multiverse NFTs

EIP-5606 defines an interface to create a Multiverse NFT standard for digital assets (such as wearables and items in games) while allowing these assets to be indexed as delegated NFTs on each platform. These platforms can be metaverses, GameFi, or NFT markets. The standard also allows for "bundling" and "unbundling" of these delegated NFTs within the multiverse NFT, enabling holders to trade them individually or as bundles. The main code is shown in the figure below:
EIP-5606 introduces the concept of multiverse NFTs, representing a digital asset that spans multiple platforms. The multiverse NFT contract defines a new token that maintains the relationship between unique digital assets and their corresponding platform counterparts (EIP refers to them as delegated tokens).

The standard introduces the simple concept of bundles. A bundle is essentially a set of delegated NFTs identified by a unique ID number (multiverse token ID). The DelegateData structure contains information about the delegated NFT tokens on each platform. The variables it includes are: contractAddress, tokenId, and quantity, to distinguish NFTs (following ERC-721 or ERC-1155 standards).

The bundle and unbundle functions accept an array of DelegateData structures, as partial bundling and unbundling need to be accommodated. They also require individual token IDs of delegated NFTs so that only the owner of the multiverse NFT (or an address with the bundler role) can call the bundle function.

In the web3 ecosystem, NFTs have evolved to represent various types of unique and non-fungible assets. One type of asset includes a set of interrelated NFTs. For example, if a brand releases a new sneaker across different platforms, it will be minted as a separate NFT on each platform.

However, in reality, it is the same sneaker. The lack of cross-platform interoperability for NFTs has become an urgent issue to address. Creating a multiverse NFT standard that allows for indexing and ownership of digital assets across different platforms will be the first step toward achieving cross-platform interoperability and true ownership. In this direction, the EIP-5606 proposal is the first practical attempt to solve the interoperability of NFTs and "true" ownership across platforms.

EIP-6150 Hierarchical NFT Standard Emergence

EIP-6150 extends the EIP-721 protocol. It proposes a multi-layer hierarchical NFT structure similar to a file system. This protocol adds new interfaces for obtaining parent NFTs or child NFTs and determining whether an NFT is a leaf node or a root node, while maintaining the hierarchical relationships between them.

The so-called hierarchical relationships between NFTs mean that all NFTs will form a hierarchical relationship tree. Each NFT is a node on the tree, which can be a root node or a leaf node, as well as a parent node or a child node. The main code is shown in the figure below:

In this proposal, the Minted event is standardized to indicate the parent-child relationship when minting a new node. In each hierarchical tree, this proposal standardizes the function parentOf to query the parent NFT of a specified tokenId and the function childrenOf to query all child NFTs of a specified tokenId. This facilitates querying upper and lower nodes. Additionally, the functions isRoot and isLeaf can be used to check whether a specified tokenId is a root node or a leaf node in the entire NFT hierarchy tree.

It is also worth mentioning that this proposal meticulously adds three optional extension interfaces:

Enumerable Extension (IERC6150Enumerable)

This proposal standardizes three functions as an extension to support enumerable queries involving child nodes. Each function has a param parentId, which is set to 0 for compatibility, meaning querying the root node.

Burnable Node Extension (IERC6150Burnable)

The hierarchical relationship transfer extension (IERC6150ParentTransferable) supports cases where, for example, a directory or a file can be moved from one directory to another in a file system. Therefore, this proposal adds the ParentTransferable extension to support this situation.

Access Control (IERC6150AccessControl)

In a hierarchy, there are often multiple accounts authorized to operate on a node, such as minting child nodes, transferring nodes, or burning nodes. This proposal adds some standard functions to check access control permissions.

Currently, most NFTs are flat, with no associative relationships between different NFTs. However, hierarchical NFTs can link all NFTs together to form a tree structure, similar to a file system. Hierarchical NFTs can be used in various application scenarios, such as organizational structures, social relationship graphs, e-commerce product category structures, and hierarchical comment systems, etc.

It can be said that any scenario with a hierarchical structure can apply this EIP-6150 protocol standard. Hierarchical NFTs are likely to find widespread applications in decentralized social, decentralized e-commerce, and other fields. Within the Ethereum ecosystem, a single smart contract can serve as the root, managing each directory/category as a separate NFT and the hierarchical relationships of NFTs.

Each NFT's tokenURI can be another contract address, a website link, or any form of metadata. Only one contract is needed to manage and operate the hierarchical relationships. In the near future, with the development of Ethereum's data availability solutions and external permissionless data retention networks, on-chain companies for managing organizational structures will become possible, enabling fully decentralized applications.

The above is the latest content regarding Ethereum NFT protocols. As of the time of this writing, EIP-5007 and EIP-5496 are still in the Last Call stage, while EIP-4955, EIP-5006, EIP-5606, and EIP-6150 have moved from Last Call to Final stage.

Overall, the approval of these new protocols makes significant contributions to the innovation and practicality of NFTs. NFTs have now moved past the PFP stage, and the journey of Web3 is vast and boundless, with innovation constantly unfolding. What will trigger the next narrative for NFTs? From these protocols, we can glimpse that the future of NFTs is increasingly heading toward a more practical and application-oriented direction.

In the near future, NFT technology itself will change games, insurance, real estate transactions, paid advertising, voting, social platforms, video media… every aspect of our lives. NFTs will not just be a "part" of crypto. In the coming years, they may become the only practical application in the crypto space closely related to the real world.