EIP-5484 - Consensual Soulbound Tokens

,

@MicahZoltu and @TimDaub have contributed greatly on the topic, it might get you a better understanding of the discussion if you take a look at the related proposals/discussions links.

Again, this proposal is in review stage. Comments and suggestions to improve the EIP are welcomed and appreciated.

1 Like

Hi, EIP-4973 author here. We’d be interested to include consensual revocation into the specification. We already have consensual “taking” and “giving” of tokens. Please let me know if this is interesting to you.

2 Likes

Hi @TimDaub, I am glad my EIP is inspiring other EIPs :wink: . Thanks for reaching out and yes this sounds interesting to me. Let me know what I can help on EIP-4973 or anything that helps our community to achieve a consensus on SBT-like token interface. If all you want is to include the mechanism, go ahead and do it :slight_smile: I am fine as long as proper credit is given.

I am presenting my two cents here and hope people can join the conversation to help improve this draft:

  • Similar to real-world credentials and identities, SBTs can’t be changed but can be burned. It is important to signify who has the rights to burn a specific token. For example, a club membership can be burned by both parties, a paid membership can only be burned by the receiver, and a loan record can only be burn by the issuer.
  • Ideally SBTs’ content shall be immutable after issuance, this provides credibility and keep receivers’ identities safe from an unreliable issuer manipulating SBTs after issuance; however, it is difficult to enforce that in an interface, so the immutability requirement is kept only as a guideline rather than an enforcement.
  • The idea of consensual follows naturally. If we are trying to build a SBT ecosystem that every token’s identity can be trusted, it is important that receivers give consent to the identity, burn agreement, and metadata proposed by the issuer. Otherwise bad actors can issue fake identities that can’t be burned by receivers, destroying the overall credibility of the system.
  • The goal of this EIP is to provide a standard that makes lives easier when developing SBTs related services. Instead of an error message from calling transfer (this standard extends EIP-721 to be compatible with existing NFTs ecosystems), developers can now check the interface ID and avoid calling transfer on SBTs. They can quickly isolate SBTs issuing events from the unique emits, and there is a number code standard for different burn authorization.
2 Likes

I saw that you base your proposal on EIP-721. Maybe you’re interested in basing the proposal on EIP-5192: Minimal Soulbound NFTs, which introduces a minimal interface to signal that a token is currently non-transferrable.

Hey @TimDaub,
I actually considered basing the proposal on EIP-5192 when I was drafting it since EIP-5192 is very concise in what it’s doing. One concern I had was that EIP-5192, which’s still in review stage last time I checked, might change in the future.
Another thing to be noted is that EIP-5192 allows contract owners to lock and unlock the transferability of NFTs. In my vision of SBT, the token shall be untransferable throughout its lifetime. Though EIP-5192’s lock and unlock controls provide flexibility in some scenarios, they also undermine soulbound token’s credibility. In the long run, SBTs shall differ from NFTs in terms of how much trust users and verifiers can assume with confidence. If we take away the immutability of ownership, SBTs are just special NFTs that have certain transfer rules customized by deployers.

We just moved it into last call and hence it will be final in roughly 14 days: EIP-5192: Minimal Soulbound NFTs

Hi my friend. I would like to share with you a concept that uses the SoulBound Tokens to actually have an interface in the web3 space and also use them to build reputation in a new social concept. I’m building first the concepts on a white paper. Are you interested ?

@DonMartin3z Sounds interesting, hit me up with more details :slight_smile:

1 Like

Send me your email and take a time to check the whitepapet

it is final now since a few days

@TimDaub

Since you are quoting from the same reply, I am sure you also saw this portion of my concern. Again, immutability gives sbts its credibility. Allowing users to lock and unlock is just making a lockable nft with no credibility and trust behind it.

I understand your concern. If EIP-5192’s ownership was mutable I’d also think it’d undermine their credibility. The interface came together given the community’s feedback and their wish to not standardize around a purely immutable EIP. But we make sure it is in the EIP-5192 implementor’s discretion to permanently lock a token. It will comply with the standard.

Hey Tim,
The community has different feedbacks based on different concerns. I have seen pro-flexibility and pro-immutability feedbacks in our community’s various discussions surrounding SBTs. IMO, both standings have valid points. Furthermore, EIP-5484’s proposal describes how to do key rotation based on consensual burning mechanics, so it has a good balance of immutability that users can assume trust on, while provides some flexibility that certain sbts can be unbound from an address. My overall goal is to setup a guideline for good issuers to follow, and protect receivers’ rights on the identities they are receiving from easy manipulation of issuers. Again, I am not saying only one approach is right. I think a flexible sbt and a trustworthy immutable sbt can go hand in hand. Developers can pick on which one they would like to use based on their application needs.