Discussion of Soulbound Token Standard

Hi all,

Creating this topic to coordinate efforts on a NEP for Soulbound Tokens (previously non-transferable NFTs). Hoping to form a (rough) consensus here on some key decisions before continuing with the NEP itself.

Here are some important links for those unfamiliar to catch up on the history:

Importantly I should note there is an outstanding NEP for SBTs, but it hasn’t seen a lot of activity yet: feat: adding soulbound token by robert-zaremba · Pull Request #393 · near/NEPs · GitHub

I’m not trying to limit discussion, but in an effort to expedite this entire process I have a proposal that I’m hoping we could focus on first:

Given that the biggest concern with the previous NEP (359) was the confusion for indexers with standard NFTs, we would rename anything ‘nft’ with ‘sbt’. All else in the previous NEP-359 would remain the same.

@frol @nategeier - feel free to tag others that you think should be part of the discussion.



I can’t really contribute to the discussion, but I wanted to voice my appreciation for the effort of reviving the conversation around this, and thank you for providing links for context!

1 Like

Recap of past discussions and comments made there

Why last implementation was rejected as a NEP

    • 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

Additionally in order to prevent spam NFTs, there should be some type of accept/approval function, and a way to discard such a NFT. There is still the issue of transfering the wallets. Maybe there can be a clause discarding the NFT in the event of adding a full access key.

@starpause also mentioned about using DAO’s to facilitate recovery mechanisms for SBTs.

Also think this is a topic the new ZK community group could get involved in.

Great, also could take a hint from ETH where they have a locked and unlock method for SBT.

Could see a contract where the contract owners have the authority to lock the NFT or unlock it if say the user wanted to transfer it to another personal account or soul bound it for a particular period of time EIP-5192: Minimal Soulbound NFTs

1 Like

@JasperTimm Thanks for creating the thread. We created few proof of concept related to feat: adding soulbound token by robert-zaremba · Pull Request #393 · near/NEPs · GitHub

The idea of my work in NEP-393 is to create a robust standard for SBT. It covers concepts of: recoverability, account transferrability (which involves blocking / blacklisting the account from which we transfer the Soul) and algebraic operations on SBT sets. All of that is described in our hackathon submission, where we use SBTs to design a proof of humanity protocol: i-am-human.app | Devpost

We are integrating this concept into NDC Governance proposal, which requires the proof of humanity and builds up on the concept of web3 Soul (“Decentralized Society: Finding Web3’s Soul”).

In the DAO builder group, @starpause suggested the idea of Community Bound Tokens. Soul bound tokens that are based on an issuer since we are trusting an authority to issue such badges. Such an authority rather than an individual should be a DAO. He mentioned that Illia and Vitalik that a recovery mechanism is needed and such a recovery mechanism would be suitable for a DAO to manage. Additionally a burn mechanism where an individual or a DAO can revoke such a nft would be a way for an individual to not get stuck w a badge or for any bad actors that a community has deemed unworthy of such nft. I think this combined with nft seats from DAOs and groups in DAOs gives opportunity for granular permissioning through NFTs for DAOs. There is still the issue of a full access key being transferred in order to transfer a NFT, however this problem persists with giving a wallet private key with a sbt inside. However rotating keys on NEAR makes this issue more prevalent