Peeking into the Future of NFTs through the Upcoming EIP Proposal
TechFlow Selected TechFlow Selected
Peeking into the Future of NFTs through the Upcoming EIP Proposal
This article will focus on EIP proposals related to NFTs that are in the Last Call and recent Final stages.
Navigating Web3 tides with focused insightsAuthor: zf857.eth, R3PO
EIP stands for Ethereum Improvement Proposal. Anyone in the Ethereum community can create an EIP. Guidelines for writing EIPs are provided in EIP-1. The creator of an Ethereum Improvement Proposal is responsible for building consensus within the community and documenting dissenting opinions.
Historically, most EIP creators have typically been application or protocol developers, as submitting high-level EIPs requires strong technical expertise. After initial review, EIPs are sequentially assigned a number and undergo the approval process shown below:
There are several types of EIPs, including Core, Networking, Interface, ERC, Meta, and Informational—each addressing different issues. Well-known standards such as ERC-20, ERC-721, and ERC-1155 are application-level protocols, and the vast majority of current NFT industry applications revolve around these mainstream protocols. EIPs are like a chronicle of Ethereum’s development, recording every major milestone since its inception and also providing foresight into the future direction of the entire Ethereum ecosystem. A small change in an EIP could contain enormous potential to disrupt entire industries. This article focuses on NFT-related EIPs currently in the Last Call and recently finalized stages.
EIP-4955 Metadata Standard Extension
This EIP proposes standardizing the schema for NFT metadata by adding a new field called "namespaces" to the JSON schema of EIP-721 and EIP-1155 standard NFTs. The core code is shown in the image below:
EIP-4955 directly extends EIP-721 metadata with backward compatibility in mind. This allows existing projects that cannot modify their metadata response (schema) to deploy a new smart contract that returns updated metadata schemas based on tokenId. Given that most projects on Ethereum use non-upgradable contracts, requiring a complete reimplementation would necessitate redeployment—an expensive and time-consuming process. By leveraging existing EIP-721 metadata fields, this proposal minimizes required changes.
Many projects require custom NFT attributes. Each project may render NFTs differently, thus needing distinct metadata values. For example, metaverse projects like Decentraland or The Sandbox require different 3D models to render NFTs depending on their visual engines. Projects like Cryptopunks or Bored Apes can generate the necessary 3D models tailored to each platform.
With the new "namespaces" field, each project or vendor can directly invoke NFT assets via namespaces (as shown in the code above), allowing developers to avoid naming conflicts when using multiple NFT metadata formats within a single smart contract or application. Furthermore, NFT metadata will enable wallets, marketplaces, metaverses, and other NFT-related applications to interoperate seamlessly with any NFT. This proposal is particularly useful for NFT marketplaces supporting multiple metadata schemas—even if sellers use different formats, the marketplace operator can ensure metadata keys remain unique while freely storing specific JSON data. The proposed solution has even broader applications: large-scale GameFi and metaverse ecosystems can use customized metadata to represent various NFT properties without naming conflicts, greatly enhancing NFT interoperability.
NFT Rental Extensions: From EIP-4907 to EIP-5006
EIP-5006 is a proposal introduced by the NFT rental marketplace Double Protocol, establishing a rental standard for ERC-1155 NFTs—a direct extension of the ERC-1155 standard. It suggests adding an additional "user" field in NFT metadata, allowing a designated address to act as the user of an asset without being its owner.
As early as June 29 last year, EIP-4907—also launched by Double Protocol—was officially approved through Ethereum's review process, becoming the first rentable NFT ERC standard. As an extension of ERC-721, EIP-4907 introduces a UserInfo variable containing the user’s address and a “userExpires” timestamp indicating when the rental period ends. Once this time expires, the rental relationship terminates. The core code is shown below:
Unlike the simple extension of ERC-721 in EIP-4907, EIP-5006 leverages the unique data structure of ERC-1155 (which supports multiple tokens under one ID, each associated with different addresses and quantities) by introducing UserRecord and usableBalance functions, enabling efficient batch management of rental statuses. The main code is shown below:
Core Value of EIP-4907 and EIP-5006 Standards
Both ERC-721 and ERC-1155 token standards benefit from this new utility: the person “using” a token may differ from the token’s owner (as in rentals). Therefore, distinguishing between “owner” and “user” roles is essential so that “users” cannot perform actions reserved for owners (e.g., transferring ownership). The introduction of EIP-4907 and EIP-5006 clarifies rights allocation for NFTs, helping address NFT liquidity shortages. With dual “owner” and “user” roles, separation of ownership and usage rights becomes possible—this is key infrastructure for solving NFT liquidity issues and enables on-chain use cases like rentals. It simplifies defining what lenders and borrowers can or cannot do with an NFT (i.e., their rights). For instance, to verify transfer rights, a project only needs to check whether the acting address is the owner or user; if it’s the user, the transaction is blocked. Additionally, owners control who becomes a user, and other projects can easily assign privileges explicitly to either party.
Moreover, based on permissionless interoperability, this standard makes it easier for third-party protocols to manage NFT usage rights without requiring permission from the NFT issuer or application. Once a project adopts the additional user role, any other project can directly interact with these features and implement their own transaction types. For example, PFP-type NFTs using this standard can be integrated into a rental platform where users rent an NFT for 30 days, or into a lending platform where users access the NFT while gradually purchasing full ownership via installment payments—all without needing permission from the original PFP project.
The launch of EIP-4907 and EIP-5006 undoubtedly further clarifies the direction for expanding NFT application value, paving the way for richer gameplay mechanics, use cases, and derivatives. Widespread adoption of NFT rentals will enrich GameFi ecosystems and significantly improve capital turnover rates. In large-scale GameFi projects like Axie, the massive base of active players contributing real playtime need low-trust-cost methods (non-mandatory transfer rentals) to rent in-game equipment or resource rights. Many NFTs will become more functional—for example, virtual land in the metaverse can be “used,” and game-asset NFTs can be actively “used” within games. In many cases, owners and users won’t always be the same. An NFT owner might rent it out to a “user.” The actions allowed for a “user” should differ from those of the “owner” (e.g., a “user” generally cannot sell the NFT). Having distinct roles identifying whether an address represents the “owner” or “user” and managing permissions accordingly is highly meaningful.
EIP-5007 Adding Time Attributes to NFTs
This proposal suggests adding a new attribute to the ERC-721 token standard: startTime and endTime. This makes time-based management of NFTs on-chain simpler and more efficient. Some NFTs have defined usage periods beyond which they cannot be used. For traditional NFTs lacking time information, marking a token as invalid or enabling it at a specific time requires manually submitting a transaction—a cumbersome and costly process. Moreover, inconsistent time function interfaces pose challenges for third-party development platforms. By introducing startTime and endTime functions, automatic activation and deactivation of NFTs on-chain become possible. The main code is shown below:
This functionality opens up many new use cases—for example, NFT-based access services or subscription content apps, where EIP-5007 allows developers to automatically revoke service or content access after a set period. The extension could also apply to digital art or collectibles whose value may depreciate over time. The ability to specify expiration times helps prevent NFTs from becoming stale or devalued over time.
It’s worth noting, however, that if expiration times aren't properly enforced or malicious actors attempt to tamper with the expiry field, the proposed solution could introduce security risks. Thus, additional safeguards may be needed to ensure expiry dates are correctly enforced and that NFT owners aren't unfairly locked out of their assets.
EIP-5496 Multi-Rights Management Extension for NFTs
EIP-5496 proposes an extension to the EIP-721 token standard, enabling multi-rights management for NFTs. The proposal defines an interface extending EIP-721, allowing NFTs to share privileges among multiple people. Privileges can be on-chain (such as voting rights, eligibility for airdrops) or off-chain (coupons for online stores, restaurant discounts, airport lounge access). Each NFT may contain multiple privileges, and privilege holders can transfer them to others. Privileges can be non-transferable or transferable. Transferable privileges can be cloned, with providers adjusting details along distribution paths. Expiration times can also be set for each privilege. The main code is shown below:
The privilege data management process uses two nested structs. First, PrivilegeRecord is defined, storing the user address (address user) and expiration time (expiresAt). Then PrivilegeStorage is defined, storing the latest expiration time (LastExpiresAt), and mapping privilege IDs to PrivilegeRecord entries. This ID-based approach is clever—verifying privileges becomes straightforward since there's no need to match content character-by-character; only the privilege ID needs verification. Since privilege content often changes frequently, keeping content off-chain while storing only the ID on-chain allows issuers to update privileges without incurring gas fees. However, once privilege IDs are abstracted, it becomes difficult to intuitively see what privileges an NFT holds, potentially requiring third-party tools to provide dedicated setup and query interfaces to map IDs back to actual benefits. The main code is shown below:
This protocol enables real-time, effective management of privileges attached to NFTs. Many NFTs serve purposes beyond profile pictures or art collections—they can offer real utility across various scenarios. For example, a fashion brand might offer discounts to its NFT holders; DAO member NFT holders could vote on treasury proposals; a DApp might run an airdrop targeting specific groups like blue-chip NFT holders; grocery stores could issue membership cards as NFTs granting shopping perks. Issuers can embed various privileges into NFTs, but holders may not always want to use them. Traditional EIP-721 only records ownership and transfer history—privileges themselves aren’t stored on-chain. EIP-5496 extends this by allowing merchants/projects to write privileges onto the blockchain, grant them to specific audiences, and empower both issuers and holders to independently manage individual privileges—unlocking practical value and enabling large-scale real-world NFT applications.
EIP-5606 Multiverse NFT
EIP-5606 defines an interface to create a Multiverse NFT standard for digital assets (e.g., wearables, in-game items), indexing delegated NFTs representing that asset on each platform. These platforms can include metaverses, GameFi, or NFT marketplaces. The standard also allows “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 below:
The concept of Multiverse NFT introduced by EIP-5606 represents a digital asset spanning multiple platforms. The Multiverse NFT contract defines a new token type that maintains the relationship between a unique digital asset and its counterparts on various platforms (referred to as delegate tokens in the EIP). The standard introduces the simple concept of a “bundle”—essentially a group of delegated NFTs identified by a unique ID (the multiverse token ID). The DelegateData struct contains information about the delegated NFTs on each platform, including variables like contractAddress, tokenId, and quantity, applicable to both ERC-721 and ERC-1155 standards. The bundle and unbundle functions accept an array of DelegateData structs to support partial bundling/unbundling. They also require individual token IDs of the delegated NFTs, ensuring only the multiverse NFT owner (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, non-fungible assets. One category includes sets of interconnected NFTs. For example, if a brand launches a new sneaker across different platforms, it mints a separate NFT on each. Yet, in reality, it’s the same sneaker. The lack of cross-platform NFT interoperability remains a pressing issue. Creating a multiverse NFT standard that indexes digital assets and ownership across platforms would be the first step toward true cross-platform interoperability and genuine ownership. In this regard, EIP-5606 represents the first concrete attempt to solve interoperability and true ownership for NFTs across platforms.
EIP-6150 Hierarchical NFT Standard Emerges
EIP-6150 extends the EIP-721 standard by proposing a multi-layer hierarchical NFT structure similar to a file system. The protocol adds new interfaces to EIP-721 and its contracts for retrieving parent or child NFTs, determining whether an NFT is a leaf or root node, and maintaining hierarchical relationships. The hierarchical relationship between NFTs means all NFTs form a tree-like structure. Each NFT is a node on the tree—possibly a root, leaf, parent, or child. The main code is shown below:
This proposal first standardizes the Minted event to indicate parent-child relationships when minting a new node. Within each hierarchical tree, the proposal specifies the parentOf function to query the parent NFT of a given tokenId, and childrenOf to retrieve all child NFTs of a specified tokenId—making it easy to navigate up and down the hierarchy. Additionally, isRoot and isLeaf functions determine whether a given tokenId represents a root or leaf node in the entire NFT hierarchy.
Notably, the proposal thoughtfully includes three optional extension interfaces:
Enumerable Extension (IERC6150Enumerable)
Three functions are standardized to support enumerable queries involving child nodes. Each function includes a param parentId; for compatibility, setting parentId to 0 means querying root nodes.
Burnable Node Extension (IERC6150Burnable)
Hierarchical Transfer Extension (IERC6150ParentTransferable): In certain cases—like file systems—a directory or file can be moved from one directory to another. This proposal adds the ParentTransferable extension to support such operations.
Access Control (IERC6150AccessControl)
In a hierarchy, multiple accounts often need permission to operate a node—such as minting child nodes, transferring nodes, or burning nodes. This proposal adds standard functions to check access control permissions.
Currently, nearly all NFTs are flat, with no inherent relationships between them. In contrast, hierarchical NFTs link all NFTs into a tree-like structure, much like a file system. Hierarchical NFTs can apply to diverse use cases: organizational charts, social graph networks, e-commerce product categories, hierarchical comment systems, and more.
Indeed, any scenario involving hierarchical structures could adopt the EIP-6150 standard. Hierarchical NFTs may find broad applications in decentralized social networks, decentralized e-commerce, and beyond. Within the Ethereum ecosystem, a single smart contract could act as the root, managing each directory/category as individual NFTs with defined hierarchical relationships. Each NFT’s tokenURI could point to another contract address, a website link, or any form of metadata. Only one contract is needed to manage and manipulate the hierarchy. In the near future, with advancements in Ethereum’s data availability solutions and external permissionless data storage networks, on-chain companies managing organizational structures could become feasible—enabling fully decentralized applications.
The above covers recent developments in Ethereum NFT protocols. At the time of writing, EIP-5007 and EIP-5496 are still in the Last Call stage, while EIP-4955, EIP-5006, EIP-5606, and EIP-6150 have advanced from Last Call to Final status. Overall, these new protocols make significant contributions to NFT innovation and practicality. We’ve moved beyond the PFP era—the journey of Web3 reaches far into the stars. Innovation continues ceaselessly. What will be the next narrative for NFTs? From these protocols, we can glimpse a future where NFTs evolve toward increasingly practical and application-driven directions. In the near future, NFT technology itself will transform gaming, insurance, real estate transactions, paid advertising, voting, social platforms, video media—and countless aspects of daily life. NFTs will no longer be just a piece of crypto—they may become the only truly real-world-connected practical application in the entire crypto space in the coming years.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
R3PO
