The full name of EIP is Ethereum Improvement Proposals, and anyone in the Ethereum community can create an EIP. Guidelines for writing Ethereum Improvement Proposals are provided in EIP-1. Creators of Ethereum improvement proposals are responsible for building consensus within the community and recording dissent. Historically, the creators of most Ethereum improvement proposals are usually application or protocol developers, because submitting high-level Ethereum improvement proposals requires strong technical capabilities, and the EIP will be given a serial number after the initial review. And discuss through the review process shown in the figure below.

secondary title

EIP-4955 Metadata Standard Extensions

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

EIP-4955 uses a direct extension of EIP-721 metadata, and the idea behind it is for backward compatibility. Enables existing projects that cannot modify the metadata response (schema) to create a new smart contract that returns an updated metadata schema based on the tokenId. Given that most projects on Ethereum use non-upgradeable contracts. If this EIP requires a completely new implementation of these contracts, it must be redeployed. This is a waste of time and money. By utilizing the existing metadata fields of EIP-721, the number of necessary changes can be minimized.

There are many projects that require custom NFT properties. Each item may have its own way of rendering NFTs, so they require different metadata values. For example metaverse projects like Decentraland or TheSandbox, they need different 3D models to render NFT, based on the visual/engine of each project. NFTs projects like Cryptopunks, Bored Apes, etc. can create the 3d models needed for each project,

secondary title

NFT lease use extension from EIP-4907 to EIP-5006

EIP-5006 This proposal is a leasing standard for ERC-1155 NFT proposed by the NFT leasing market Double Protocol, which is an extension of the ERC-1155 standard. The proposal proposes an additional new field user (user) in the NFT metadata, which can be granted an address (owner) representing the asset user (user) instead of the owner.

As early as June 29 last year, EIP-4907, also launched by the NFT leasing market Double Protocol, officially passed the Ethereum audit and became the first ERC standard for leasing NFT. As an extension of ERC-721, EIP-4907 adds a user information (UserInfo) variable, which includes the user (User) address and "lease expiration time (userExpires)". When the time exceeds the lease time, the lease relationship is terminated. The main code is shown in the figure below:

secondary title

Core Values ​​of EIP-4907 and EIP-5006 Standards

Both ERC-721 and ERC-1155 standard tokens require such a new utility. Right now"use"The person who holds the token may be different from the person who owns the token (as in a lease). Therefore, for"owner"and"user"It is necessary to set different roles, so that"user"Actions that the owner can take (for example, transfer ownership) cannot be taken. The proposal of EIP 4907 and EIP-5006 clarifies the distribution of NFT rights, which is conducive to solving the shortage of NFT liquidity. with double"owner"and"user"Roles can realize the separation of ownership and use rights of NFT, which is the key infrastructure to solve the problem of NFT liquidity shortage, and provides technical support for some on-chain usage scenarios such as leasing. Makes it very easy to manage what NFT lenders and borrowers can and cannot do with NFTs (in other words, their rights). For example, for the right to transfer ownership, the project only needs to check whether the address taking the action is an address representing the owner (owner) or a user (user), and if it is a user (user), block the transaction. Additionally, owners can control who users are, and it is easy for other projects to assign their own stake explicitly to owners or users.

At the same time, on the basis of permissionless interoperability, the standard makes it easier for third-party protocols to manage the usage rights of NFTs without the need for permission from NFT issuers or NFT applications. Once a project adopts additional user roles, any other project can directly interact with these functions and implement their own transaction types. For example, PFP-type NFTs using this standard can be integrated into a leasing platform, where users can rent NFTs for 30 days, and can also be integrated into a mortgage loan platform, where users can use NFTs and eventually purchase ownership of NFTs through installment payments. This will all be done without requiring permission from the original PFP project.

The launch of EIP-4907 and EIP-5006 will undoubtedly further clarify the direction of NFT to expand the application value, and more and rich gameplay, application scenarios and derivatives will emerge. For example, the popularity of leasing NFT will enrich GameFi's ecological gameplay, and the capital turnover rate will be greatly improved. These massive basic players who can really contribute online time in large Gamefi such as Axie need a relatively low trust cost method (non-mandatory transfer lease) to rent equipment or resource rights in the game. Many NFTs will be more practical. Like the virtual land in the metaverse can be"use", NFT representing game assets can be used in the game"use". In some cases, owner and user may not always be the same. There may be an owner of an NFT, renting it out to a"user". one"user"Actions that should be able to be taken against NFTs will be different"owner"(For example,"user"NFT ownership generally cannot be sold). In these cases, there are separate roles to identify an address that represents"owner"still"user"secondary title

