EIP-5484 - Consensual Soulbound Tokens

[BuzzCai]

@TimDaub

@BuzzCai

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.

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.

[TimDaub]

@BuzzCai

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.

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.

[BuzzCai]

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.

[BuzzCai]

Moved to Last Call
ddl: 2022-11-05

[exstalis]

@BuzzCai

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.

Hi, I’m really interested in your opinions. The confidence level between parties can assume is a great point we need to address. Do you have use cases in mind or would you like you to simulate a scenario on that? I also would like to connect with you on creating more fairness for token holders applying more sustainable ecosystems thru SBTs.

[BuzzCai]

Hey @exstalis,
Recently I have been talking to ethSF teams who are interested in building sbt projects. I have heard some very interesting ideas applying sbts to gamefi, dao, and web2 scenarios. Soulbound definitely has a lot of potential solving problems that couldn’t be solved by NFTs, and many of us are experimenting with the potentials. If you have any interesting idea to share, I am happy to chat.

[TimDaub]

Frankly and respectfully, because the following is gonna sound harsh, your last message and your move forward show that you haven’t committed enough time to properly understand EIP-5192 and EIP-4973.

• EIP-5192 is a perfectly capable interface for expressing both permanently “soul”-bound tokens (in a code-immutable way) as much as it can express a permanently transferrable token (in a code-immutable way). E.g. public-assembly has shipped a permanently account-bound token with EIP-5192: Add first cut ERC5192 interface by TimDaub · Pull Request #6 · public-assembly/curation-protocol · GitHub, but entirely different flavors are possible!
• EIP-5484 is rushed into finalization (which happens in a few days on 2022-11-05) although being unclear and incomplete about, e.g., soul binding. Yes, you named it “… Soulbound token,” but while the specification acknowledges non-transferability and its issues, it does NOT specify clearly how binding needs to be implemented., E.g., this section:

One problem with current soulbound token implementations that extend from EIP-721 is that all transfer implementations throw errors. A much cleaner approach would be for transfer functions to still throw, but also enable third parties to check beforehand if the contract implements the soulbound interface to avoid calling transfer.

I’m writing this with this intensity as it was pointed out to me that the specification is now already moving into finalization (of which I was surprised - I should have paid more attention) without meaningfully addressing the community’s feedback (e.g., mine).

I think that your burn and authorization logic around consent is actually really valuable, and they represent what, e.g., the authors of the DeSoc paper have described. I’m being so passionate about this all here because I think your work so far has been quite impactful and important! So my demand is asking you to roll back the status to “Review” and do the appropriate changes towards better consistency and completeness of your document. Please!

[BuzzCai]

Hey @TimDaub,

With all due respect, the followings are gonna sound harsh too.
I noticed you had the tendency to call competing proposals “rushed into finalization”, and saw you’ve done it several times in the past. I was expecting you post something similar when I moved to last call, and here we are. So this is my response to that:

1. Your EIP-5192 Minimal Soulbound NFTs was created on June 30th, and moved to last call on Aug 29th, roughly 60 days. While this EIP-5484 was created on Aug 17th and moved to last call on Oct. 27th, roughly 70 days. Ten more days than your proposal.

2. I know the change you actually want me to make is again the change you personally demanded earlier, which is to base EIP-5484 on your EIP-5192. I have responded to that previously in this post, which received great community feedback and you never responded to.

@BuzzCai

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.

3. It is interesting you brought up community feedback.

@TimDaub

without meaningfully addressing the community’s feedback (e.g., mine).

Here is a community feedback I am sure you saw and ignored.

@BuzzCai

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.

This conversation happened during the final call of your proposal EIP-5192. I am wondering why you pushed your proposal all the way to final when you didn’t, as you phrased it, “meaningfully addressing the community’s feedback (e.g., mine).”
The only difference is that I didn’t come to your proposal asking you to revert your EIP-5192 status to review because I considered there is a conflict of interest between us competing proposal authors.

