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.