Discussion for soulbound (ERC-721) tokens.
thanks for your submission, Iām happy youāve taken this step and I think thereās now more fascinating questions we can ask.
E.g. in the document you remark that:
Soulbound tokens are meant to be permanent badges/indicators attached to a persona. This means that not only can the user not transfer ownership, but the minter also cannot withdraw/transfer/change ownership as well.
But this makes me wonder that since youāre removing any ātoken-likeā functionality, if it is still useful calling the standard āsoulbound tokensā, when indeed its functionality is more akin to, as you remark yourself, badges/indicators/items etc.
1 Like
This is a good point. Perhaps Soulbound Badges would be a better name? Iām not opposed to changing the name.
1 Like
Thanks for this PR! Had a couple of thoughts:
- What are your thoughts on having a āBurnā event. Since there is no approval required for minting a Soulbound token for any NFT, many people may get unwanted tokens that they would like to get rid of. Or it may happen that the minter would like to revoke the soulbound token given to an NFT due to some malicious activity in the future.
- Moving the tokenUri and collectionUri to another interface that can act as a metadata extension (along with ānameā and āsymbolā functions) as done for ERC721.
This would break the immutability of soulbound badges/tokens. One of the benefits of immutability here is that once assigned, applications can aggressively cache results because they have high confidence that a token cannot be removed, reassigned, moved, mutated, changed, etc.
If they are not part of this standard, then they should be moved to a different EIP. I did consider this, but I felt that it was important to emphasize the immutability constraints within this EIP so it was clear that these badges were immutable through and through. It is worth noting that the content of the URI is delegated to future EIPs, but Iām hesitant to move even more.
Re: name/symbol: I feel like this information should live at the URI. It is descriptive metadata about the token, and these tokens are likely useless without the metadata (e.g., without image/description/details). If readers are going to have to lookup some metadata externally anyway, it feels like all of the token metadata including name/symbol should live there rather than being split on and off chain.
This standard represents a non-fungible, non-transferable, non-separable asset.
Naming thoughts:
- Non-Fungible Badge (NFB)
- Pairs well with NFT.
- Soulbound Badge (SBB)
- Follows the soulbound naming convention, but makes it clear this doesnāt have token-like properties.
- Soulbound Token (SBT)
- Leans on the Soulbound Token meme that is currently going around. This isnāt an ideal name, but it would be nice if this is what people thought of when they talk about Soulbound Tokens, rather than some other standard that decides to do a name grab.
- Badge
- Do fungible badges make sense? If so then NFB adds clarity over just Badge. If fungible badges donāt make sense, then perhaps the NF is redundant.
2 Likes
First, YES. I like the generic-ness of this standard better than 5107ās (the superset discussion).
Second, about the immutability in the tokenuri:
I think thereās value in immutable soulbound tokens but there is also value in mutable ones - and Iām not sure they need to be separate standards. If the goal is non-separateness of tokens, nothing mandates that the tokens themselves shouldnāt contain mutable references that can be updated and evolve over time. It seems like a different goal (which would be a great standard to have regardless).
I understand the goal is minimising the ability of the owner/minter to āeffectivelyā burn the token by changing it, but the documentation of past settings is still on the chain in case of a dispute.
Example use-case: a soulbound token representing a government ID. The token itself represents the personhood of the holder with their government ID, and is bound. The Metadata though can contain mutable information: legal name, photo ID, etc.
Itās useful, and since itās useful people will end up doing it and in practice what weāll see is 5114 tokens with IPFS links that point to HTTP links.
We can, and should, encourage implementations using immutable pointers and have mutable be used only if thereās a strong use-case for it - but not outright mandate it.
Third, regarding naming:
With names I tend to think familiarity and clarity are the most important bits. The soulbound concept is already known and popular, as well as the idea of a token (the token-badge distinction doesnāt seem meaningful to me). People who are already familiar with the soulbound token concept generally think of something similar to what is being implemented here. We can come up with something else, but that would require the unnecessary socialisation of a new name.
Consider me a noob here. Just sharing an idea on Soulbound Badge/NFT to eradicate the unwanted tokens getting associated with the user as @aditya0212jain mentioned
Consider a process that can be broken down in two parts 1. issuance 2. claim
On issuance the issuer of the soulbound nfts simply triggers _mint on address(0) and set _tokenApprovals[<token_id>] = <claimer_address>. This step can be done by overriding _mint and removing the require checks of to != address(0)
claim will be trigger by the claimer which in turn will map the msg.sender as owner and resetting the approver to address(0).
claim will have a requirement of msg.sender as approver. This will block any further calls of claim
There are of-course few more changes required. Again might sound stupid.
1 Like
@somcha.eth: I think this can be solved per-token and doesnāt need to be standardized. What matters is just that the mint event isnāt fired until both parties agree in this case. I would certainly support what you described, I just think it is a Best Practice, not a Standard.
@tomcohen.eth While I agree that some people will want what you have described in terms of mutable badges, I personally think that it isnāt following the spirit of soulbound immutability that I think is valuable. For example, if you change your name that should result in a new name token being issued. You would still be Alice, but you just now are also Bob. You can never become not-Alice, else the badges no longer hold their immutable guarantee.
If they do that, they arenāt an EIP-5114 token. 
Certainly, we canāt stop people from developing whatever they want, but if you donāt follow the spec then it isnāt an EIP-5114 token.
2 Likes
what do you think about soulbound badges that are owned (attached to) the soulbound tokensā¦
I.e. tokens that are owned / attached to the owner of another token.
1 Like
This is mentioned in the Security Considerations section:
It is possible for a soulbound token to be bound to another soulbound token. In theory, if all tokens in the chain are created at the same time they could form a loop. Software that tries to walk such a chain should take care to have an exit strategy if a loop is detected.
2 Likes
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
tokenUrialso 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.
+1 for Soulbound Badges
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.
1 Like
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.
1 Like
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.
So originally, EIP-4973 was simply a means to contribute to that discussion. Way before Vitalik et. alās paper we foresaw this problem at ETHDenver and I wrote about it: Non-Skeuomorphic Harberger Properties may not be implementable as ERC721 NFTs Thatās how EIP-4973 came about.
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.
2 Likes