Hi community members, I’d like to call for a early stage vetting of the idea of having a standard for consumable. Thank you!
eip: 2135
title: Consumable NFT for Ticketing
description: An interface extending EIP-721 and EIP-1155 for consumability, supporting use case such as an event ticket.
author: Zainan Victor Zhou (@xinbenlv)
discussions-to: ERC-2135: Consumable Interface, e.g. NFT Event Tickets
status: Review
type: Standards Track
category: ERC
created: 2019-06-23
requires: 165, 721, 1155
Abstract
The interface identifies functions and events needed for creating a contract to be able to mark a digital asset as “consumable”, and react to the request of “consumption”.
Motivation
Being a digital assets sometimes means a consumable power. One most common seen examples would be a concert ticket.
It will be “consumed” at the moment the ticket-holder uses the ticket to get access to enter a concert.
By having a standard ERC interface, the Ethereum ecosystem can interoperate to provide services, clients, UI, and inter-contract functionalities on top of this very general use-case.
Specification
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.
- Any compliant contract MUST implement the following interface
pragma solidity >=0.7.0 <0.9.0;
/// The EIP-165 identifier of this interface is 0x0c44c20d
interface IEIP2135 {
/// @notice The consume function consumes a token every time it succeeds.
/// @param _consumer the address of consumer of this token. It doesn't have
/// to be the EOA or contract Account that initiates the TX.
/// @param _assetId the NFT asset being consumed
/// @param _data extra data passed in for consume for extra message
/// or future extension.
function consume(address _consumer, uint256 _assetId, bytes[] calldata _data) external returns(bool _success);
/// @notice The interface to check whether an asset is consumable.
/// @param _consumer the address of consumer of this token. It doesn't have
/// to be the EOA or contract Account that initiates the TX.
/// @param _assetId the NFT asset being consumed
function isConsumableBy(address _consumer, uint256 _assetId) external view returns (bool _consumable);
/// @notice The event emitted when there is a successful consumption.
/// @param _consumer the address of consumer of this token. It doesn't have
/// to be the EOA or contract Account that initiates the TX.
/// @param _assetId the NFT asset being consumed
/// @param _data extra data passed in for consume for extra message
/// or future extension.
event OnConsumption(address indexed _consumer, uint256 indexed _assetId, bytes[] _data);
}
-
If the compliant contract is an EIP-721 or EIP-1155, in addition to
OnConsumption, it MUST also emit relatedTransfer/TransferSingleevent as if a token has been transfer from the current holder to0x00address if the call toconsumemethod succeeds. -
The compliant contract MUST respond
truefor
EIP-165 identifierinterfaceID=0x0c44c20dwhen queried
supportsInterface(bytes4 interfaceID)
Rationale
- The function
consumeperforms the consume action. Being an interface standard,
this EIP does not impose any assumption of
- who has the power to perform such activity.
- under what condition such consumption can occur.
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 EIP-721
-
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 creation of a consumable asset. This is because the creation of a consumable asset will need to make assumption of the nature of an actual use-case. If we see some common use-case of creation, we can have another follow up standard.
-
We also left out metadata associated to the consumables from the standard. If necessary, related metadata can be created with a separate metadata extension interface like
ERC721Metadatafrom EIP-721 -
We choose to include an
address consumerforconsumefunction andisConsumableByso that an NFT MAY be consumed for someone other than the transaction initiator. -
We choose to include an extra
_datafield for future extension, such as
adding crypto endorsements. -
We explicitly stay opinion-less about whether EIP-721 or EIP-1155 shall be required because
while we design this EIP with EIP-721 and EIP-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
isConsumableBycan be used to check whether an asset is
consumable by the_consumer.
Backwards Compatibility
This interface is designed to be compatible with EIP-721 and NFT of EIP-1155. It can be tweak to used for EIP-20, EIP-777 and Fungible Token of EIP-1155.
Security Considerations
The compliant contract 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.
The compliant contract should also carefully define access control, particularlly whether any EOA or contract account may or may not initiate a consume method in their own use case.
Security audit and tests should be imposed to verify the access control to the consume
shall behave as expected.
Copyright
Copyright and related rights waived via CC0.