DCIPs/EIPS/eip-4400.md

114 lines
6.5 KiB
Markdown

---
eip: 4400
title: EIP-721 Consumable Extension
description: Interface extension for EIP-721 consumer role
author: Daniel Ivanov (@Daniel-K-Ivanov), George Spasov (@Perseverance)
discussions-to: https://ethereum-magicians.org/t/EIP-4400-EIP721consumer-extension/7371
status: Final
type: Standards Track
category: ERC
created: 2021-10-30
requires: 165, 721
---
## Abstract
This specification defines standard functions outlining a `consumer` role for instance(s) of [EIP-721](./eip-721.md). 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](./eip-721.md).
## Motivation
Many [EIP-721](./eip-721.md) 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.
```solidity
/// @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](../assets/eip-4400/test/erc721-consumable.ts).
## Reference Implementation
The reference implementation can be found [here](../assets/eip-4400/contracts/ERC721Consumable.sol).
## 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](../LICENSE.md).