ERC-4671: Non-Tradable Tokens Standard

Abstract

A non-tradable token, or NTT, represents inherently personal possessions (material or immaterial), such as university diplomas, online training certificates, government issued documents (national id, driving license, visa, wedding, etc.), labels, and so on.

As the name implies, non-tradable tokens are made to not be traded or transferred, they are "soulbound". They don't have monetary value, they are personally delivered to you, and they only serve as a proof of possession/achievement.

In other words, the possession of a token carries a strong meaning in itself depending on why it was delivered.

Motivation

We have seen in the past smart contracts being used to deliver university diplomas or driving licenses, for food labeling or attendance to events, and much more. All of these implementations are different, but they have a common ground: the tokens are non-tradable.

The blockchain has been used for too long as a means of speculation, and non-tradable tokens want to be part of the general effort aiming to provide usefulness through the blockchain.

By providing a common interface for non-tradable tokens, we allow more applications to be developed and we position blockchain technology as a standard gateway for verification of personal possessions and achievements.

Specification

Non-Tradable Token

A NTT contract is seen as representing one type of certificate delivered by one authority. For instance, one NTT contract for the French National Id, another for Ethereum EIP creators, and so on...

• An address might possess multiple tokens. Each token has a unique identifier: tokenId.
• An authority who delivers a certificate should be in position to revoke it. Think of driving licenses or weddings. However, it cannot delete your token, i.e. the record will show that you once owned a token from that contract.
• The most typical usage for third-parties will be to verify if a user has a valid token in a given contract.

Extensions

Metadata

An interface allowing to add metadata linked to each token.

Enumerable

An interface allowing to enumerate the tokens of an owner.

Delegation

An interface allowing delegation rights of token minting.

Consensus

An interface allowing minting/revocation of tokens based on a consensus of a predefined set of addresses.

Pull

An interface allowing a token owner to pull his token to a another of his wallets (here recipient). The caller must provide a signature of the tuple (tokenId, owner, recipient) using the owner wallet.

NTT Store

Non-tradable tokens are meant to be fetched by third-parties, which is why there needs to be a convenient way for users to expose some or all of their tokens. We achieve this result using a store which must implement the following interface.

Rationale

On-chain vs Off-chain

A decision was made to keep the data off-chain (via tokenURI()) for two main reasons:

• Non-tradable tokens represent personal possessions. Therefore, there might be cases where the data should be encrypted. The standard should not outline decisions about encryption because there are just so many ways this could be done, and every possibility is specific to the use-case.
• Non-tradable tokens must stay generic. There could have been a possibility to make a MetadataStore holding the data of tokens in an elegant way, unfortunately we would have needed a support for generics in solidity (or struct inheritance), which is not available today.

Reference Implementation

You can find an implementation of this standard in ../assets/eip-4671.

Using this implementation, this is how you would create a token:

This could be a contract managed by the Ethereum foundation and which allows them to deliver tokens to EIP creators.

Security Considerations

One security aspect is related to the tokenURI method which returns the metadata linked to a token. Since the standard represents inherently personal possessions, users might want to encrypt the data in some cases e.g. national id cards. Moreover, it is the responsibility of the contract creator to make sure the URI returned by this method is available at all times.

The standard does not define any way to transfer a token from one wallet to another. Therefore, users must be very cautious with the wallet they use to receive these tokens. If a wallet is lost, the only way to get the tokens back is for the issuing authorities to deliver the tokens again, akin real life.

Copyright

Copyright and related rights waived via CC0.