EIP standards for Non-fungible tokens.

ERC is an acronym for Ethereum Request for Comments. ERCs are application-level standards for Ethereum and can include token standards, name registries, library/package formats, and more. Anyone can create an ERC, but it is the author’s responsibility to clearly explain their standard. Besides the popular ERC standards like ERC20, ERC721, and ERC1155, here are the important NFT standards that have already been finalized.

EIP-2309: ERC-721 Consecutive Transfer Extension

Created at 2019–10–08

The optional ERC-721 Consecutive Transfer Extension provides a standardized event that could be emitted during the creation/transfer of one, or many non-fungible tokens. This standard does not set the expectation of how you might create/transfer many tokens. It is only concerned with the event emitted after the creation, or transfer of ownership of these tokens. This extension assumes that token identifiers are in consecutive order.

EIP-2981: NFT Royalty Standard

Created at 2020–09–15

This EIP enables any NFT marketplace to unite on a single royalty payment standard. This standard allows token-holders who support both ERC-721 and ERC-1155 interfaces to make a standardized way of signaling royalty information. More specifically, these contracts can now calculate the royalty amount for content that is being sold.

EIP-3525: Semi-Fungible Token

Created at 2020–12–01

This token standard is designed to represent semi-fungible assets, which are most suited for financial instruments rather than collectibles or in-game items — ERC1155. If one was to create financial instruments such as bonds, insurance policy, or vesting plans using EIP-721, one need to create a separate ERC-20 contract for each financial product.

Every token has both ID and value property, where the ID property has the same semantics as ERC-721, and the value has the same meaning as ERC-20.

The semi-fungibility of the tokens is defined by the SLOT property, when two tokens have the same SLOT, their value is fungible, that is: they can be added together like ERC-20 tokens do. Every EIP-3525-compliant contract must implement the EIP-3525, EIP-721, and EIP-165 interfaces.

EIP 4907: Rental NFTs

Created at: 2022–03–11

This standard is an extension of EIP-721. It proposes an additional role (user) that can be granted to addresses and a time when the role is automatically revoked (expires). The user role represents permission to “use” the NFT, but not the ability to transfer it or set users.

Some digital assets have particular utilities. For example, virtual land can be used to build scenes, and assets representing game assets can be used in-game. In some cases, the owner and user may not always be the same person. There may be an owner of the asset that rents it out to a “user”. The actions that a “user” should be able to take with an asset would be different from those of its owner (for instance, users usually shouldn’t be able to sell ownership of the asset). In these situations, it makes sense to have separate roles that identify whether an address represents an “owner” or a “user” and manage permissions accordingly.

In addition to this, many applications of the NFT model (such as renting) require that users have only temporary access to using the NFT. Normally, this means submitting two on-chain transactions — one to list a new address as the new user role at the start of the duration and one to reclaim the user role at the end. This is inefficient in both labor and gas and so an “expires” function is introduced that would facilitate automatic expiration without requiring a second transaction.

EIP-5192: Minimal Soulbound NFTs

created at: 2022–07–01

This standard proposes an extension of EIP-721. It aims to make tokens soulbound using EIP-165’s ability to detect features. A soulbound token is a non-fungible token bound to a single account.

Due to the lack of a standard, many developers throw errors on a user’s invocation of transfer functionalities in the case of non -transferable SoulBound tokens, which is wrong over a longer period of time. The EIP allows for minimal addition to EIP-721 that allows wallet implementers to check for a token contract’s permanent (non-)transferrability using EIP-165.

The contract implementing this interface (Soulbound tokens) must return True for interfaceID=0xb45a3c0e if function supportsInterface(bytes4 interfaceID) external view returns (bool) is called on it.

EIP-5375: NFT Author Information and Consent

Created at: 2022–07–30

The EIP standardizes a JSON format for storing off-chain information about NFT authors. Specifically, it adds a new field that provides a list of author names, addresses, and proofs of authorship consent: proofs that the authors have agreed to be named as authors. Note that proof of authorship consent is not proof of authorship: an address can consent without having authored the NFT.

This EIP standardizes the format for storing this information on the blockchain. It also moves some functionality from ENS into the blockchain (such as registering new NFTs), which will allow us to use other EIPs like this one in the future.

there are several situations where the minter and the author might not be the same due to the following reasons :

• NFTs minted by a contract
• Lazy minting
• NFTs are minted by an intermediary (which can be particularly useful when the author is not tech-savvy and/or the minting process is convoluted)

This standard allows the minter to provide authorship information, while also preventing authorship claims without the author’s consent.

EIP-5484: Consensual Soulbound Tokens

Created at: 2022–08–17

This EIP defines an interface extending EIP-721 to create soulbound tokens. Both parties (the issuer and the receiver) must agree on who has the authorization to burn this token before its issuance. After its issuance, a soulbound token cannot be transferred but can be burned based on a predetermined immutable burn authorization.

In order to provide flexibility in these scenarios, soulbound tokens must have an application-specific burn authorization and a way to distinguish themselves from regular EIP-721 tokens. The improvement proposed is as follows:

1. Soulbound tokens will be compatible with existing NFTs. Service providers can treat SBTs like NFTs and won’t have to make drastic changes to their code.
2. Transfer functions throw errors if there’s no soulbound interface in place but also enable third parties to check beforehand if the contract implements the soulbound interface in order to avoid calling transfer.
3. Tokens have different burn authorizations: IssuerOnly, ReceiverOnly, Both, and Neither. Burn authorization is tied to specific tokens and immutable after issuance. It is therefore important for the receiver to gain consent before the token is issued.
4. On issuing, an Issued event will be emitted alongside EIP-721’s Transfer event.
5. when a key rotation needs to happen, the owner of the token (who is also the issuer) can inform the party with burn authorization. Then that person can burn the token while the issuer can issue a new replica.

EIP-5528: Refundable Fungible Token

Created on : 2022–08–16

Because there is no way to reverse payments in a pseudonymous cryptocurrency, the lack of trusted escrow services creates an unsafe environment for crypto payments. To combat this problem, this standard describes a smart contract interface that can act as an escrow service with a function where tokens are returned to the original wallet upon failure of the escrow. Here is how it works :-

• The seller issues tokens.
• The seller creates an escrow smart contract with detailed escrow information like contract addresses, lock period, exchange rate, additional escrow success conditions, etc.
• The seller funds seller tokens to the Escrow Contract.
• Buyers fund buyer tokens which are pre-defined in the Escrow Contract.
• When the escrow status meets success, the seller can withdraw buyer tokens, and buyers can withdraw seller tokens based on exchange rates.
• Buyers can withdraw (or refund) their funded token if the escrow process is failed or is in the middle of the escrow process.

Uniping is a platform where the Dapps can target their potential customers based on their on-chain activity. We are the first platform that provides granular web3 targeting without any dependence on the web2 marketing platform that illegally collects user data. Please give us a try at https://uniping.xyz.