EIP-5007 Give time attribute to NFT

This proposal proposes to add a new attribute based on the ERC-721 token standard, including the initial time and expiration time (startTime, endTime). This makes the time management of NFT on the chain simpler and more efficient. Some NFTs have a defined lifespan beyond which they cannot be used. With traditional NFTs that don't include time information, if you want to mark a token as invalid or enabled at a specific time, you need to actively submit a transaction - a process that is obviously cumbersome and expensive. And the interface of its time function is inconsistent, which will bring some difficulties to the third-party development platform. By introducing these functions (startTime, endTime), NFT can be automatically enabled and disabled on the chain. The main code is shown in the figure below:

This feature can also bring many new usage scenarios to NFT, such as NFT-mediated access services or NFT-based subscription content applications, because EIP-5007 will allow developers to automatically revoke subscriptions to services or services after a set period of time. Content Access. In addition to this, the expansion of the protocol can also be applied to digital art or collectibles, where the value of NFT may decrease over time. The ability to specify an expiration time can help prevent NFTs from becoming"obsolete"or devaluation.

secondary title

EIP-5496 NFT multi-stake management extension

EIP-5496 proposes an extension to the EIP-721 token standard, allowing NFT's multi-stake management. This proposal defines an interface that extends EIP-721 to provide NFT with rights that can be shared by multiple people. Benefits can be on-chain (voting rights, permission to request airdrops) or even off-chain (coupons for online stores, discounts at local restaurants, access to airport lounges). Each NFT may contain many rights, and the holder of the rights can transfer the rights to others. Interests can be non-shareable or shareable. Shareable interests can be cloned and replicated, and providers can adjust the details according to the propagation path. It is also possible to set an expiration time for each privilege. The main code is shown in the figure below:

The specific equity data management process uses two structures for double-layer nesting. First, PrivilegeRecord is defined, which stores two fields of user address (address user) and expiration time (expiresAt), and then PrivilegeStorage is defined, which contains The latest expiration time (LastExpiresAt) is stored, and the benefit ID is bound to the PrivilegeRecord by means of mapping. This method of equity IDization is very smart. After the equity ID is converted, it will be very convenient to verify the equity. It does not need to match the equity verbatim to verify the equity. It only needs to verify the equity ID. The content of the equity usually changes frequently. , put the content of the rights and interests off the chain, and only put the rights and interests ID on the chain, and the project party does not need to spend gas fees when changing the rights and interests. However, after the rights and interests are ID-based, the problem is that it is impossible to intuitively see what rights and interests this NFT has. It may also require a third-party product to independently set a rights and interests content and query functions to index to the corresponding ID. The main code is shown in the figure below:

secondary title

EIP-5606 Multiverse NFT

EIP-5606 defines an interface to create a Multiverse NFT (Multiverse NFT) standard for digital assets (such as wearable devices and in-game items), while indexing the entrusted NFT of such assets on each platform. These platforms can be metaverses, Gamefi or NFT marketplaces. The standard also allows for the commissioning of these delegated NFTs in the multiverse NFT"tie up"and"untie", so holders can trade individually or as a bundle. The main code is shown in the figure below:

The multiverse NFT concept introduced by EIP-5606 represents a digital asset that spans multiple platforms. Multiverse NFT contracts define a new kind of token that maintains the relationship between a unique digital asset and its associated platform counterpart (EIP refers to them as entrusted tokens). The standard introduces the simple concept of a bundle. 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 contains are: contractAddress, tokenId, quantity, to distinguish NFT (follow the ERC-721 standard or ERC-1155 standard). The bind and unbind functions accept an array of DelegateData structures, as needed to satisfy partial binding and unbinding. They also need to delegate the NFT's individual token ID to optionally 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 grown to represent multiple types of unique and non-fungible assets. One type of asset consists of a set of interrelated NFTs. For example, if a brand releases a new sneaker on different platforms, it will be minted as a separate NFT on each platform. In reality, however, it's the same sneaker. The lack of cross-platform interoperability of NFT has become an urgent problem to be solved. Creating a multiverse NFT standard that allows indexing and ownership of digital assets on different platforms will be the first step towards cross-platform interoperability and true ownership. In this direction, the EIP-5606 proposal is to solve NFT and cross-platform"real"secondary title

