ERC-2135 Consumable token interface (Consumable Interface (Tickets, etc))
Final · NFTs & multi-token · created 2019-06-23
A standard interface that makes ERC-721 and ERC-1155 tokens "consumable" assets and announces when consumption occurs. It is used for digital assets whose effect ends once used, such as concert admission tickets.
Why it is needed
A digital asset such as a concert ticket does not end with being held and transferred, because there is a moment when it is actually "used." When the ticket owner enters the venue, the ticket is consumed. However, existing token standards have no common way to express this act of consumption, so each service had to implement it in its own way. That leaves wallets, ticket-checking services and other contracts unable to consistently check which tokens are consumable and whether consumption actually happened. This standard defines a consume function, a function to query whether something is consumable, and an event emitted on consumption as a single interface, so that services, clients, screens and contracts built on this use case work together.
In depth
The consume function and permission design
consume consumes one token each time a call succeeds. This standard deliberately does not define who has permission to perform the consumption or under what conditions consumption is possible. Each implementation decides according to its use case. It does, however, assume that the asset is identified by a uint256 asset id, as in ERC-721. The _consumer parameter exists so that a token can be consumed on behalf of someone other than the account that initiated the transaction. The _data field is a place for additional messages or future extensions (for example, adding cryptographic proofs).
The isConsumableBy view function
isConsumableBy is a view function that does not change state, and it returns a boolean indicating whether the _consumer address can consume the _assetId asset in the quantity _amount. It is meant for ticket-checking services or screens to check whether consumption is possible before actually calling consume.
Event rules: OnConsumption and Transfer
When consumption succeeds, the OnConsumption event must be emitted. This event records consumer and assetId as indexed fields, along with amount and data. In addition, if the conforming contract is an ERC-721 or ERC-1155 token, a Transfer or TransferSingle event must also be emitted when the consume call succeeds, as if the token were transferred from the current holder to the zero address. This rule lets services that subscribe to existing token events recognize consumption as a burn-like transfer.
ERC-165 identifier 0xdd691946
A conforming contract must return true for a call to ERC-165's supportsInterface(0xdd691946). With this single query, a client can tell whether the counterpart contract supports this consumable interface.
Deliberately left out: creation and metadata
This standard deliberately does not include functions or events for creating consumable assets (minting). Creation requires assumptions about the nature of the actual use case, and the standard explains that a follow-up standard can address it once common cases emerge. Metadata is also left out of the standard, and if needed it can be built as a separate metadata extension interface, such as ERC721Metadata in ERC-721.
Compatibility scope
This interface is designed to be compatible with NFTs of ERC-721 and ERC-1155. However, it does not make ERC-721 or ERC-1155 a mandatory requirement, so as not to rule out future use with other token standards or other use cases. It states that, with minor adjustments, the interface can also be used with ERC-20, ERC-777, and the fungible tokens of ERC-1155. For reference, the version 0x1002 reference implementation is deployed on the goerli testnet at address 0x3682bcD67b8A5c0257Ab163a226fBe07BF46379B.
Things to watch out for
- Checking balance changes on consumption: Pay attention to balance changes when a token is consumed. If the contract is paused or the user's transfers are restricted, whether a token can be consumed must behave consistently with those transfer restrictions.
- Defining consume access control: Define access control carefully for your use case, including which externally owned accounts (EOAs) or contract accounts can initiate consume.
- Audits and testing: Verify through security audits and testing that the access control of the consume function works as intended.