Proposes a standard API for account-bound Tokens (ABT) within smart contracts. An ABT is a non-fungible token bound to a single account. ABTs don't implement a canonical interface for transfers. This EIP defines basic functionality to mint, assign, revoke and track ABTs.
In the popular MMORPG World of Warcraft, its game designers intentionally took some items out of the world's auction house market system to prevent them from having a publicly-discovered price and limit their accessibility.
Vanilla WoW's "Thunderfury, Blessed Blade of the Windseeker" was one such legendary item, and it required a forty-person raid, among other sub-tasks, to slay the firelord "Ragnaros" to gain the "Essence of the Firelord," a material needed to craft the sword once.
Upon voluntary pickup, the sword permanently binds to a character's "soul," making it impossible to trade, sell or even swap it between a player's characters.
In other words, "Thunderfury"'s price was the aggregate of all social costs related to completing the difficult quest line with friends and guild members. Other players spotting Thunderfuries could be sure their owner had slain "Ragnaros," the blistering firelord.
World of Warcraft players could trash legendary and soulbound items like the Thunderfury to permanently remove them from their account. It was their choice to visibly equip or unequip an item and hence show their achievements to everyone.
The Ethereum community has expressed a need for non-transferrable, non-fungible, and socially-priced tokens similar to WoW's soulbound items. Popular contracts implicitly implement account-bound interaction rights today. A principled standardization helps interoperability and improves on-chain data indexing.
The purpose of this document is to make ABTs a reality on Ethereum by creating consensus around a maximally backward-compatible but otherwise minimal interface definition.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
ABTs must implement the interfaces:
ABTs must not implement the interfaces:
ERC721 (0x80ac58cd)An ABT receiver must be able to always call function unequip(address _tokenId) to take their ABT off-chain.
See ERC-721 for a definition of its metadata JSON Schema.
To invoke function give(...) and function take(...) a bytearray signature must be created using EIP-712. A tested reference implementation in Node.js is attached at index.mjs, index_test.mjs and package.json. In Solidity, this bytearray signature can be created as follows:
ABTs shall be maximally backward-compatible but still only expose a minimal and simple to implement interface definition.
As ERC-721 tokens have seen widespread adoption with wallet providers and marketplaces, using its ERC721Metadata interface with ERC-165 for feature-detection potentially allows implementers to support ABTs out of the box.
If an implementer of ERC-721 properly built ERC-165's function supportsInterface(bytes4 interfaceID) function, already by recognizing that ERC-721's track and transfer interface component with the identifier 0x80ac58cd is not implemented, transferring of a token should not be suggested as a user interface option.
Still, since ABTs support ERC-721's ERC721Metadata extension, wallets and marketplaces should display an account-bound token with no changes needed.
Although other implementations of account-bound tokens are possible, e.g., by having all transfer functions revert, ABTs are superior as it supports feature detection through ERC-165.
We expose function unequip(address _tokenId) and require it to be callable at any time by an ABT's owner as it ensures an owner's right to publicly disassociate themselves from what has been issued towards their account.
Given the non-transferable between accounts property of ABTs, if a user's keys to an account or a contract get compromised or rotated, a user may lose the ability to associate themselves with the token. In some cases, this can be the desired effect. Therefore, ABT implementers should build re-issuance and revocation processes to enable recourse. We recommend implementing strictly decentralized, permissionless, and censorship-resistant re-issuance processes.
But this document is deliberately abstaining from offering a standardized form of exception handling in cases where user keys are compromised or rotated.
In cases where implementers want to make account-bound tokens shareable among different accounts, e.g., to avoid losing access when keys get compromised, we suggest issuing the account-bound token towards a contract's account that implements a multi-signature functionality.
ABTs can be indexed by tracking the emission of event Transfer(address indexed from, address indexed to, uint256 indexed tokenId). As with ERC-721, transfers between two accounts are represented by address from and address to being non-zero addresses. Unequipping a token is represented through emitting a transfer with address to being set to the zero address. Mint operations where address from is set to zero don't exist. To avoid being spoofed by maliciously-implemented event Transfer emitting contracts, an indexer should ensure that the transaction's sender is equal to event Transfer's from value.
We have adopted the ERC-165 and ERC721Metadata functions purposefully to create a high degree of backward compatibility with ERC-721. We have deliberately used ERC-721 terminology such as function ownerOf(...), function balanceOf(...) to minimize the effort of familiarization for ABT implementers already familiar with, e.g., ERC-20 or ERC-721. For indexers, we've re-used the widely-implemented event Transfer event signature.
You can find an implementation of this standard in ERC-4973-flat.sol.
There are no security considerations related directly to the implementation of this standard.
Copyright and related rights waived via CC0.