feat: adding soulbound token #393

robert-zaremba · 2022-09-14T06:15:01Z

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:

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 · 2022-09-14T11:23:25Z

@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 · 2022-09-15T09:42:50Z

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

Renamed query methods to make it NEP-181 compatible: * sbt_tokens_by_owner -> sbt_tokens_for_owner * sbt_supply_by_owner -> sbt_supply_for_owner

robert-zaremba · 2022-11-29T00:50:40Z

@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 · 2022-11-29T00:51:47Z

specs/Standards/Sould Bound Token/README.md

+    **********/
+
+    /// get the information about specific token ID
+    fn sbt(&self, token_id: TokenId) -> Option<Token>;


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.

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.

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.

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

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 · 2022-11-29T14:53:09Z

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 · 2022-11-29T15:03:13Z

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.

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/
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 · 2022-11-29T19:20:03Z

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 · 2022-12-02T01:06:51Z

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.

specs/Standards/Sould Bound Token/README.md

robert-zaremba · 2022-12-20T23:08:07Z

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.

specs/Standards/Sould Bound Token/README.md

frol · 2022-12-21T14:52:12Z

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 · 2023-06-30T18:35:01Z

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

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

…mentation

…EP document

frol

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

In #393 we defined Issuer (an entity authorized to mint SBTs in the registry) and SBT Class. We also defined Issuer Metadata and Token Metadata, but we didn't provide interface for class metadata. This was implemented in the reference implementation (in one of the subsequent revisions), but was not backported to the NEP. In this PR * we fix the name of the issuer interface from `SBTContract` to `SBTIssuer`. The original name is wrong and we oversight it in reviews. We talk everywhere about the issuer entity and issuer contract (even the header is _SBT Issuer interface_). * Renames `ContractMetadata` to `IssuerMetadata`. * added `ClassMetadata` struct and `sbt_class_metadata` function to the `SBTIssuer`. --------- Co-authored-by: Alexander Fadeev <fadeevab.com@gmail.com>

feat: adding soulbound token

365e8c2

frol added the WG-contract-standards Contract Standards Work Group should be accountable label Sep 14, 2022

frol added the S-draft/needs-author-revision A NEP in the DRAFT stage that needs an author revision. label Oct 7, 2022

ori-near added the A-NEP A NEAR Enhancement Proposal (NEP). label Oct 13, 2022

robert-zaremba added 8 commits November 29, 2022 00:40

set NEP number

7aa2f8b

Renamed queries *by_owner to *for_owner

1783a3e

Renamed query methods to make it NEP-181 compatible: * sbt_tokens_by_owner -> sbt_tokens_for_owner * sbt_supply_by_owner -> sbt_supply_for_owner

use proper doc comment syntax

515f35d

add copyright

fb488a8

adding optional sbt_token_for_owner

56397d0

typos

41d6020

added consequences

6c261e1

fix: nep 181 -> 171

cb96e8d

robert-zaremba commented Nov 29, 2022

View reviewed changes

robert-zaremba marked this pull request as ready for review December 2, 2022 01:06

robert-zaremba requested a review from a team as a code owner December 2, 2022 01:06

robert-zaremba commented Dec 13, 2022

View reviewed changes

specs/Standards/Sould Bound Token/README.md Outdated Show resolved Hide resolved

KazanderDad reviewed Dec 13, 2022

View reviewed changes

specs/Standards/Sould Bound Token/README.md Outdated Show resolved Hide resolved

robert-zaremba added 2 commits December 14, 2022 23:55

small note about events

c5c64c5

review: update summary

f29bfa2

frol reviewed Dec 21, 2022

View reviewed changes

specs/Standards/Sould Bound Token/README.md Outdated Show resolved Hide resolved

frol mentioned this pull request Dec 21, 2022

Non-transferable NFT Standard #359

Closed

robert-zaremba added 4 commits June 30, 2023 16:16

more notes about token ID and the available space

0ec0dca

language

c57a4d2

gramma

eece830

gramma

b816793

ori-near added S-approved A NEP that was approved by a working group. and removed S-voting/final-comment-period A NEP in the final REVIEW stage. Last chance to bring up concerns before the voting call. labels Jun 30, 2023

robert-zaremba added 11 commits July 11, 2023 18:40

small updates

57b4ac6

review

3a410f9

language

1f5001e

sbt_mint example update

673beb6

function comments

3fc3447

bold must

1149e98

add sbts method

66c794f

query: sbt_classes and docs

fe352b8

more docs about sbt_renew

7e784a2

Merge branch 'master' into robert/nep-sbt

06279c5

update metadata struct comments

51b14d9

robert-zaremba mentioned this pull request Sep 6, 2023

NEP: SBT Metadata Standard #504

Open

2 tasks

robert-zaremba added 2 commits September 7, 2023 01:23

add sbt_update_token_references method and event to the standard

ad56e5f

fix: events: should use issuer rather than ctr as per reference imple…

3ea249b

…mentation

robert-zaremba force-pushed the robert/nep-sbt branch from 4d0e590 to 3ea249b Compare September 6, 2023 23:23

robert-zaremba and others added 4 commits September 7, 2023 17:41

language

9f4c86e

add soul_transfer implementation notes

7b753f1

add benefits

912803f

Added the decision statement and link to the video recording to the N…

ceabc86

…EP document

frol approved these changes Sep 12, 2023

View reviewed changes

frol merged commit 3786d9b into near:master Sep 12, 2023
3 checks passed

robert-zaremba mentioned this pull request Jan 25, 2024

nep-393: add class metadata interface #528

Merged

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: adding soulbound token #393

feat: adding soulbound token #393

robert-zaremba commented Sep 14, 2022 •

edited by ori-near

Loading

frol commented Sep 14, 2022

robert-zaremba commented Sep 15, 2022

robert-zaremba commented Nov 29, 2022

robert-zaremba Nov 29, 2022

frol Dec 12, 2022

frol Dec 12, 2022

robert-zaremba Dec 12, 2022

robert-zaremba Dec 12, 2022 •

edited

Loading

ryancwalsh commented Nov 29, 2022

robert-zaremba commented Nov 29, 2022

ryancwalsh commented Nov 29, 2022

robert-zaremba commented Dec 2, 2022

robert-zaremba commented Dec 20, 2022

frol left a comment

frol commented Dec 21, 2022

ori-near commented Jun 30, 2023

frol left a comment

feat: adding soulbound token #393

feat: adding soulbound token #393

Conversation

robert-zaremba commented Sep 14, 2022 • edited by ori-near Loading

NEP Status (Updated by NEP moderators)

Concerns

frol commented Sep 14, 2022

robert-zaremba commented Sep 15, 2022

robert-zaremba commented Nov 29, 2022

robert-zaremba Nov 29, 2022

Choose a reason for hiding this comment

frol Dec 12, 2022

Choose a reason for hiding this comment

frol Dec 12, 2022

Choose a reason for hiding this comment

robert-zaremba Dec 12, 2022

Choose a reason for hiding this comment

robert-zaremba Dec 12, 2022 • edited Loading

Choose a reason for hiding this comment

ryancwalsh commented Nov 29, 2022

robert-zaremba commented Nov 29, 2022

ryancwalsh commented Nov 29, 2022

robert-zaremba commented Dec 2, 2022

robert-zaremba commented Dec 20, 2022

frol left a comment

Choose a reason for hiding this comment

frol commented Dec 21, 2022

ori-near commented Jun 30, 2023

frol left a comment

Choose a reason for hiding this comment

robert-zaremba commented Sep 14, 2022 •

edited by ori-near

Loading

robert-zaremba Dec 12, 2022 •

edited

Loading