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.
Some suggestions and opinions:
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:
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.
we write a contract at: GitHub - marryinweb3/ERC721-520: NFT-like Soulbound Token implement
and implement a dapp at: https://marry3.love
we can talk about soulbound tokens more at here
thanks Micah ,
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-4973implementers 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?
“Soul Binding” concept seems fresh at crypto space but it already existed at online game industry for decade. Like your personal equipment only you can own it. Therefore, own it or destroy it. I believe you all know and not difficult to understand right.
For what I have learn above that EIP-5114 serves several purposes:
What I have learnt currently, the EIP-5114 seems has limited usage scene like NFT.
Therefore what I write above, like the game asset, EIP-5114 combines the unique ownership, like an identity, can’t trade. Merit is shine, very unique and exclusive, but the shortage is also obvious, priceless at some point, valueless.
However, could we think about its original data upgrading?
Although EIP-5114 serves its purpose to untransferable(binds the soul), the soul or the attribute could improve by time or by experience. So I believe embed traditional NFT standard like EIP-165, and need to consider about upgradable metadata like EIP-4906.
For what I found the current ERC721/1155 are great, and transferable, tradable, EIP-5114 serves another purpose: emphasizing crypto personality, identity.
In sum, EIP-5114 is a great exploration, tokenUri and collectionUri not a matter, but still need to consider the upgradable metadata embed issue.
All in all, is an NFT.
I don’t think this is a bad feature, but it does prevent aggressive caching, which is unfortunate.
I contend that it is not possible to build a censorship resistant process for re-issuance, which is why I’m against this pattern.
Also, even if you could solve that problem, if it is difficult to go through the re-issuance process then people are less likely to engage in healthy security practices like key rotation. For a real world example, one of the Ethereum Core Devs leaked a private key holding a bunch of testnet ETH on GitHub. They knew they made this mistake when it happened, but even though all of the assets were trivially transferable it was still “too much effort” to rotate the keys (they would have to update a bunch of scripts with the new keys). Something like 9 months later someone stole all of their testnet ETH. I bring this up because it shows that even people who understand the security risks will still be stopped from following good security practices if it is too difficult, and we should make it as trivially easy to do the right thing as possible, which means as few barriers to address rotation as possible.
I’m pretty strongly against upgradability, because it introduces an avenue for censorship by the issuer. One can imagine an issuer issuing an “upgradable” token and then if the current holder of that token does something they don’t like, the issuer can “upgrade” the token have no metadata, or have offensive metadata, or otherwise alter the value of the token out from under the owner.
Thanks Micah, I am totally agree with you.
The point I mention above is, metadata could be upgraded through the contract or the rule itself, not through human behavior.
Definitely this may require a huge foresight designing in a project, but I believe once it solved the current market would forward to next dev stage.
Not sure what you mean exactly, please consider elaborating this point in the EIP-4973 discussion thread and we can try to find solutions.
Please let me make yet another argument for ABTs being censorship-resistant that I haven’t seen anyone make. But first, I want to highlight the following:
For example, as I’ve pointed out multiple times, many smart contracts today do account bind certain functionality. E.g. within a Gnosis Safe, we bind the partial ownership over calling functions and executing mutually agreed-upon transactions to accounts. And it isn’t done in any structured way where e.g. an indexer coming across a Gnosis Safe contract and another account-binding contract can effectively extract and transform this data. I wanna say that there are now interface standards and that’s bad!
Similarly, as I’ve outlined, with Harberger taxes and the newly resulting property class that I call “Harberger property”, we want to bind a property to a smart contract and it cannot have a transfer function. Same problem: No consensus on interfaces.
Within MolochDAO, voting rights are account bound and rage quitting and re-proposing entry would help to switch accounts.
Finally, I want to say that these use cases are very different from what is e.g. laid out in Vitalik et al.'s DeSoc paper and it is also very different from the Verified Credentials specification.
The above mechanisms have been used within Ethereum for years now and they work. I don’t know anyone that refuses to use the Gnosis Safe on the basis that it makes key rotation difficult. The exact opposite is true: Using a Gnosis Safe in a high-trust group makes key rotation of an individual a piece of cake.
And what you’re describing above with the Testnet dev would not have happened if those funds were held in a multi-signature wallet!
But, I’ve said at the beginning of this post that I want to make an argument for censorship resistance, and here is it:
But in that later case, I want to say: Let them do it!
The blockchain keeps all data stored permanently. So if a group deems it a good idea to structurally censor or discriminate against others: all of their misbehavior is forever etched into the blockchain and I trust that eventually, the broader public will come to understand that what this group has done to others is bad!
So for me, regarding censorship resistance, I think in practice is solved as blockchain’s transparency holds everyone accountable.
There may be a bit of a miscommunication here. I don’t think attaching assets to an address is bad. A Gnosis Safe having an owner is not a problem. The problem is permanently binding assets to an address, or making it more difficult than absolutely necessary to transfer an asset between addresses is what is bad. Also, there are plenty of places where immutable address makes sense. For example, if you are building something that integrates with DAI, it makes total sense to set the DAI address as immutable. The problem arises when you are making ownership immutable.
Anytime we are attaching asset ownership to an address, there must be a way for the owner address to change, and that process should be as easy/simple/censorship resistant as possible.
Censorship and curation are both on the same spectrum, and the line between them is extremely fuzzy and extremely opinionated. If you can curate, then you can censor. Whether any given action is “censorship” or “curation” is entirely in the eye of the beholder. To some, Twitter and YouTube actively engage in “curation”, while to others they actively engage in “censorship”.
While I do think there is value in curated systems, in most cases you don’t need a blockchain to build them. There are some designs for curated systems that do require the censorship resistance feature that blockchains provide (e.g., choose-your-own-censor), but they are definitely the outliers IMO.
For the purpose of this discussion, I think this is out of scope because I’m advocating for a censorship resistant soulbound token, which functionally means it is also resistant to curation as the two things come as a packaged deal.
OK awesome, this clears it up for me. Thanks for the discussion 
thanks for response , totally agree on this and given that EIP has to be an simple and immutable representation of the interface / programming pattern
It’s probably getting much too late here, but I’m not figuring out which is better for undercollateralized loans use case; EIP-4973 or EIP-5114?