4. The list goes on, but really these are the important points I want to make for now. I know you knew this proposal isn’t rushed to finalization, and you knew I read EIP-4973 and EIP-5192 along with all their discussions multiple times as in the very beginning I posted the links to the relevant discussions and proposals for people to refer to.

@BuzzCai

• Related Proposals/Discussions:
  1. EIP-4973 - Account-bound Tokens | Discussion
  2. EIP-5114: Soulbound Badge | Discussion
  3. EIP-5192: Minimal Soulbound NFTs | Discussion

@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.

I know that you are accusing this proposal being rushed and me being unfamiliar with the two proposal in order to undermine the credibility of this proposal to community members who haven’t been following along. Frankly I understand why you do what you did as a competing proposal author, but hey we are not writing these proposals for personal or business benefits, and I think as a very active member of the forum, you are better than that.

[TimDaub]

@BuzzCai

Another thing to be noted is that EIP-5192 allows contract owners to lock and unlock the transferability of NFTs.

Contract owners e.g. EIP-173 owner() address CANNOT change the locking or unlocking.

@BuzzCai

In my vision of SBT, the token shall be untransferable throughout its lifetime.

That is possible with EIP-5192 as demonstrated with the link I shared in the public assembly project. For your convenience: Add first cut ERC5192 interface by TimDaub · Pull Request #6 · public-assembly/curation-protocol · GitHub

@BuzzCai

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.

That’s achievable with EIP-5192 but dependent on the respective implementation.

@BuzzCai

This conversation happened during the final call of your proposal EIP-5192. I am wondering why you pushed your proposal all the way to final when you didn’t, as you phrased it, “meaningfully addressing the community’s feedback (e.g., mine).”

This feedback isn’t addressible because it’s based on false premises. Contract owners cannot universally lock and unlock EIP-5192 tokens as this is specific to the implementation. EIP-5192 enables permanently locked, permanently transferrable and all other possibilities depending on an implementation.

@BuzzCai

I know that you are accusing this proposal being rushed and me being unfamiliar with the two proposal in order to undermine the credibility of this proposal to community members who haven’t been following along.

My intention for objecting EIP-5484 is that I think it would dovetail well with EIP-5192 but that you don’t seem to fully understand how it works therefore I’m asking you to try to understand it completely before marking urs as final.

[BuzzCai]

In your EIP-5192 thread, specifically the post that inspired you to include the locked function.

@aram

This will allow wallets to check for transferability for UX, allows implementers more freedom around mint/burn and maybe even allowing transfers in certain situations.

@TimDaub

yeah, @aram I think this is a good idea as it’ll still allow someone to inseparably bind a token to an account, but leave that choice to the user (which IMO should ultimately have the freedom of decision).

The effect is that it can shut up the nay-sayers arguing for better key rotation practices in SBTs as the interface is neutral towards the concept of permanent locking.

You specifically mentioned token transferability is possible, and this “shut up the nay-sayers arguing for better key rotation”. It doesn’t matter who has the rights to change token transferability, contract owner of token receiver, the fact that this is changeable makes my previous point:

@BuzzCai

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.

Again, it’s not about what is “possible” or “achievable with EIP-5192”. What’s important is that the flexibility of EIP-5192 diminishes credibility of SBTs’ immutability.

If you want to argue that oh wait, I have changed my mind, and EIP-5192’s lock status CANNOT be changed by either parties after issuance. There are few things you have to do. First,

@TimDaub

Contract owners e.g. EIP-173 owner() address CANNOT change the locking or unlocking.

This should be in your EIP’s specification section, not here in the comment section of a related proposal. Your proposal made it very vague and ambiguous on who has the rights to change/assign lock status. Previously I thought you leave it to the implementation to decide the specific rules, but if you want to argue that lock/unlock status is permanent after issuance (which is basically what you are arguing in the previous post), your current EIP-5192 definitely needs a lot of modification on clarifying the rules, and I recommend you roll it back to review status if you intend EIP-5192’s lock status to be permanent after issuance.

[exstalis]

