EIP-721 Consumable Extension
Video
Original
Abstract
This specification defines standard functions outlining a consumer
role for instance(s) of EIP-721. An implementation allows reading the current consumer
for a given NFT (tokenId
) along with a standardized event for when an consumer
has changed. The proposal depends on and extends the existing EIP-721.
Motivation
Many EIP-721 contracts introduce their own custom role that grants permissions for utilising/consuming a given NFT instance. The need for that role stems from the fact that other than owning the NFT instance, there are other actions that can be performed on an NFT. For example, various metaverses use operator
/ contributor
roles for Land (EIP-721), so that owners of the land can authorise other addresses to deploy scenes to them (f.e. commissioning a service company to develop a scene).
It is common for NFTs to have utility other than ownership. That being said, it requires a separate standardized consumer role, allowing compatibility with user interfaces and contracts, managing those contracts.
Having a consumer
role will enable protocols to integrate and build on top of dApps that issue EIP-721 tokens. One example is the creation of generic/universal NFT renting marketplaces.
Example of kinds of contracts and applications that can benefit from this standard are:
- metaverses that have land and other types of digital assets in those metaverses (scene deployment on land, renting land / characters / clothes / passes to events etc.)
- NFT-based yield-farming. Adopting the standard enables the "staker" (owner of the NFT) to have access to the utility benefits even after transferring his NFT to the staking contract
Specification
The keywords “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.
Every contract compliant to the EIP721Consumable
extension MUST implement the IEIP721Consumable
interface. The consumer extension is OPTIONAL for EIP-721 contracts.
/// @title EIP-721 Consumer Role extension /// Note: the EIP-165 identifier for this interface is 0x953c8dfa interface IEIP721Consumable /* is EIP721 */ { /// @notice Emitted when `owner` changes the `consumer` of an NFT /// The zero address for consumer indicates that there is no consumer address /// When a Transfer event emits, this also indicates that the consumer address /// for that NFT (if any) is set to none event ConsumerChanged(address indexed owner, address indexed consumer, uint256 indexed tokenId); /// @notice Get the consumer address of an NFT /// @dev The zero address indicates that there is no consumer /// Throws if `_tokenId` is not a valid NFT /// @param _tokenId The NFT to get the consumer address for /// @return The consumer address for this NFT, or the zero address if there is none function consumerOf(uint256 _tokenId) view external returns (address); /// @notice Change or reaffirm the consumer address for an NFT /// @dev The zero address indicates there is no consumer address /// Throws unless `msg.sender` is the current NFT owner, an authorised /// operator of the current owner or approved address /// Throws if `_tokenId` is not valid NFT /// @param _consumer The new consumer of the NFT function changeConsumer(address _consumer, uint256 _tokenId) external; }
Every contract implementing the EIP721Consumable
extension is free to define the permissions of a consumer
(e.g. what are consumers allowed to do within their system) with only one exception - consumers MUST NOT be considered owners, authorised operators or approved addresses as per the EIP-721 specification. Thus, they MUST NOT be able to execute transfers & approvals.
The consumerOf(uint256 _tokenId)
function MAY be implemented as pure
or view
.
The changeConsumer(address _consumer, uint256 _tokenId)
function MAY be implemented as public
or external
.
The ConsumerChanged
event MUST be emitted when a consumer is changed.
On every transfer
, the consumer MUST be changed to a default address. It is RECOMMENDED for implementors to use address(0)
as that default address.
The supportsInterface
method MUST return true
when called with 0x953c8dfa
.
Rationale
Key factors influencing the standard:
- Keeping the number of functions in the interfaces to a minimum to prevent contract bloat
- Simplicity
- Gas Efficiency
- Not reusing or overloading other already existing roles (e.g. owners, operators, approved addresses)
Name
The chosen name resonates with the purpose of its existence. Consumers can be considered entities that utilise the token instances, without necessarily having ownership rights to it.
The other name for the role that was considered was operator
, however it is already defined and used within the EIP-721
standard.
Restriction on the Permissions
There are numerous use-cases where a distinct role for NFTs is required that MUST NOT have owner permissions. A contract that implements the consumer role and grants ownership permissions to the consumer renders this standard pointless.
Backwards Compatibility
This standard is compatible with current EIP-721 standards. There are no other standards that define a similar role for NFTs and the name (consumer
) is not used by other EIP-721 related standards.
Test Cases
Test cases are available in the reference implementation here.
Reference Implementation
The reference implementation can be found here.
Security Considerations
Implementors of the EIP721Consumable
standard must consider thoroughly the permissions they give to consumers
. Even if they implement the standard correctly and do not allow transfer/burning of NFTs, they might still provide permissions to the consumers
that they might not want to provide otherwise and should be restricted to owners
only.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all