# Addressing the most common misconceptions about Account-bound tokens.

Authors: [Tim Daubenschütz](https://twitter.com/timdaub) (OP [EIP-4973](https://eips.ethereum.org/EIPS/eip-4973)), [Raphael Roullet](https://mobile.twitter.com/RaphaelRoullet) ([Violet](https://violet.co/)), [Rahul Rumalla](https://twitter.com/rahulrumalla) ([Otterspace](https://www.otterspace.xyz/))

Even since [Vitalik's first post on Soulbound tokens](https://vitalik.ca/general/2022/01/26/soulbound.html), Weyl and Ohlhaver and him then followed up with a paper titled "[Decentralized Society: Finding Web3's Soul](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763)", "Account-bound" (ABTs), "Soulbound" (SBTs), "non-transferrable" (NTTs), ["name-bound" (NBTs)](https://github.com/ethereum/EIPs/pull/5107), "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](https://eips.ethereum.org/EIPS/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.

## Misconception #1: EIP-4973 ABTs do discourage key rotation

{% 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](https://eips.ethereum.org/EIPS/eip-4973) ABT to be permanently bound to an account - even in case of key loss.

Quite the opposite, while [EIP-4973](https://eips.ethereum.org/EIPS/eip-4973) ABTs do indeed not implement [EIP-721](https://eips.ethereum.org/EIPS/eip-721)'s `transfer` and `transferFrom` functions, [EIP-4973](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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.

## Misconception #2: EIP-4973 ABTs cannot be misused

Yes, you're reading this correctly. We're not going to claim anything utopic here. While the scope of an [Ethereum Improvement Proposal](https://eips.ethereum.org/EIPS/eip-1) 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](https://www.ribbonfarm.com/2017/05/25/blockchains-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](https://hal.archives-ouvertes.fr/hal-03513113/document) of blockchains. And similarly, we think that there's acceptance needed towards understanding blockchain as [so culturally diverse and international/global](https://timdaub.github.io/2022/02/28/smart-contracts-are-programmable-commons/) 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.

## Misconception #3: EIP-4973 ABTs are censorship-vulnerable

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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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.

## Misconception #4: EIP-4973 ABTs are an example of a Not-invented-here Syndrome: Let's, please use Verified Credentials (VCs)

[Verified credentials](https://www.w3.org/TR/vc-data-model/) 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](https://eips.ethereum.org/EIPS/eip-4973)'s author Tim Daubenschütz came up with the standard [mainly to implement Harberger property](https://timdaub.github.io/2022/02/19/non-skeuomorphic-harberger-properties-erc721-nfts/).

The problem is that [EIP-721](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/eip-165)'s `supportsInterface` method for feature detection.

So, strictly speaking, although we acknowledge the [EIP-4973](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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.

## Misconception #5: EIP-4973 ABTs is the best standard, and no others should exist

Already within the working groups for [EIP-4973](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/eip-4973) to a new standard called ["name-bound" tokens](https://github.com/ethereum/EIPs/pull/5107) 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](https://github.com/ethereum/EIPs/pull/5114) are now being submitted too.

We hope [EIP-5107](https://github.com/ethereum/EIPs/pull/5107), [EIP-5114](https://github.com/ethereum/EIPs/pull/5114) and [EIP-1238](https://erc1238.notion.site/) 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.