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.
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.
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...
tokenId.An interface allowing to add metadata linked to each token.
An interface allowing to enumerate the tokens of an owner.
An interface allowing delegation rights of token minting.
An interface allowing minting/revocation of tokens based on a consensus of a predefined set of addresses.
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.
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.
A decision was made to keep the data off-chain (via tokenURI()) for two main reasons:
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.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.
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 and related rights waived via CC0.