This EIP defines an interface to mark a digital asset as "consumable" and to react to its "consumption."
Digital assets sometimes need to be consumed. One of the most common examples is a concert ticket. It is "consumed" when the ticket-holder enters the concert hall.
Having a standard interface enables interoperability for services, clients, UI, and inter-contract functionalities on top of this use-case.
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.
If the compliant contract is an ERC-721 or ERC-1155 token, in addition to OnConsumption, it MUST also emit the Transfer / TransferSingle event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to consume method succeeds.
supportsInterface(0xdd691946) MUST return true for any compliant contract, as per ERC-165.
consume performs the consume action. This EIP does not assume:It does, however, assume the asset can be identified in a uint256 asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 pattern.
The event notifies subscribers whoever are interested to learn an asset is being consumed.
To keep it simple, this standard intentionally contains no functions or events related to the creation of a consumable asset. This is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. If there are common use-cases for creation, another follow up standard can be created.
Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like ERC721Metadata from ERC-721
We choose to include an address consumer for consume function and isConsumableBy so that an NFT MAY be consumed for someone other than the transaction initiator.
We choose to include an extra _data field for future extension, such as
adding crypto endorsements.
We explicitly stay opinion-less about whether ERC-721 or ERC-1155 shall be required because while we design this EIP with ERC-721 and ERC-1155 in mind mostly, we don't want to rule out the potential future case someone use a different token standard or use it in different use cases.
The boolean view function of isConsumableBy can be used to check whether an asset is
consumable by the _consumer.
This interface is designed to be compatible with ERC-721 and NFT of ERC-1155. It can be tweaked to used for ERC-20, ERC-777 and Fungible Token of ERC-1155.
A deployment of version 0x1002 has been deployed onto goerli testnet at address 0x3682bcD67b8A5c0257Ab163a226fBe07BF46379B.
Find the reference contract verified source code on Etherscan's
goerli site for the address above.
Compliant contracts should pay attention to the balance change when a token is consumed. When the contract is being paused, or the user is being restricted from transferring a token, the consumeability should be consistent with the transferral restriction.
Compliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not initiate a consume method in their own use case.
Security audits and tests should be used to verify that the access control to the consume
function behaves as expected.
Copyright and related rights waived via CC0.