Authors: Tim Daubenschütz (OP EIP-4973), Raphael Roullet (Violet), Rahul Rumalla (Otterspace)
Even since Vitalik's first post on Soulbound tokens, Weyl and Ohlhaver and him then followed up with a paper titled "Decentralized Society: Finding Web3's Soul", "Account-bound" (ABTs), "Soulbound" (SBTs), "non-transferrable" (NTTs), "name-bound" (NBTs), "non-tradable" tokens (NTTs) have been the focal point for discussion in the Ethereum community.
As the topic is rather fresh off the press and since not many people have had time to thoroughly think through some of the concepts proposed in Weyl et al.'s paper, we, the authors of the Account-bound tokens specification EIP-4973, have had to witness several uninformed takes we'd like to address with this post conclusively.
Below, segmented in sections, are the most common misconceptions about Account-bound tokens and how we think about them. And before we get into the meat, please let us prefix the article by stating that we, too, are "beginners" in this newly emergent field. But we're narrowly focused on delivering a standard, so we believe we have a position and voice worth hearing in the discussion.
A good primitive design intends to do one very specific task in a precisely defined and highly reliable fashion - this is one of the first principle approaches we took with ABTs i.e., how do we best bind tokens to accounts with consideration of consent and recoverability in mind.
{% twitter https://twitter.com/LefterisJP/status/1530845615030251520 %}
The most common concern we've heard when introducing the concept of binding tokens to an account is that it discourages users from frequently rotating keys. Given the standard's current state and that, indeed, revocation or revocation and re-assignment are a possibility, the standard itself makes no normative statements about an EIP-4973 ABT to be permanently bound to an account - even in case of key loss.
Quite the opposite, while EIP-4973 ABTs do indeed not implement EIP-721's transfer and transferFrom functions, EIP-4973 is intentionally designed to leave the responsibility of reassignment and revocation up to the implementer, i.e., a community, a protocol, a dApp, and not impose this as part of the primitive itself.
If you want, EIP-4973 introduces a non-normative transfer functionality using attestations and revocations that are freely implementable by anyone using the standard.
And while account recovery on blockchains is still an unsolved topic, it's important to distinguish between (1) preventative frequent key rotation and (2) switching keys upon compromise.
For example, in the case of a university binding a credential to a student's account, we'd assume the university would give the student the ability to revoke and re-assign their credentials to a new account at any time. This would include occasions where a user wants to (1) preventatively rotate their keys but also when they want to urgely (2) switch keys upon compromise.
In fact, (2) upon key compromise, Account-bound tokens as we define them in EIP-4973, without making normative statements on when revocations and re-issuance should occur, would allow an issuer to revoke and re-attest, or: "recover", from a compromised account to a newly instituted acccount.
Similarly, we're not making any normative statements about who should be able to revoke ABTs either, which brings us to the second most common misconception, namely that ABTs cannot be misused to dox someone permanently on-chain.
Yes, you're reading this correctly. We're not going to claim anything utopic here. While the scope of an Ethereum Improvement Proposal is far-reaching and powerful, it's not magic, and it cannot prevent the myriad possibilities of misuse.
But let us be clear: None of Ethereum's infrastructure or standards currently prevent misuse. If you want to dox someone's Ethereum account, there are already a billion ways to do so. And controversially, there is not a single way to delete that data. In fact, this is a discussion entirely out of scope for defining a token standard interface for wallet implementers. And there have been numerous amazing philosophical takes on the subject matter too. The best, in our opinion, is Ribbonfarm's "Blockchain's never forget," which accepts its "dystopian" property of data availability as a chance to rethink inter-human interaction.
Blockchains like Ethereum currently violate the EU's right to be forgotten. If user data is stored on Ethereum, it also violates the GDPR laws in many cases. There is a debate about the alegality of blockchains. And similarly, we think that there's acceptance needed towards understanding blockchain as so culturally diverse and international/global that, e.g., the EU or US's local laws won't "just" cut it.
It is not to say that we shouldn't use those laws as guiding principles for implementing technology. But, clearly, in the case of bringing up the abuse potential of ABTs, the community doesn't understand that any other token standard or any other Ethereum transaction can also contain abusing information linking to accounts.
So generally, we want to encourage more discussion around the topic: But we also want to be clear: This isn't a problem limited to ABTs. It is a problem of blockchains and should hence also be discussed on that level.
ABTs can be misused, and we must work on heuristics to maximally prevent misuse. Not only within blockchains, but also generally for any modern and inter(net)-national peer2peer protocols.
Then, once someone understands that ABTs can be re-issued using a sequential revocation and re-attestation, an accusation that has been brought up is that ABTs are vulnerable to censorship, namely because the implementer is in the position to permit the re-issuance.
And while, of course, this argument can be easily made, e.g., in the above case of a university issuing credentials to students, what is vital to understand is that the EIP-4973 account-bound token standard makes no normative statement about the conceptual structure of an ABT issuer.
Yes, a naive implementation of a university using EIP-4973 tokens may indeed be vulnerable to censorship. But that's because it's implemented fragilely. In contrast, and since the standard makes no normative statements, there's now also a chance to implement entirely decentralized credential issuance schemes we're probably not even able to imagine today.
But for making a visual example, let's imagine that a future decentralized university degree may not come from the centralized credential emitting unit - but rather that it could be a collection of professor's badges that the student earns through attending classes and being a bright apprentice.
ABTs do not mandate a token issuer to be a centrally controlled and censorship-vulnerable entity, and so the argument that ABTs are censorship-vulnerable likely stems from misinformation.
We should implement ABTs issuers in a decentralized fashion. We should properly rethink how our trust-crediting institutions work. We should fit them into the mold of the interfaces we have available. And if they don't fit: Let's change the interfaces.
Verified credentials are a good standard, and we believe there to be an intersection of utility between "Soulbound tokens" and VCs. But, we should collectively acknowledge that both credentials existing off-chain and on-chain can be used by implementers.
However, claiming that something should generally be off-chain or on-chain without hearing the use case first is likely going to lead to an uninformed take. We want to make clear that putting credentials on-chain is useful too and that, additionally, it is not entirely correct to conflate ABTs with verified credentials.
While, yes, ABTs look like badges or credentials, and since today they've been framed as such many times, the EIP-4973's author Tim Daubenschütz came up with the standard mainly to implement Harberger property.
The problem is that EIP-721 and other token standards make an implicit assumption about the ownership structures adhering to normative private property laws. He's been extensively blogging on the problems of normalizing those ownership properties - and how Harberger properties are inherently incompatible.
So a direct motivating factor for publishing EIP-4973 for Tim was that it would allow users to display an NFT-ish token in their wallet while giving wallet implementers the possibility to call EIP-165's supportsInterface method for feature detection.
So, strictly speaking, although we acknowledge the EIP-4973 standard to be useful for issuing credentials, it didn't even originate as a credential standard.
Then secondly, we think it's important to highlight why it may be useful to put badges/credentials on-chain. See, someone issuing a token is required to send a signed message to Ethereum, and its consensus ensures the signature and message's validity and integrity.
Additionally, messages sent to Ethereum are stored permanently for a rather negligible cost. Permanently. It can have benefits over storing credentials off-chain in case, e.g., someone is making a statement that they may want to redact later, but it shouldn't be redactable/deletable/censorable.
Also, by defining a standard interface for Solidity - which essentially EIP-4973 does, it allows ABTs to show up in a wallet next to other tokens. So we're taping into existing powerful infrastructure. Infrastructure that we've collectively built with users to, e.g., back up their secret words.
Lastly, although using oracles, we could do it with verified credentials too, having badge-ish tokens on-chain allows them to be used by smart contracts to make decisions.
And finally, a word on naming and binding to existing ownership structures.
Already within the working groups for EIP-4973, we've branched off and listened to the community's feedback that is interested in, e.g., binding credentials to ENS names. We've "forked" EIP-4973 to a new standard called "name-bound" tokens and submitted it as a draft PR to the ethereum/EIP repository.
Additionally, by intentionally binding tokens to accounts, we've further the discussion around whether that's a good idea. As a response, more generalized approaches like Micah Zoltu's EIP-5114 are now being submitted too.
We hope EIP-5107, EIP-5114 and EIP-1238 aren't the last attempts at defining Soulbound tokens for Ethereum. Rather, we think that for collective intelligence to emerge, many new ways of expressing credentials on-chain have to be discovered to understand what users truly want.
We must encourage other standards. Let's learn from each other to create a decentralized society and find web3's soul.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe