EIPs/EIPS/eip-2981.md

eip	title	author	discussions-to	status	type	category	created	requires
2981	NFT Royalty Standard	Zach Burks (@vexycats), James Morgan (@jamesmorgan), Blaine Malone (@blmalone), James Seibel (@seibelj)	https://github.com/ethereum/EIPs/issues/2907	Draft	Standards Track	ERC	2020-09-15	165

Simple Summary

A standardized way to retrieve royalty payment information for NFT tokens to enable universal support for royalty payments in all NFT marketplaces and ecosystem participants.

Abstract

This standard extends NFT standards such as the ERC-721 and [ERC-1155]](./eip-1155.md) specifications to enable setting a royalty amount paid to the NFT creator or rights holder every time an NFT is sold and re-sold. This is intended for NFT marketplaces that want to support the ongoing funding of artists and other NFT creators. The royalty payment must be voluntary, as transferFrom() includes NFT transfers between wallets, and executing transferFrom() does not always imply a sale occurred. Marketplaces and individuals implement this standard by retrieving the royalty payment information with royaltyInfo(), which specifies how much to pay to which address for a given sale price. The exact mechanism for paying and notifying the recipient will be defined in future EIPs. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments.

Motivation

There are many marketplaces for NFTs with multiple unique royalty payment implementations that are not easily compatible or usable by other marketplaces. Just like the early days of ERC-20 tokens, NFT marketplace smart contracts are varied by ecosystem and not standardized. This EIP enables all marketplaces to retrieve royalty payment information that NFT creators specify and are entitled to, enabling accurate royalty payments regardless of which marketplace the NFT is sold or re-sold at.

Many of the largest NFT marketplaces have implemented royalty payments that are incompatible with other platforms and therefore make it much harder to enforce when the NFT is sold on another marketplace, not fulfilling the potential of any implemented royalty system. This standard implements standardized royalty information retrieval that can be accepted across any type of NFT marketplace. This minimalist proposal leaves the actual funds transfer up to the marketplace itself, and only provides a mechanism to fetch the royalty amounts. Future EIPs may build on this ERC to implement payment notifications and other features.

This standard extends the [ERC-721 and [ERC-1155]](./eip-1155.md) specifications to enable setting a royalty amount paid to the NFT creator or rights holder every time an NFT is sold and re-sold. If a marketplace chooses not to implement this EIP, then obviously no funds are paid for secondary sales. But as most NFT marketplaces have developed some unique royalty system themselves - and all of them are singular and only work within their own contracts - there should be an accepted standard for royalty payment information (if the creator chooses to set royalties on their NFTs). We believe the NFT marketplace ecosystem will voluntarily implement royalty payments to provide ongoing funding for artists and other creators, and NFT buyers will assess the royalty payment as a factor when making NFT purchasing decisions.

Without an agreed royalty payment standard, the NFT ecosystem will lack an effective means to collect royalties across all marketplaces and artists and other creators will not receive ongoing funding. This will hamper the growth and adoption of NFTs and demotivate artists and other NFT creators from minting new and innovative tokens.

"Yes we have royalties, but if your NFT is sold on another marketplace, we cannot provide royalties" ... "But can't I sell my NFT anywhere with a click of my wallet?" ... "Yes... but we don't have a standard for royalties so you'll lose out."

This EIP fixes this issue, enabling all NFT marketplaces to unify on a single royalty payment information standard and benefiting the entire NFT ecosystem.

While this standard is focused on NFTs and compatibility with the ERC-721 and ERC-1155 standards, EIP-2981 does not require compatibility with ERC-721 and ERC-1155 standards. Any other contract could integrate with EIP-2981 to return royalty payment information. ERC-2981 is therefore a universal royalty standard for many asset types.

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.

ERC-721 and ERC-1155 compliant contracts MAY implement this ERC for royalties to provide a standard method of specifying royalty payment information.

Marketplaces that support this standard SHOULD implement some method of transferring royalties to the royalty recipient. Standards for the actual transfer and notification of funds will be specified in future EIPs.

Implementers of this standard MUST NOT use the _data parameter and _royaltyPaymentData return value. These are intended for future EIPs that extend this ERC with additional features.

Implementers of this standard MUST have all of the following functions:

pragma solidity ^0.6.0;
import "./ERC165.sol";

///
/// @dev Interface for the NFT Royalty Standard
///
interface IERC2981 is ERC165 {
    /// ERC165 bytes to add to interface array - set in parent contract
    /// implementing this standard
    ///
    /// bytes4(keccak256("royaltyInfo(uint256,uint256,bytes)")) == 0xc155531d
    /// bytes4 private constant _INTERFACE_ID_ERC2981 = 0xc155531d;
    /// _registerInterface(_INTERFACE_ID_ERC2981);

    /// @notice Called with the sale price to determine how much royalty
    //          is owed and to whom.
    /// @param _tokenId - the NFT asset queried for royalty information
    /// @param _value - the sale price of the NFT asset specified by _tokenId
    /// @param _data - information used by extensions of this ERC.
    ///                Must not to be used by implementers of EIP-2981 
    ///                alone.
    /// @return _receiver - address of who should be sent the royalty payment
    /// @return _royaltyAmount - the royalty payment amount for _value sale price
    /// @return _royaltyPaymentData - information used by extensions of this ERC.
    ///                               Must not to be used by implementers of
    ///                               EIP-2981 alone.
    function royaltyInfo(uint256 _tokenId, uint256 _value, bytes calldata _data) external returns (address _receiver, uint256 _royaltyAmount, bytes memory _royaltyPaymentData);

    /// @notice Informs callers that this contract supports ERC2981
    /// @dev If `_registerInterface(_INTERFACE_ID_ERC2981)` is called
    ///      in the initializer, this should be automatic
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @return `true` if the contract implements
    ///         `_INTERFACE_ID_ERC2981` and `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

Examples

This standard being used on an ERC-721 during deployment:

Deploying an ERC-721 and signaling support for ERC-2981

constructor (string memory name, string memory symbol, string memory baseURI) {
        _name = name;
        _symbol = symbol;
        _setBaseURI(baseURI);
        // register the supported interfaces to conform to ERC721 via ERC165
        _registerInterface(_INTERFACE_ID_ERC721);
        _registerInterface(_INTERFACE_ID_ERC721_METADATA);
        _registerInterface(_INTERFACE_ID_ERC721_ENUMERABLE);
        // Royalties interface 
        _registerInterface(_INTERFACE_ID_ERC2981);
    }

Checking if the NFT being sold on your marketplace implemented royalties

Note: using address.call() is completely OPTIONAL and is just one method.

bytes4 private constant _INTERFACE_ID_ERC2981 = 0xc155531d;

function checkRoyalties(address _contract) internal returns (bool) {
    (bool success) = IERC2981(_contract).supportsInterface(_INTERFACE_ID_ERC2981);
    return success;
 }

Rationale

Optional royalty payments

It is impossible to know which NFT transfers are the result of sales, and which are merely wallets moving or consolidating their NFTs. Therefore, we cannot force every transferFrom() call to involve a royalty payment, as not every transfer is a sale that would require such payment. We believe the NFT marketplace ecosystem will voluntarily implement this royalty payment standard to provide ongoing funding for artists and other creators, and NFT buyers will assess the royalty payment as a factor when making NFT purchasing decisions.

Simple royalty payments to a single address

This EIP does not specify the manner of payment to the royalty recipient. Furthermore, it is impossible to fully know and efficiently implement all possible types of royalty payments logic, so it is on the royalty payment receiver to implement all additional complexity and logic for fee splitting, multiple receivers, taxes, accounting, etc. in their own receiving contract or off-chain. If we attempted to do this as part of this standard, it would dramatically increase the implementation complexity, increase gas costs, and could not possibly cover every potential use-case. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments. Future EIPs can specify more details regarding payment transfer and notification.

Royalty payment amounts over percentages

This EIP does not specify how the _royaltyAmount is calculated from the sale price _value. Many NFT contracts may follow a fixed-percentage royalty that is the same regardless of price. However, EIP-2981 implementers may choose whatever logic they want to calculate the _royaltyAmount - this EIP does not mandate a fixed-percentage fee model.

Additionally, we return a specific _royaltyAmount so there is no dispute with a marketplace over how much is owed for a given sale price.

Unused data parameters in function signature

This EIP mandates the inclusion of the _data parameter and the _royaltyPaymentData return value, and also mandates that these are unused. The purpose of this is to have a seamless path to build on this ERC by further EIP standards that specify payment notifications, fee splitting, and other advanced use cases.

Backwards Compatibility

This standard is compatible with current ERC-721 and ERC-1155 standards.

Universal Royalty Payments

Although designed specifically with NFTs in mind, this standard does not require that a contract implementing EIP-2981 is compatible with either ERC-721 or ERC-1155 standards. Any other contract could integrate with this, provided it uniquely identifies assets by ID (like tokenId) to return royalty payment information. ERC-2981 is therefore a universal royalty standard for many other asset types.

Security Considerations

There are no security considerations related directly to the implementation of this standard.

Copyright

Copyright and related rights waived via CC0.