EIP-3754: A vanilla non-fungible token standard

[simontianx]

Abstract

A vanilla NFT standard is proposed. In this standard, a non-fungible token stands as atomic existence and encourages layers of abstraction built on top of NFTs. Ideal for representing concepts like right, a form of abstract ownership. Such right, especially on-chain right, can then be made liquid because of this tokenization.

Rationale

The primary intention of this proposal is not to make a technical improvement to ERC721, although a new technical direction in a subsequent proposal EIP-4341 does present new technical merits, but rather to improve the conceptual clarity of NFTs, i.e., NFTs for digital collectibles, crypto-assets are specified and known by ERC721, and NFTs for abstract ownership such as rights, membership, etc. are specified and known by EIP-3754.

Use Cases

An example of applying this token to represent the right of making a function call to a contract is given here.

An on-chain subscription business model is also made possibe by adopting this token to represent quarterly or yearly membership (time-dependent right). An example can be fees per transaction for off-chain data via an oracle can be replaced by a long-term membership fee. Then as long as the caller has a valid EIP-3754 NFT, the consumption of data feeds is free (plus gas fees). NFTs can be transferred, so is the right of consuming data feeds. This has certain advantages over the current pay-as-you-go business model. An example can be found here.

A mid-layer can be added between NFT buyers and NFT creators with this standard. Currently, NFT creators have difficulty setting up initial prices and NFT buyers have the fear of missing out good NFTs. A mid-layer can be added between the two sides by minting ERC3754 NFTs as rights to purchase NFTs. NFT creators can presale such rights at lower prices and set the initial prices higher. For NFT buyers, buying such rights is a small commitment and can sell such rights if they do not like the NFTs minted later on. It can be best understood as a call option on an NFT. Effectively, this is a market making layer by reducing the bid-ask spread. A similar but slightly different idea can be seen in "@0xKiwi_ designed for @uwucrewnft". An in-house toy example can be found here.

A virtual coupon can be built by this standard. Ownership of such NFTs can enjoy certain discounts over a preset period of time.

Another great illustration of this concept can be found in this tweet that Andre Cronje sold the naming rights to his Twitter account to FTX.

[github-actions]

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

[abcoathup]

Metadata extension is optional in ERC721 (https://eips.ethereum.org/EIPS/eip-721#specification)

https://eips.ethereum.org/EIPS/eip-721#specification

The metadata extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent.

It looks like all this EIP is trying to do is remove reference to the tokenURI. Can the use case not be met with either not using the metadata extension or the tokenURI returning some generic JSON?

Similar question asked in: https://ethereum-magicians.org/t/eip-3754-a-vanilla-non-fungible-token-standard/6926/2?u=abcoathup

[simontianx]

@abcoathup Hey Andew, thanks for the question. ERC-721 is indeed the super set to the proposed standard here. That also introduces problems in practice. I personally had experiences explaining this new way of using NFTs to people and received confusion and doubts in return, even though URIs are technically OPTIONAL.

A simplification can reduce the concept of NFT to its core, which is a non-fungible token. It really does not have to be attached to any metadata or link to external media contents. Instead, this simplification can actually open up new possibilities on-chain by allowing layers of abstraction built on top of a non-fungible token.

[simontianx]

One more point to add is yes, NFTs can technically have URIs being set as empty strings, but a strange phenomenon could arise that if such tokens are listed on NFT platforms by accident or for some reasons, no media contents are going to be shown, even though they are totally ERC721 compliant.

The ERC3754 standard can help avoid such phenomenon.

[ndrslmpk]

Can you explain what the actual problem about the URI issue is? Isn't it an implementation detail on side of the actual NFT platform to show NFTs that are not associated to URIs, instead of establishing a new Token Standard to avoid that case handling?

[simontianx]

@ndrslmpk I think this is a situation that can be best described as "less is more".

NFTs are generally used to represent ownership of external media contents, or some other tangible items. They can also be used to represent abstract concepts like rights, a form of abstract ownership. An example of this is having NFT#1 is allowed to do actions A, B, C, and having NFT#2 is allowed to do D, E, F. In such scenarios, URIs are truly redundant.

A square separation between the two rather than blending both in one is good for conceptual clarity.

[abcoathup]

@abcoathup Hey Andew, thanks for the question. ERC-721 is indeed the super set to the proposed standard here. That also introduces problems in practice. I personally had experiences explaining this new way of using NFTs to people and received confusion and doubts in return, even though URIs are technically OPTIONAL.

@simontianx there is already ecosystem support for ERC721, and this EIP is ERC721 without the optional components.
I am struggling to see the need and to see how this EIP would get ecosystem support.

In the use case described, with NFT#1 having actions ABC and NFT#2 having actions DEF, then including the actions in the metadata would appear to be worthwhile to describe how they can be used.

[simontianx]

@abcoathup

this EIP is ERC721 without the optional components.

The logical relationship between ERC721 and this standard can be expressed with notations from Solidity as ERC721 is ERC3754.

metadata would appear to be worthwhile to describe how they can be used

Heuristically speaking, the metadata idea is extending abstraction on the same level in the logic hierarchy and this standard encourages building abstraction on higher levels.

ERC721: token + URI
ERC3754: token + f(token) + g(f(token)) + ..., where f(.) and g(.) are utility functions built upon a given token.

I agree ERC721 can do the same as:

ERC721: token + (URI) + f(token) + g(f(token)) + ..., where (URI) is optional.

Given the clear distinction between the two, having both can make ERC721 overloaded. Since not much attention has been paid to this way of using NFTs, our experience with this standard suggests, it is better to offload some and delegate it to a new standard.