feat: adding soulbound token

[robert-zaremba]

Soulbound Tokens (SBT) are non transferrable NFTs. Even though tranferability is not available, we define a recoverability mechanism.

SBTs are well suited of carrying proof-of-attendence NFTs, proof-of-unique-human "stamps" and other similar credibility-carriers.

---

NEP Status (Updated by NEP moderators)

SME reviews:

• @KazanderDad (NDC GWG): feat: adding soulbound token #393 (review)
• @alexastrum (Tenamint): feat: adding soulbound token #393

Contract Standards WG voting indications (❔ | 👍 | 👎 ):

• 👍 @frol: feat: adding soulbound token #393 (review)
• 👍 @fadeevab: feat: adding soulbound token #393 (review)
• -- @robert-zaremba (can't vote myself)

Wallet Standards WG voting indications:

• ❔ @Cameron-Banyan
• ❔ @MaximusHaximus
• ❔ @esaminu

Concerns

#	Concern	Resolution	Status
1	[Rober] Should we Emit NEP-171 Mint and NEP-171 Burn by the SBT contract (in addition to SBT native events emitted by the registry)? If the events will be emitted by registry, then we need new events to include the contract address.	[Robert] Don't emit NFT events. SBT is not NFT. Support: @alexastrum	open
2	[Robert] remove memo in events. The memo is already part of the transaction, and should not be needed to identify transactions. Processes looking for events, can easily track transaction through event and recover memo if needed.	currently removed, consequently also removed from registry transactions . Support: @alexastrum	open
3	Token Spam	[Robert]: we have a Burn event. Added example sbt_burn function, but keeping it not as a part of required interface. Event should be enough.	open
4	Multiple registries. Registry source of truth comment	Robert: this is a part of the design: permissionless approach. Justification for registry	open
5	[Robert] Approve the proposed multi-token	Support: @alexastrum	open
6	[Robert] Use of milliseconds as a time unit.	[Robert] Currently the standard uses milliseconds.	open
7	Should a burn function be part of a standard or a recommendation?	[Robert] We already have the Burn event. IMHO a function should not be part of the standard inteface (similarly to FT and NFT).	open
8	[Robert] Don't include sbt_soul_transfer in the standard interface, comment.	[Robert] moving outside of the required interface.	open
9	Privacy	[Robert] Concerns have been addressed: comment-1 and comment2	open
10	x	resolution	open

[frol]

@robert-zaremba Thanks for the submission! I want to double-check that you have reviewed the prior art: #359 (ideally, mention this in the NEP itself and cover pros and cons), and especially, the resolution #359 (comment)

[robert-zaremba]

@frol , thanks for the link, I didn't see it. I will look and put a review here.

[robert-zaremba]

@frol updated the spec and added consequences.

Compared to #359, this NEP:

• provides more concrete specification with implementation, which deviates from NFT standard: requires recoverability mechanism, requires "blacklist" registry, has optional revoking mechanism. Provides also the spec for events.
• more targeted narrative: it's not really about NFT, it's about Soubound: something that is assigned to an identity.
• outlined that the standard is needed for various other building blocks.

TL;DR it is not NFT - transferability.
However we may consider using related query function names eg nft_tokens_for_owner instead of currently proposed sbt_tokens_for_owner

[robert-zaremba]

may consider nft prefix where relevant to make the functions compatible with existing tools. eg : nft_tokens_for_owner instead of sbt_tokens_for_owner.

[frol]

Collision with the existing tooling will create more harm than help here as we already discussed in #359. The only way I can see that being resolved is by the NEP which will help to identify the supported extensions, read more in #129, #154, and #275.

[frol]

Actually, I was trying to refer to #351, which could be then used as a requirement for SBT NEP to unlock nft_ prefixes by saying that SBT = NEP-171 + NEP-330 + NEP-XXX (that just defines that nft_transfer is not available) - this way the tooling can reasonably handle the deviation from NEP-171 through introspection.

[robert-zaremba]

I was bringing up interface registration already in 2020, then created #154 ;)

[robert-zaremba]

If we reuse nft_ prefix then SBT is a subset of NFT, not an extension. Adding #330 makes sense. We need to discuss more if we want to be compatible with NFT standard, and carry over some of the shortcoming (like representing the token id as a U64 rather than u64 -- more about this in Considerations section)

[ryancwalsh]

Thanks for continuing to explore this feature. I think it's interesting.

I also hope that a discussion will resume about naming since "soulbound" / "sbt" might end up causing more confusion than clarity, especially as we hope to move towards 1 billion participants in the ecosystem. There was interesting discussion in 359.

It would be great to get more people to offer their thoughts and creative ideas. I think mindfulness in naming goes a long way towards helping something be successful.

[robert-zaremba]

I also hope that a discussion will resume about naming since "soulbound" / "sbt" might end up causing more confusion than clarity,

I truly think that neither Non-transfareable NFT nor Verifiable Credentials is relevant to what I'm proposing here.

1. Non-transfareable NFT -- I think it's wrong. Because it's more than non-transferability. It's more about identifying a "soul". Please read
   • the famous Decentralized Society: Finding Web3's Soul -- which is also a base for what we propose for NDC
   • interview: https://cryptobriefing.com/of-soulbound-tokens-and-crypto-politics-an-interview-with-glen-weyl/
2. Verifiable Credentials could be seen as subset of SBT. But it's not. It requires set of claims and privacy protocols. It would make more sense to model VC with relation to W3 DID standard. SBT is different, it doesn't require a resolver nor method registry. I think VC should also be carefully designed, but for SBT we need something more elastic.

[ryancwalsh]

It seems like you've thought a lot about it (and I may end up agreeing with you!), but I still feel unable to follow what you're saying.

Is your reason for using the word "soul" mainly because E. Glen Weyl did and his paper was popular?

I think "soul" is a tricky term (even aside from trying to introduce it into computer science).

Additionally (and maybe this question has been answered somewhere, but I haven't found it), if the concept is more about "identity" of the owner, then that would imply to me that ideally the token would be transferable (but somehow limited only to wallets owned by the original owner, and I'm not sure how that would be enforced). E.g. a driver can move her own driver license from one wallet to another. The license itself is still "tied" to the owner.

But if we're saying that that problem is too hard to solve for now (allowing the original owner to move the token between wallets that they also own), then maybe it feels like "non-transferrable token" is pretty accurate (although maybe still not sufficiently clear or marketable).

[robert-zaremba]

Is your reason for using the word "soul" mainly because E. Glen Weyl did and his paper was popular?

The reason I'm using word "soul" is to better qualify what we want to model here, and it's pretty accurate with respect to web3 accounts.

BTW: Identity could be also modeled using W3C DID. SBT is different.

if the concept is more about "identity" of the owner,

So this is a key difference between NFT as driving license, and SBT as a "soul".

• SBT Must be linked to an account, and have recovery mechanism. It must be bound to an account.
• NFT represents the driving license, not the account.

So, it depends what and how you want to model.

"non-transferrable token" is pretty accurate

IMHO, it's not accurate. SBT has different meaning, and different consequences.

[robert-zaremba]

Shall we organize a call to discuss the open issues in this PR and finalize it?

• multiset or binary SBT per account (so returning Option rather than vector)
• re-using nft_ namespace whenever possible?

[frol]

Sidenote, I was playing around with the idea of badges using SBT/NFT and realized that internal storage for such use cases could be optimized to only store the badge metadata once for a number of users receiving the same proof/badge/etc.

[frol]

Shall we organize a call to discuss the open issues in this PR and finalize it?

Given the holiday season is going, I think async will work better.

multiset or binary SBT per account (so returning Option rather than vector)

Ideally, cover the pros and cons of it in the NEP itself, and let's discuss them in the comments to those lines.

re-using nft_ namespace whenever possible?

Can you share your thoughts about what problem it can solve?

[ori-near]

Thank you to everyone who attended the fifth Contract Standards Work Group call today! The work group members reviewed the NEP and reached the following consensus:

Status: Approved

• 👍 @frol: feat: adding soulbound token #393 (review)
• 👍 @fadeevab: feat: adding soulbound token #393 (review)

Meeting Recording:
https://youtu.be/S1An5CDG154

@robert-zaremba Thank you for authoring this NEP!

Next Steps:

• @robert-zaremba to embed the benefits & concerns into the NEP document
• @near/nep-moderators To approve and merge the NEP
• @robert-zaremba to Endorse SBT support in Wallets

[frol]

As a moderator, I approve it and ready to merge it as all the requirements are fulfilled