Thank you for your response! I would love to learn and also make use of myself in exchange for technical support
My idea is to create an adaptive learning platform - for children - using an LLM as a guidance system in a web3 setup. I feel like SBTs can be used to strengthen community traits, and different industries/communities can use them for different purposes. There are many use cases, but my idea is about changing the way we teach things. Thru adaptive learning, I think we can make more interactive or more individualistic education for the next generation. There is more to add to that. But, briefly put, it’s for children who are coming from different socio economic backgrounds.

[TimDaub]

@BuzzCai

Again, it’s not about what is “possible” or “achievable with EIP-5192”. What’s important is that the flexibility of EIP-5192 diminishes credibility of SBTs’ immutability.

We cannot enforce an implementation via an interface. If you’ve heard of e.g. sleepminting attacks, then they demonstrate that despite the EIP-721 standard mandating the mint event to go from addr(0) to the transaction.from field, someone may not implement that to fool Rarible or Etherscan user interfaces: What Is Sleepminting And Will It Ruin NFT Provenance?

Solidity interfaces do not enforce implementation.

For any EIP-5484 or EIP-5192, without users specifically auditing the actual implementation there is no credibility that implementing the interface correctly also means immutably soul binding the token. This information can only be derived from actually auditing the entire code of any contract.

Here, a fully working transferrable “Soulbound EIP-5633” implementation.

// SPDX-License-Identifier: CC0-1.0

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "./IERC5633.sol";

/**
 * @dev Extension of ERC1155 that adds soulbound property per token id.
 *
 */
abstract contract ERC5633 is ERC1155, IERC5633 {
    
    /// @dev See {IERC165-supportsInterface}.
    function supportsInterface(bytes4 interfaceId) public view virtual override(ERC1155) returns (bool) {
        return interfaceId == type(IERC5633).interfaceId || super.supportsInterface(interfaceId);
    }

    /**
     * @dev Returns true if a token type `id` is soulbound.
     */
    function isSoulbound(uint256 id) public view virtual returns (bool) {
        return true;
    }
}

[BuzzCai]

Hi exstalis,

Interesting idea Can you elaborate on what do you mean by LLM, and your ideas on how SBTs can be used to strengthen community traits? You can DM me about ur ideas so we can keep this thread focused on the EIP, thanks.

[BuzzCai]

@TimDaub

Solidity interfaces do not enforce implementation.

You are explaining something so basic I don’t know what to say.

@TimDaub

For any EIP-5484 or EIP-5192, without users specifically auditing the actual implementation there is no credibility that implementing the interface correctly also means immutably soul binding the token.

It is pretty obvious we cannot force the exact implementations of sbts. If you read my previous posts carefully:

@BuzzCai

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.

you wouldn’t waste your time explaining basic concept like EIP cannot enforce implementation, since the goal of this EIP is to set guidance, build credibility, and create a standard for burnauth number coding, not enforcement.
Furthermore, you are dodging all the important questions I have posted and focusing on useless details that you might think could help win your argument.

This conversation has become a total waste of my time. I am not going to respond to your further questions/comments if it’s just another childish attempt trying to nitpick some nonexistent problems to make yourself feel better.

[exstalis]

Great! But how do i dm you, can you dm me first so that I can learn?

[BuzzCai]

Update: Status → Final

[donnoh]

I want to implement a SBT extending ERC721, what should I do? Do I have to implement both EIP5192 and EIP5484? Do I have to emit both a Locked and a Issued event on minting? It is very confusing to have two standards referring to the same thing without acknowledging one another. @TimDaub @BuzzCai

[TimDaub]

depends on what functionality you need. If you want to lock and unlock ERC721 tokens, just implement 5192 and that‘s it. If you need burn authorization and 5192 compatibility, come talk to me and we can find a solution with e.g. a new standard

[AustinZhu]

@BuzzCai
Recently I’m working on an experimental implementation of semi-fungible SBT supporting EIP-5484. Having a BurnAuth defined when issuing SBT makes revocation rights more explicit.
I would really appreciate your feedbacks on semi-fungible SBTs.

[Kean0322]

Can I get this whitepaper? thanks.