NFT Series

Soulbound NFT (EIP-4671)

Trying to understand why and when a Non-tradable token is useful.

Paolo Servillo

Published in

Coinmonks

5 min readSep 6, 2022

Introduction

Especially in the last year, interest in NFTs has grown dramatically. The reasons for this interest are many, but this is not the aspect that I want to deepen in this article. The point is that more and more people have become familiar with the concept of NFT.

It can represent ownership over digital or physical assets and fits very well in use cases where it is used as:

Access NFTs, to grant their owners entry and access to communities, events, or experiences in both the digital and physical world
Engagement NFTs, when are used to engage with brands and other users within the community
Gamified NFTs, where are tied to elements that are part of a gaming universe
Asset NFTs, when encompasses the ownership of a unique value-based digital or physical asset

About NFT Classification, it is worth reading Miguel Cienfuegos’s article NFT Utility Classification — current and prospective trends, where a very useful and well-defined taxonomy of NFT is shown.

Motivation

But what do all these use cases have in common?

In these scenarios, the NFTs are always tradeable items, with the peculiarity that they can be transferred or sold by the owner.

But in this way, a typical case is not covered, when the asset represented by the NFT is “soulbound”.

What does it mean “soulbound”?

It simply implies that once picked up, the NFT cannot be sold or transferred to another person.

With this concept in mind, a very interesting EIP was created on January 2022 by Omar Aflak: EIP 4671 — Non-Tradable Tokens Standard.

As he states:

“…non-tradable tokens … don’t have monetary value, they are personally delivered to you, and they only serve as a proof of possession/achievement”

The motivation behind the Non-tradable tokens (or NTT) is to address all the cases where a token is not tradable. So, when it symbolises intrinsically personal possessions (material or immaterial), such as university diplomas, online training certificates, government-issued documents (national id, driving license, visa, wedding, etc.), labels, attendance to events and so on.

But, in my opinion, use cases involving certificates or documents are very complex to address with the NTT approach, taking into account that privacy and security are the key elements in this context. The current most viable way is delineated in the context of the Self-Sovereign Identity (SSI) initiatives as the European Self-Sovereign Identity Framework (ESSIF).

On another side, soon after the creation of the EIP, Vitalik Buterin wrote about the argument in his blog post “Soulbound”. Here, he focuses on the concept of NFT signaling, i.e., a person must prove some kind of skill to acquire an NFT. But, because NFTs are tradable items, you cannot tell if someone did X personally or if they simply paid someone else to do X.

An NFT, as is, just signals wealth, so, this is the reason why the world needs Non-tradable tokens.

The post continues by pointing out the importance of well-defined governance for non-transferability and the need to have very clear ideas on how to manage and preserve the privacy of users. These may be the reasons why Vitalik indicates “proof of attendance” as an excellent use case of NFT that works better if it could be soulbound. The use case is simple and well delineated, as the NFT simply represents the idea that the owner personally participated in some event.

The reference implementation

Anyway, I’m curious to look at the current status of the reference implementation of the EIP (currently in draft status).

An NTT contract is seen as representing one type of certificate delivered by one authority. The choice here is to not extend the ERC721 standard and override the transfer methods to do nothing, so this is the IERC4671 interface.

This interface has the `balanceOf` and `ownerOf` methods in common with the IERC721, but in addition, it was thought to manage the revocation of a token. For this reason, the methods `isValid` and `hasValid` are present:

`isValid`: checks if a token hasn’t been revoked
`hasValid`: checks if an address owns a valid token in the contract

So, whoever delivers an NTT has the faculty to revoke it, but cannot delete a token.

Some interesting extensions were proposed:

IERC4671Metadata: allows to add metadata linked to each token and it is exactly the same as the IERC721Metadata interface
IERC4671Enumerable: allows enumerating the tokens of an owner (very similar to IERC721Enumerable)
IERC4671Delegate: allows delegation rights of token minting
IERC4671Consensus: allows minting/revocation of tokens based on a consensus of a predefined set of addresses
IERC4671Pull: allows a token owner to pull his token to another of his wallets

The ERC4671 reference implementation extends IERC4671, IERC4671Metadata, IERC4671Enumerable and ERC165 interfaces.

abstract contract ERC4671 is IERC4671, IERC4671Metadata, IERC4671Enumerable, ERC165

A struct `Token` is present to store token’s information as the issuer, the owner and the validity of the token:

struct Token {
    address issuer;
    address owner;
    bool valid;
}

Then, the mappings from `tokenId` to `Token` and from owner’s address to its owned tokens are present:

mapping(uint256 => Token) private _tokens;mapping(address => uint256[]) private _indexedTokenIds;

Relevant methods are:

`_revoke`: to mark a token as revoked
`_mint`: to mint a new token
`_isCreator`: True if the caller is the contract’s creator, false otherwise

A demo application

On Vercel at https://non-tradable-token.vercel.app/ is possible to interact with a demo ERC4671 contract implementation.

The idea is that the NTT token is used as proof of having visited the website. Everyone can connect to the site and get a token or check the token ownership.

The code of the contract is the following:

The relevant feature is that only the creator (that is the deployer of the contract) can mint or revoke a token.

So, after connecting the wallet to the website, is possible to:

check if you have a valid token
get a valid token, only if you don’t own any (the minting transaction will be triggered by the backend)

All the application lives on Goerli testnet and the code can be found at https://github.com/donpabblo/non-tradable-token

Thank you for reading, I hope you enjoyed the article. Let me know what you think about it.

References

Eip-4671 on GitHub
EIP-4671: Non-tradable Token on Ethereum Magicians forum
Soulbound by Vitalik Buterin
Reference implementation on GitHub

New to trading? Try crypto trading bots or copy trading