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.
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.
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.
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.
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.
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.
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.
@TimDaub I also believe IERC4973Enumerable should be an option as this can have a totalSupply() function that can compliment the balanceOf() in the IERC4973
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.