ERC-5192 Minimal Soulbound NFT (Minimal Soulbound NFTs)

Final · NFTs & multi-token · created 2022-07-01

Adds one locked function and two events to an EIP-721 NFT, so that wallets and apps can check in a standard way whether a token is bound to one account and cannot be transferred.

Why it is needed

A Soulbound Token is an NFT that is bound to one account and cannot be handed to anyone else. The Ethereum community has wanted tokens that cannot be transferred and whose value comes from social meaning, like bound items in World of Warcraft. But there was no standard for this, so many developers implemented it by simply raising an error when a user calls the transfer function. For a wallet or app, there is no way to know in advance which tokens cannot be transferred, and each implementation works differently, so they are hard to use together. If this continues, implementations diverge and composability declines. This standard adds a very small interface to EIP-721 so that a wallet can use EIP-165 feature detection to check whether a token contract is permanently transferable or not.

What to implement

In depth

EIP-721 extension and EIP-165 detection

This standard is an interface that extends EIP-721 and requires EIP-165 and EIP-721 (requires: 165, 721). It does not create a new token specification. It attaches the IERC5192 interface to an existing EIP-721 token. The source explains that this model is the simplest path to a formal interface for soulbound tokens and reflects the many existing implementations that simply revert on transfer. The interface code uses pragma solidity ^0.8.0, and the SPDX-License-Identifier is CC0-1.0.

The locked function and the transfer prohibition rule

function locked(uint256 tokenId) external view returns (bool) returns the bound state of the given tokenId. A token with uint256 tokenId is considered bound to the receiving account when locked returns true. In that case, every EIP-721 function of this contract that moves the token from one account to another must throw. A soulbound token assigned to the zero address is considered invalid, and queries about such a token throw.

Locked and Unlocked events

event Locked(uint256 tokenId) is emitted when the bound state changes to locked, and event Unlocked(uint256 tokenId) is emitted when it changes to unlocked. When a token is minted, the contract should also emit Locked if the state is locked and Unlocked if it is unlocked (the source wording is should). Both events take only tokenId as an argument. The locked function returns the current state and the events announce state changes, so emitting an event at mint time lets the initial state be known from events alone.

Interface ID 0xb45a3c0e

To signal that an EIP-721 token implements soulbinding through this standard, when EIP-721's function supportsInterface(bytes4 interfaceID) external view returns (bool) is called with interfaceID=0xb45a3c0e, a contract that implements this standard must return true. A wallet implementer can check the permanent transferability (or non-transferability) of a token contract with this single call. It uses EIP-165's feature detection method as is.

Backwards compatibility, security, status

This proposal is fully backwards compatible with EIP-721. The source's Security Considerations section states that there are no security considerations directly related to implementing this standard. The status is Final, and it belongs to the ERC category of Standards Track. It was created on July 1, 2022, and copyright and related rights are waived under CC0, so anyone can use it freely.

Original ERC · ← ERCs