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)

9 Likes

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.

3 Likes

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

2 Likes

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.

1 Like

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.

2 Likes

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

2 Likes

Just for reference, someone recently proposed a Soul Bound Token for a mintbase grant, Puzzletask License NFT (Soulbound Token) by Adalt3ch · Pull Request #48 · Mintbase/Grants-Program · GitHub

and also NT NFT standard was reviewed by the Contract Standards Working Group
Contract Standards Working Group Meeting (August 22, 2022) - YouTube on August 22 with main concerns being

  • the reference implementation does not solve non transferability

  • there is no point in implementing non transferability if it cannot hold this property

  • will break prior ecosystem implementation, need to define availability of transfer, mint and burn standards (functions named the same)

  • discoverability issue, difficult to tell apart from NEP 171

  • burning not defined, so could be a SPAM NFT

  • burn method shouldn’t be defined by this standard and should be defined elsewhere

4 Likes

@starpause the NFT standard OG, sent over this which is some alpha. https://xclaim.club/ or NEAR.Watch

  • near.watch literally has a NFT widget that is in your wallet. You get by transferring NEAR to your wallet
  • xclaim.club lets you claim 2 NFTs, one with instructions, and 1 a dynamic NFT used as an advertisements, rewarding holders with $NEAR (extra for clicking on links) It even has an option to remove the NFT (burn method in v1.xcxp.near contract) but it didnt require me to sign again

https://explorer.mainnet.near.org/accounts/v1.xcxp.near

2 Likes

Somewhere in his fireside chat with Illia at BUIDL Asia, Vitalik concedes that SBT need some sort of recovery mechanism for them to be useful. One way of achieving that would be an NFT that can only be transferred by a DAO address.

Looking over all the examples above it seems like NFT need a way of defining who is allowed to transfer them, which seems similar to NEP-178 Approval Management. We just need to add flexibility so that the party approving transfer isn’t necessarily the owner of the NFT.

4 Likes

I am asking a question?
Is there a way to create an NT NFT now on the near protocol
can I get a link to it and also how to make an NFT marketplace

1 Like

I agree with all above

1 Like

Linking here our (NDC GWG) SBT design:

It’s a big undertake, and the goal is to create a well thought infrastructure for SBTs. After few iterations, the design recommends departure from the NEP-171 (NFT) compatibility due to the need of an atomic soul transfer feature. Look at the Abstract and Motivation sections of the NEP-393 for more details.

1 Like

The easiest way is to start with any NEP-171 example and then simply do nothing when nft_transfer is called.

1 Like