Migrating discussion with @TimDaub from the PR to here regarding the terminology and requirements around immutability.
IIUC, there are two separate concerns being discussed:
Should we constrain the system such that it badges cannot mutate/change under reasonable operating assumptions?
How should we express this concept to the user.
For (1) I feel pretty strongly that for something to be compliant with this standard, it MUST be indefinitely cacheable, which means there needs to be a reasonable assumption that the data will not change. For data that isn’t content addressable, we cannot ensure this guarantee and if the remote data does change we may run into a problem where users don’t have a way to validate truth.
For (2) I’m much more open to alternative wordings. At the moment I disagree with @TimDaub that immutable is the wrong word. While technically true that immutable data can be mutated, for many systems (like IPFS, Immutable datastructure libraries, immutable databases, blockchains, etc.) this is only true under bizarre scenarios like a user who is intentionally breaking their own ability to validate data or where there are critical bugs/attack vectors in the software being used.
And these tokens won’t have the same ID. Meaning that for all purposes the issuer issued two identities to the same person. So now we’re forcing out-of-band revocation processes to prevent sybil attacks and inform consumers of the token which is the “correct” token.
The discussion is about if ERC5114 should contain an immutability guarantee - so the lack of immutability can’t be a counterargument.
You follow the spec to the letter: the tokenURI is an IPFS file. It’s just that this file then redirects, references, or points to an HTTP resource.
These tokens (and really any similar token) should not be assumed to be limited to 1 person, 1 identity. It is functionally impossible to solve the 1 person, 1 identity problem and I think that should be made abundantly clear to all users/developers (perhaps I should add something to security considerations).
It also may be valuable to add a mention that these tokens are intentionally irrevocable, just to help drive home the point that these are not meant to be used as a permission/security system.
I believe this is handled with this requirement:
// any external links referenced by the content at tokenUri also MUST follow all of the above rules
Instead of all this arguing about how a tokenUri should be structured: How about renaming tokenUri to e.g. getMultiHash to make it abundantly obvious and required that the Soulbound Badge must be a hash resolvable through IPFS?
Edit: IMO it’d be hella interesting if we had an EIP that gave recommendations for what are good URIs and what aren’t when used in e.g. smart contracts. Right now, and in the NFT space, there’s so much confusion and continuous discussion around this field and there’s no high quality document that outlines the pros and cons for various URI forms on blockchains.
IMO URI guarantee discussion is out of scope of Soulbound tokens. We should have a separate “what are good and bad URIs EIP document” and then reference it in the Soulbound Badges scope.
If you aren’t standardizing the content of tokenUri and collectionUri, I would argue that those functions shouldn’t be part of your interface at all. If multiple incompatible standards arise for EIP-5114 metadata, and they all use the same tokenUri function, a contract would not be able to implement more than one of them.
Further, I think these tokens should implement EIP-165, which would let dapps detect these tokens, and which metadata extensions they support.
I think the requirement that URI’s be censorship resistant and durable is going beyond what can be enforced by a standard. It’s simply too easy for a token viewing dapp to ignore that requirement and support HTTP(S).
That said, if you were to force a particular data storage standard (for example drop the ipfs:// prefix, and require that all URI’s be IPFS implicitly) then it wouldn’t be possible to bypass the requirement.
Another option would be to allow any URI, but also require a content hash function. That would at least provide immutability and allow any honest archivist to prove they have the correct data for a given block.
I don’t want to constrain to only IPFS, only to content that doesn’t change.
EIPs are for standards, not best practices. I agree that such a document should exist, just not as an EIP. I recommend a blog/article or static website that people can link to.
I argue that guarantees around what can be cached, how aggressively, and what security guarantees there are for the data SHOULD be part of a standard, as it is part of the interface between different actors communicating via this standard. In this case, the standard is asserting that the data can be cached indefinitely, and that the caller can verify the integrity of the data client side. The specifics of how that is achieved are up to individual implementations.
I can appreciate the argument here but I’m hesitant to lock in a data format standard in this EIP as one can imagine several competing standards on that front that build off of this EIP, yet I find it useful to give strong guarantees about the immutability of these tokens and make it clear what they are meant to represent.
You aren’t the only one. My tentative plan is to add EIP-165 support after this is merged as a draft. I need to spend some time figuring out how to do that, and I don’t want it to hold up merging as a draft.
My biggest concern with this EIP is that it practically has no one asking for it.
With EIP-4973, I drafted a standard to institutionalize non-transferrable tokens such that e.g., we stop the malpractice of “soul binding” NFTs to accounts with reverting on transfer and transferFrom. I did so because of a practical technical problem I had faced in the https://partialcommonownership.com/ working group where we were discussing if Harberger property should be friendly transferrable or not.
Then, after some time, people that wanted to mint badges found EIP-4973 interesting too. In fact, for more than a month, I’ve been now directly iterating as a freelancer with two startup companies in the space. We’ve met up in Amsterdam and Berlin to further discuss EIP-4973. It is my conviction that we’re doing something that’ll eventually help their products. EIP-4973 is a product of the problems of people building in the space.
So having done all of this work, and we’ve also documented lots of it in the EIP-4973 discussion thread, I have to say that I don’t “get” EIP-5114.
To me, it is a nice and elegant theoretical solution to what was laid out in Vitalik et al.'s paper. I can see lots of great new things happening when tokens can be bound to other tokens. It’s seriously interesting.
But at least until now, I don’t know anyone that needs this. I’m not aware of one project that has done what is described here. And contrary to that, there are now countless NTTs on Ethereum all using revert to achieve what is properly laid out in EIP-4973.
So I was wondering, to the authors: Do you think EIP-5114 and EIP-4973 do fundamentally serve different use cases, and should they go towards standardization in parallel? Or rather, as @MicahZoltu you’ve framed it in the EIP-4973 discussion thread, should EIP-4973 fail (and EIP-5114 take over?)
I’m not sure if the question is directed at me (the only author) or someone else, but I’ll answer none the less.
As I have mentioned elsewhere, I think that permanently binding assets to Ethereum addresses is a really bad idea. I created this so when people go looking for standards around permanently binding assets, they’ll hopefully stumble on this and ultimately choose to not bind assets to addresses.
Just because people want/do a thing doesn’t mean it is a good idea for the ecosystem, society, or users. While I believe people should be free to do what they want, I will still encourage people to do what I believe is best for society/end-users. Binding assets to addresses may be good/simple for developers, but it is not good for users long term and thus I advocate pretty strongly against it, even if it is what people think/say they want.
People also want custodial coins, censorship, government backdoors into software, no financial privacy, etc. and these are all things that I similarly advocate and develop against.
In EIP-4973 we do not advocate for perma-binding assets to addresses. We put revocation mechanisms into the hands of e.g. the contract implementers. ERC20 and ERC721 do that too, they don’t enforce implementation, just interface definition. E.g. I think we should standardize that ABT receivers can disassociate themselves on-chain. But how to do it? Your help would be useful.
Rather than going on your own, I’d be happy if we could integrate solutions to your concerns in EIP-4973 somehow.
If a token can be unbound to account A and then bound to account B, then it isn’t really soulbound (it isn’t non-seperable, non-mergeable). It is just an NFT with complicated transfer mechanics.
If the token can only be unbound, then it doesn’t solve the problem of encouraging key rotation/wallet upgrades (the problem that I think needs solved).
If the process of transferring a token is sufficiently complicated, users are less likely to rotate their keys. It is already bad enough that a user wanting to rotate keys or upgrade their wallet has to manually transfer all of their assets. If they also have to petition a governance board when they want to roll their keys or change wallets, they will be strongly discouraged from actually doing it.
If a person or group of people has the ability to unbind a token, then that person/group of people can effectively engage in censorship. e.g., if some individual has soulbound badge X, one can imagine a governance group or operator deciding to revoke that individual’s soulbound badge, potentially against that person’s desires (the system isn’t censorship resistant).
I agree with everything you said above. But you’re pessimistically looking at the worst-case scenarios where people implement the standard, e.g., engage in censorship or discouraging key rotation.
And I’d like to remind you that practical account binding on Ethereum happens almost everywhere. Anytime a contract isn’t issuing a transferrable symbolic token defining the interaction rights with a contract, it’s account binding. When contract implementers store a type address and then require it to call functions, in many cases it is account binding!
IMO it’s important to, e.g., explicitly outline what’s good account binding vs. bad account binding. And to be explicit here: E.g., anything to do with airdrops that account-binds to past interactions is, e.g., bad as it discourages key rotation and makes people lose out on potential additional funds (e.g., I have one address that I cannot access the Optimism Airdrop).
But, IMO, if we dwell on the problem long enough, I think there are legit account-binding applications. I find it unrealistic to assume that users will never account-bind functionality. It has already happened so many times.
For E.g. MolochDAO binds voting rights to accounts but allows a MolochDAO member to ragequit. Given your pessimistic outlook on account-binding, would you say MolochDAO actively discourages key rotation? Because alternatively, one could say that an individual that wants to key rotate within a MolochDAO can “ragequit” and get re-accepted by the group (is that censorship if the group rejects re-entrance)?
On the other hand, e.g., your proposal in EIP-5114 wouldn’t solve this as, e.g., MolochDAO assumes voting rights to remain bound to an account. IMO we can only gain by standardizing account-binding and by identifying what are good practices and what are bad practices.
As I have mentioned previously, just because people do a thing doesn’t mean it is a good thing or something that should be encouraged/supported (such as by standardizing the behavior). If you want to argue the point that account binding is good (and worthy of supporting via standardization efforts), I think you should focus on coming up with concrete use cases for account binding that are achievable and don’t have negative consequences.
Just about every use case I have seen for account binding is either unachievable --what people want is human-binding, but that isn’t actually possible and they treat an account as a proxy for that-- or it comes with significant consequences like censorability, permissioned systems, discouragement of key/wallet rotation, and increased tracking/surveillance of humans.
TL;DR: I don’t think there are any good practices for account binding, it is a rotten concept to the core and we should be doing everything we can to discourage it. Standardized bad-thing is still a bad-thing, it is just now easier to build tools for bad-thing.
You are being unclear what equates account-binding and you’re arbitrarily pick examples where account-binding outlines unfavorable outcomes that make you “win” arguments here. You haven’t answered my specific example with MolochDAO.
E.g. EIP-173 is binding ownership of contracts to accounts. According to your logic, you should do anything possible to avoid getting this proposal to status “final” or offer an alternative.
Where does account-binding start according to your definition? Yes, EIP-173 has a transferOwnership method, does that mean the contract’s ownership isn’t account-bound? Is account-bound anything that doesn’t implement a standardized transfer function?
If a key gets compromised, how does it help having a transferOwnership method assuming a thief can frontrun that call to steal ownership?
Additionally, many contracts explicitly implement Ownable to e.g. control or “censor” functionality.
what people want is human-binding
100% disagree. Everybody is maximally against this.
Does soulbound token binding bind humans to address, or address to address? Or is tokenId and address bound? This is a topic worth exploring.
How to unbind soulbound token after binding? Unreleasable binding may cause some problems, but this kind of release is definitely not arbitrary release, what is it?
Does soulbound token need to be compatible with widely used standards such as erc721 and erc20? I think it is necessary, otherwise it will bring a lot of ecological compatibility problems to create a token standard.
Who initiated the binding of the soulbound token? How to ensure that no one can generate a soulbound token for an address without consent, it is a serious topic, if someone can generate a soulbound token for you without consent, it will be a very serious disaster.
What are the specific scenarios of soulbound token? It needs to be supplemented by some specific scenarios in different fields to define the exact characteristics that SBTs should have.
btw. We are also exploring some scenarios about soulbound token, which can be used as a reference, but our scenario is a further Paired bounding scenario, which creates a new identity for the address and stores the relationship between the paired address at the same time. It is an extend of the standard erc721, and its characteristics are mainly:
implement from erc721, most NFT usage scenarios are seamlessly compatible
non-transferable and non-sellable, one person can only have one valid Token at the same time.
mint paired soulbound token through multi-signature flow, Mint will issue 2 Soulbound Tokens at one time.
can be destroyed through multi-signature flow, and new Soulbound Token can be minted with other addresses after burn.
Behind the token, we store the relationship between two tokens, and the bounding relationship can be queried through the contract interface.
But we haven’t considered making it a standard yet, because his scene is still very limited, and it’s more of a social network attempt.
apart from the discussion thread that explains very interesting points , i want to ask an higher level question, how can the concept be modularised similar to Lens protocol to include other aspects of the identity that can be upgradeable ? thanks
Yes, I think Molach DAO’s design is bad and should not be copied.
EIP-173 supports transferring ownership, so it isn’t a permanent binding.
Assets (of any kind) should be freely transferable by the user with as few hoops as possible. A transfer function executable by the owner is probably as close as we can get to ease of transfer. While some centralized/governance based transfer process is marginally better than no transfer ability at all, I argue that that margin is so tiny that the benefits it provides are far insignificant compared to the harm done by supporting/encouraging the pattern.
You can already do this today, and people have done this already (created NFTs that can be given to a user but the user cannot get rid of them). A soulbound standard can’t prevent this.
No. Soulbound tokens serve a different purpose, and in order to serve that purpose well they may (and in this case do) have a different interface.
Badges/credentials assigned to a persona. You can think of this as a component of a reputation system. A persona builds up reputation over time (good or bad) and this provides a mechanism for ensuring that persona cannot be merged with another persona and cannot be split into multiple personas.
In this EIP, soulbound tokens are bound to an NFT of some kind. That NFT can then be bound too an address, which may or may not be solely controlled by a human. It is not possible (and some would argue not recommended) to bind to a human.
I am of the opinion that standards should be as simple as possible, and I think this EIP is about there. One can (and some do) argue that the URI stuff should be removed to make it even simpler, but the point here is that I am pretty firmly against making it more complicated.
Within EIP-4973, we’re now requiring implementers to always allow ABT receivers to call function burn(uint256 _tokenId). So the token is technically still account-bound, but not permanently. E.g. a user can always “transfer” the token to address(0). Here’s what our document says:
An ABT receiver must be able to always call function burn(address _tokenId) to disassociate themselves from an ABT publicly.
and
We expose function burn(address _tokenId) and require it to be callable at any time by an ABT’s owner as it ensures an owner’s right to publicly disassociate themselves from what has been issued towards their account.
Additionally, we’ve adjusted the “Exception Handling” section:
Given the non-transferable between accounts property of ABTs, if a user’s keys to an account or a contract get compromised or rotated, a user may lose the ability to associate themselves with the token. In some cases, this can be the desired effect. Therefore, EIP-4973 implementers should build re-issuance and revocation processes to enable recourse. We recommend implementing strictly decentralized, permissionless and censorship-resistant re-issuance processes.
Have we come your way with these changes to address some of your concerns? Do you feel different now about EIP-4973?
