EIP-4973 - Account-bound Tokens

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

I think it would be good to have hooks _beforeTokenTransfer and _afterTokenTransfer (on _mint and _burn) for extensibility (to allow extension like ERC4973Enumerable to be built in the future), like on ERC721.

1 Like

I believe it be useful to have a balanceOf function in the IERC4973

A general use case would be the community attests ABT tokens to a particular account. The more tokens attested, the more that account is trusted by the community.


agreed that balanceOf is useful. I saw that e.g. snapshot.org’s simplest EIP-721 token voting strategy uses it and so EIP-4973 should have it too!

@TimDaub I also believe IERC4973Enumerable should be an option as this can have a totalSupply() function that can compliment the balanceOf() in the IERC4973

1 Like

Actually it might be better to mention I721Enumerable as an option in the proposal, because it already has a totalSupply() function and its other functions can be useful too.

Given the recent misinterpretation related to Soulbound tokens and Account bound tokens EIP-4973, we’re now segmenting the Telegram groups into those that want to create a new property class (e.g. a “soulbound sword” as in WoW: That’s Account-bound tokens.) And everything else, e.g. credentials etc: “Soulbound tokens”

  • We’ve updated the “Motivation” section to clearly describe the document’s goal: Specifying a similar mechanic as World of Warcraft’s “soulbound items” like Ragnaros’ Thundefury: EIP-4973: Account-bound Tokens

Just for the record, I disagree that a “Soulbound Sword” makes sense as address bound. The sword is bound to a character usually, sometimes to an account, but the account can undergo credential changes, unlike an Ethereum address.

balanceOf is now part of the interface and reference implementation: Add `function balanceOf(...)` by TimDaub · Pull Request #5172 · ethereum/EIPs · GitHub

1 Like

We’re making progress with implementing mintWithPermission and are getting ready to write up the change to the spec too. Here’s the latest implementation: ERC4973/ERC4973Permit.sol at 5e7d50ec62d9592f425c4cccd2fc3c3b8aca48c1 · rugpullindex/ERC4973 · GitHub

  • signature(hash(from, to, uri), from.pk) allows to to keep the token off-chain and take the token on-chain with from's permission
  • In a 2^256 big bitmap, we’re making sure that any combination of hash(from, to, uri) will only be minted once
  • EIP-1271 support is included so contracts can allow minting as from too
  • tokenIds are incremented internally so that we don’t have race conditions of two or more users redeeming at the same time
  • signatures are now EIP-2098 compact representation compatible

feedback is welcome

1 Like