ERC-5484 Consensual Soulbound Token (Consensual Soulbound Tokens)
Final · NFTs & multi-token · created 2022-08-17
The standard interface for soulbound tokens, which are NFTs that cannot be transferred to another address. Before minting, the issuer and the recipient agree on who can burn the token, and that authority cannot be changed after minting.
Why it is needed
Soulbound tokens drew wide attention as NFTs that hold information that must be bound to a specific person, such as credentials, credit records, loan history, and memberships. However, there was no common interface, so implementations were incompatible with one another. Without a minimal agreement on how to implement them, it is hard to build general-purpose services that target soulbound tokens. In addition, existing implementations extended ERC-721 and simply made every transfer function throw an error, so an external service had no way to know that a token was non-transferable until it tried calling one. The right party to destroy a token also differs by use case, so a standard was needed that fixes the burn authority per application in advance and lets soulbound tokens be told apart from ordinary NFTs.
What to implement
function burnAuth(uint256 tokenId) external view returns (BurnAuth): Returns the burn authority for the given token ID. A token ID that has not been minted yet is invalid, so the query fails.
In depth
A structure that extends ERC-721
A contract that implements this standard MUST implement the ERC165 interface (0x01ffc9a7) of ERC-165 and the ERC721 interface (0x80ac58cd) of ERC-721. The ERC-165 interface identifier of this standard itself is 0x0489b56f. Soulbound tokens are designed as a special subset of existing ERC-721 tokens for smooth compatibility with existing NFT services. Service providers can handle soulbound tokens like NFTs and do not need to change their existing codebases significantly.
Three rules of burnAuth
The burn authority (burnAuth) has three rules. First, it SHALL be presented to the recipient before minting. Second, it SHALL NOT be changed after minting. Third, it SHALL be the sole criterion that determines which party has the right to burn the token. The burnAuth(uint256 tokenId) function returns the burn authority for each token ID, and a token ID that has not yet been assigned is invalid, so the query throws. Because the burn authority is bound per token, it can differ from token to token even within the same contract.
The four BurnAuth values and their uses
The enum BurnAuth is a guideline for standardizing the numbering of burn authorities, and it has four values: IssuerOnly (only the issuer can burn), OwnerOnly (only the holder can burn), Both (either party can burn), and Neither (no one can burn). As examples, the original Rationale gives IssuerOnly for a loan record, ReceiverOnly (which corresponds to OwnerOnly in the specification) for a paid membership, Both for a credential, and Neither for a credit record. Because who should be able to erase a record differs by use, the core of the design is a burn rule that is flexible yet fixed before minting.
Consent before minting and fixed metadata
The issuer SHALL present the token metadata to the recipient before minting and obtain the recipient's signature. The metadata SHALL NOT be changed after minting. Since the burn authority does not change after minting, minting happens only when the recipient knows and agrees to both the token content and the burn rule. This procedure is the reason the standard's name includes Consensual.
Signaling an SBT with the Issued event
When a token is minted, an Issued event is emitted together with the ERC-721 Transfer event. The Issued event carries the issuer (from), the recipient (to), the token ID (tokenId), and the burn authority (burnAuth). The design keeps the Transfer event as is to preserve backward compatibility, while giving third parties a clear signal that this is the minting of a soulbound token and not an ordinary NFT.
Blocking transfers but making that knowable in advance
The problem with existing soulbound implementations that extend ERC-721 was that every transfer implementation simply throws an error. From the outside, there is no way to know a token is non-transferable until you actually call it. In this standard the transfer function still throws an error, but the original text explains that it is a cleaner approach to let third parties check, before calling, whether a contract implements the soulbound interface, so that they can avoid the transfer call altogether.
The key replacement problem and reissue after burning
There is a concern that soulbound tokens, whose ownership cannot be changed, make it hard to replace a wallet key. The original text accepts this as a valid concern and explains that key replacement is possible if the soulbound token is burnable. When a holder who needs to change keys notifies the issuer, the party with the burn authority burns the token and the issuer reissues a token with the same content (a replica) to the new address.