EIP-4973 - Account-bound Tokens

@ra-phael @rsquare Chris Chung and I had an account-bound tokens get-together at NFTBerlin to talk about the standard’s future and what other plans we have. Below I’m copying the full notes to the Ethereum Magicians forum. Alternatively you can also read them here on hackmd.

Token Binding Working Group Meeting Berlin

Date of meeting: 2022-05-25
Time: 3pm
Location: Berlin, NFTBerlin event



(pls add yourself)

  • TimDaub
  • Raphael Roullet
  • Chris Chung
  • Rahul Rumalla


(please add agenda items if you have any)

  • (Tim): mini update state of ABTs/SBTs
  • (Tim): Gather feedback about transitioning standard from using “non-transferrable” to “non-separable.”
  • (Tim): Present Otterspace’s effort to make an informed decision about using event Transfer.
  • (Tim): For event Transfer discuss mapping of input parameter values: from, to, id.
  • (Tim): How to move forward with EIP-5107 “Name-bound tokens”: Add initial draft for Name-bound tokens by TimDaub · Pull Request #5107 · ethereum/EIPs · GitHub
  • (Tim): What about Micah’s proposal on “NFT-bound tokens”?





  • Tim Daub
  • Rahul
  • Raph
  • Chris

State of the ABTs/SBTs

Heightened engagement of 4973 on twitter.

Account-bound tokens are starting to emerge as a term.

Name-bound tokens proposal created as a spin-off for ENS-bound token standard to help focus the discussions.

Let’s aim to keep discussions focussed around the specifics of Account-bound tokens on EIP thread of 4973.

Decision making

Decisions that are made on design and implementation must be done through the EIP thread on ethereum magicians forum.

How do we make decisions on certain contentious features in terms of placing something in the spec versus suggestions that users have the choice to implement or not.

Making sure we have discussions that are tracked and traceable so we can be efficient in being productive and be knowledgeable about the rationale and motivations behind any of the decisions being made.


Account-bound might be more specific than soulbound.

Non-separability seems to be less loaded than non-transferability where the baggage of ownership is a contentious point.

Token may not even be the appropriate term for the structure of what we might want to be “soulbound”. Maybe we should be more technically descriptive about the function that we are trying to capture or even revisit the intended macro-goal of bindingness.


Backwards compatibility for the event signatures may help integrateability: i.e.transfer .

Potentially any “breaking changes” to compatibility can be supported by a clear design intent for the new approach which differentiates it from other tokens. Narrowing down and being very specific can help with adoption.

Initially from was removed from the attest and revoke fields. It should be re-introduced to 4973 but the underlying problem needs to be addressed elsewhere.


currently working on a product that has the potential to be huge, and you had me on integrateability because it’s going to be hard to adopt this if it doesn’t have not backward compatibility with specs like ERC-721

1 Like

Alternative naming suggestions:

Identity Bound Tokens (IBTs)
User Bound Tokens (UBTs)
Personal Identity Tokens (PITs)
User Designated Token (UDTs)

The names suggested so far are not great, especially “Soul Bound Token”. If we want blockchain utilities to go mainstream, it would help to start using mainstream language when naming them. Most native English speakers hadn’t even heard the word “fungible” before NFTs became popular, but I digress.

1 Like

In a new post, we’re addressing some of the misconceptions on Twitter and here on the forum about Account-bound tokens:


Proposing a new set of changes to EIP-4973: A disassociation mechanic using function burn. Details: Include disassociation mechanic by TimDaub · Pull Request #5136 · ethereum/EIPs · GitHub

1 Like

I found EIP-4494 and it’s interesting as a mechanism to both store ABTs off-chain and implement consensual minting towards connecting two accounts. More details: EIP-4494: Extending ERC-2612-style permits to ERC-721 NFTs - #32 by TimDaub

That’s not true.

I can envision a possibility – (1) a smart contract is deployed that allows anyone to register themselves as someone who will accept no soul bound tokens. (2) in order to be compliant with the standard, any minting contract must consult that registry first and only create the token if the address is not in the registry.

There are probably a Turing-complete number of other possible solutions.

@MicahZoltu is correct: https://nftevening.com/mcdonalds-nft-collection-has-a-nasty-racial-slur-hidden-in-the-mcrib/

