Non-Transferable NFT Standard

Goal: Create a standardised way of constructing NFTs that are not meant to be transfered. These non-transferable NFTs (NTNFTs, or “soulbound” NFTs) should be bound to an owner address on minting, so the owner would never change.

Potential use-cases:

  • badges, POAPs
  • proofs of KYC or other verifications
  • ticketing, access control
  • certificates

Why transferable NFTs cannot do the job?

Attributions are usually made to a specific identifier (wallet address). For that reason, transferable NFTs don’t represent a suitable design, as the owning address can change. While an NEP-171 contract could limit the transfer functionality to prohibit it, this property won’t be easy to determine without checking the actual code. A standardised way of non-transferable NFTs would make this limitation explicit, which would build trust in the owners of tokens abiding to this new NEP standard.

To increase security, minting the non-transferable NFT should be limited to the owner of the account that executed the contract function, or the NTNFT contract must check that the owner agreed to be the target of the NTNFT.

Other considerations:

  1. The traditional way of “burning” a token is transferring it to the Zero address. Since the transfer functionality will be missing from this implementation, the standard will probably need to add an explicit way of burning a token (should be requested by the token owner).
  2. This NEP could also be extended with the “usual” NFT extensions, like Metadata and Enumeration. The Approval Management extension would not make sense though.
  3. From a technical standpoint the functionalities described by this standard will be a subset of the standard NFT functions, so this is not really an “extension” of the NEP-171, actually the NEP-171 standard should be an extension of this one. For historical reasons this will not be the case, but it could be a future improvement to NEP-171 to show this relation (while also implementing the burning function)

Proposed interface:

The interface of an NTNFT contract is really simple, it would “inherit” the only function from NEP-171 which is not related to transferring tokens:

function nft_token(token_id: string): Token|null {}

A new function added by the standard is the explicit burning function:

funcition burn_token(token_id: string): null {}

The Metadata and Enumeration extensions could extend the interface by the usual functions, for example: nft_metadata, nft_total_supply, nft_supply_for_owner

Note: This proposal is created by the kycDAO team, as part of a NEAR grant. The “torch-bearer” for this proposal is Balázs Némethi @nembal (assisted by myself, Sándor Juhász)


I agree very much with re-using NEPs 177 and 181. I’d also suggest using the nft_mint event as defined in NEP-297 and explained here.

1 Like

I feel I have already seen a proposal on to add NTT (non-transferable token) standard based on ERC-1238, but I cannot find it somehow.

1 Like

Agree with all the above. A consideration might be made for the inclusion of nft_transfer, but callable only by the contract owner? I’m thinking of a case where some NTNFT owner who is a crypto newbie loses their seed phrase and requests an administrator to transfer NFT ownership to their new account. Or maybe this isn’t kosher because then the contract owner could transfer NFTs without the user’s permission… just thinking out loud really.

Hi folks,

I’m going to be helping Sanyi and Balazs with creating this standard (I’m also with kycDAO).

@till_mb - thanks for the response, I think using the events from NEP-297 seems like a good idea.

@lachlanglen - yea that’s a common point raised when talking about non-transferable NFTs. I think a common solution is that the contract owner should then revoke the NFT in the lost account and mint another one to the new one, confirming everything with the user. I think this solution makes sense. It might be a little confusing to have a non-transferable NFT with an nft_transfer function which is still valid in certain cases.

There are some Concerns that i have

  1. Non Transferable NFTs for ticketing doesn’t seem right , Beacuse there are some cases let’s say a movie ticket which should be allowed to transfer before the expiry date (before the date of movie ) and can also be listed on secondary marketplace , so Non Transferable NFTs for Ticketing doesn’t seem right !

  2. In the Case of losing the account providing the power to the contract owner might not be the best thing , Because it provides too much dependency on owner and also some times the contact won’t have owner it might be DAO handling that , so a better way might be that you can have a 3/5 thresholded approval to revoke it where these are the people you trust or some other mechanism