EIP-6150 Hierarchical NFT standard was born

EIP-6150 This protocol is extended on the basis of EIP-721. It proposes a multi-layer hierarchical NFT structure similar to a file system. Based on EIP-721 and the contract, this protocol adds a new interface to obtain the parent NFT or child NFT and whether the NFT is a leaf node or a root node, and maintains the hierarchical relationship between them. The so-called hierarchical relationship between NFTs means that all NFTs will form a hierarchical relationship tree. Each NFT is a node on the tree, which may be a root node or a leaf node, or a parent node or a child node. The main code is shown in the figure below:

Minted events are first standardized in this proposal to indicate the parent-child relationship when minting a new node. In each hierarchical tree, this proposal specifies that the function parentOf is used to query the parent node NFT of the NFT of the specified tokenId, and the function childrenOf is specified to query all the child node NFTs of the NFT of the specified tokenId. In this way, it is convenient to query the upper and lower nodes. In addition, the functions isRoot and isLeaf can respectively query whether the specified tokenId is a root node or a leaf node in the entire NFT hierarchical tree.

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

• Enumerable Extensions (IERC 6150 Enumerable)

This proposal standardizes three functions as extensions to support enumerable queries involving child nodes. Each function has a param parentId. For compatibility, when the parentId is specified as 0, it means to query the root node.

• Burning node extensions (IERC 6150 Burnable)

Transfer extension of hierarchical relationships (IERC 6150 ParentTransferable) In some cases, such as file systems, a directory or a file can be moved from one directory to another. So this proposal adds the ParentTransferable extension to support this case.

• Access Control (IERC 6150 AccessControl)

In a hierarchy, there is usually more than one account that has permission to operate a node, such as mint subnodes, transfer nodes, and burn nodes. This proposal adds some standard functionality to check access control permissions.

Since the current NFTs are almost all flat, there is no correlation between different NFTs. The hierarchical standard NFT can connect all NFTs in series to form a tree structure, just like a file system. Hierarchical NFT can be used in a variety of different application scenarios, such as: organizational structure, social relationship graph, e-commerce product category structure, hierarchical comment system, etc.

It can be said that any scene with a hierarchical structure can apply this EIP-6150 protocol standard. Hierarchical NFTs may have a wide range of applications in decentralized social networking, decentralized e-commerce and other fields. Within the Ethereum ecosystem, a single smart contract can be the root, managing each directory/category as a separate NFT and a hierarchy of NFTs. The tokenURI of each NFT can be another contract address, a website link, or any form of metadata. Only one contract is needed to manage and operate the hierarchical relationship. 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. Thus realizing a completely decentralized application.

Disclaimer: There are risks in the market, and investment needs to be cautious. Readers are requested to strictly abide by local laws and regulations when considering any opinions, viewpoints or conclusions in this article. The above content does not constitute any investment advice.

References:

EIP-4955:

https://eips.ethereum.org/EIPS/eip-4955 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4955.md

EIP-5006 

https://eips.ethereum.org/EIPS/eip-5006 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5006.md

EIP-5007 

https://eips.ethereum.org/EIPS/eip-5007 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5007.md

EIP-5496 

https://eips.ethereum.org/EIPS/eip-5496 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5496.md

EIP-5606 

https://eips.ethereum.org/EIPS/eip-5606 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5606.md

EIP-6150 

https://eips.ethereum.org/EIPS/eip-6150 

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6150.md

Copyright statement: If you need to reprint, please add the assistant WeChat to communicate. If you reprint or wash the manuscript without permission, we will reserve the right to pursue legal responsibility.

Disclaimer: There are risks in the market, and investment needs to be cautious. Readers are requested to strictly abide by local laws and regulations when considering any opinions, viewpoints or conclusions in this article. The above content does not constitute any investment advice.