Preventing misuse is in the scope of the Ethereum governance community. Make no mistake, I’m just one dude in my basement writing here. And my goal isn’t to build digital identity either. The use case is very narrow, a common interface for account-bound tokens. If you have concret technical insights, please get in touch and you can cowrite.

Note, our document existed before Vitalik’s paper. I’m not involved in that. Neither are my coauthors. Misuse has to be discussed more globally within crypto/Ethereum and not within ABT spec. Happy to help ofc.

I would consider this to be a best practice/good idea rather than a standard. IMO, standards are for facilitating communication between two parties and providing guarantees/constraints on what is valid over that communication channel. What you are proposing is a “negative standard” in that it isn’t specifying anything about how two things communicate but rather specifying conditions on which two things should not communicate.

FWIW, I can understand the argument for calling such things a standard, but to me that feels like scope creep on the term “standard” that I would prefer to avoid.


This last change to eip-4973 is really well designed,

I think it addessed concerns about the need to add some “authorization” process, while retaining full flexibility of the eip, and providing a clearer path for the implementers of this standard to let users keep control over their tokens.

On the subject of SBTs, I feel that this change addresses the concerns of most of the reactionary critics of vitalik et al. paper. By baking-in revocation into the standard, we let the user the ability to distinguish publicly between wanted and unwanted tokens, therefore enlarging the scope of this eip in a healthy way.

1 Like

Per @TimDaub I’m bringing up caching here. With the current design, applications cannot safely cache anything about individual tokens because it is all mutable. Just because someone owned a given token 5 minutes ago doesn’t mean they still own it now, so you have to re-check. Similarly, just because the metadata about the token said X 5 minutes ago doesn’t mean it still says X, so you have to re-check.

If everything was immutable once set, applications and service providers would be able to aggressively cache everything and not have to worry about the source of truth changing out from under the cache.


I don’t see in which way this specification would prevent applications to use the same tricks used in implementations of eip-721

ownership can be checked with :

mapping (uint256 => address)  //  tokenId => owner

And metadata could either be stored on IPFS, or directly on-chain (not costly on L2).

For the caching specifically, applications will have to checkpoint the current state of the user before interacting with protocol’s functions, but that’s already done with erc20s and NFTs.

Re caching and metadata relevant EIP: EIP-4906: ERC-721 Metadata Update Extension

Yes, ERC-20 tokens and ERC-721 tokens cannot be cached. Bound tokens/badges could be cached if they are sufficiently constrained which makes working with them significantly easier.

1 Like

If e.g. your JSON-RPC cache is based on requests with block number tag “latest”, caching will always be a challenge and it’s generally helpful if requests were instead idempotent (over time). So e.g. if you cache eth_call JSON_RPC requests containing a block number, these results should almost never change (unless a reorg happens I guess).

Caching by block isn’t particularly useful, because ultimately what you are working with is “latest” which is constantly changing. Being able to tell a user, “you owned X as of block Y” isn’t nearly as useful as being able to tell the user “you own X now”. With full immutability, you can cache everything and you can assert to the user what they own without worrying about mutations happening after you fetch the data.

1 Like

I agree that working with immutable data is far easier, and would allow for better tooling on-chain, but adding this constraint would reduce the scope of this eip imo there’s already a lot of different use-cases for mutable metadata, and even more with SBTs.
Besides, I think this is not something to deal with on the interface level but on the implementation level, like making “standard implementations” with on-chain, immutable, metadata.

1 Like

If lifetime policies aren’t part of the specification, then no one can rely on them generally. If someone thinks that data should be mutable, I would argue that should be a separate standard and a given asset could then be either this standard or that standard depending on what lifetime guarantees they make about the data.

@ra-phael @rsquare and I have expanded our “Common Misconceptions about ABTs” blog post with additional sections. We’re planning to expand it even more e.g. addressing Kate Sills’s post in the future. Here’s the latest version: Addressing the most common misconceptions about Account-bound tokens

1 Like

EIP-4973 reference implementation now implements simple burn functionality for disassociation of receiver: EIP-4973: Add `function burn` to reference impl. by TimDaub · Pull Request #5148 · ethereum/EIPs · GitHub