--- eip: 2981 title: ERC-721 Royalty Standard author: Zach Burks (@vexycats), James Morgan (@jamesmorgan), Blaine Malone (@blmalone), James Seibel (@seibelj) discussions-to: https://github.com/ethereum/EIPs/issues/2907 status: Draft type: Standards Track category: ERC created: 2020-09-15 requires: 165 --- ## Simple Summary A standardized way to retrieve royalty payment information for ERC-721 tokens to enable universal support for royalty payments in all NFT marketplaces and ecosystem participants. ## Abstract This standard extends the [ERC-721 specification](./eip-721.md) 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 required by the EIP-721 standard, 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, ERC-721 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 ERC-721 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 specification](./eip-721.md) 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. ## 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 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: ```solidity pragma solidity ^0.6.0; import "./ERC165.sol"; /// /// @dev Implementation of royalties for 721s /// interface IERC2981 is ERC165 { /// ERC165 bytes to add to interface array - set in parent contract /// implementing this standard /// /// bytes4(keccak256("royaltyInfo(uint256,uint256,bytes)")) == 0x6057361d /// bytes4 private constant _INTERFACE_ID_ERC721ROYALTIES = 0x6057361d; /// _registerInterface(_INTERFACE_ID_ERC721ROYALTIES); /// @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 ERC721 supports ERC2981 /// @dev If `_registerInterface(_INTERFACE_ID_ERC721ROYALTIES)` 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_ERC721ROYALTIES` 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 ```solidity constructor (string memory name, string memory symbol, string memory baseURI) public Royalties(royalty_amount, msg.sender) { _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_ERC721ROYALTIES); } ``` #### Checking if the NFT being sold on your marketplace implemented royalties Note: using address.call() is completely **OPTIONAL** and is just one method. ```solidity function checkRoyalties(address _token) internal returns (bool) { (bool success) = address(_token).call(abi.encodeWithSignature("royaltyInfo(uint256,uint256,bytes)")); 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 completely compatible with current ERC-721 standards - in fact it requires it. ## Security Considerations There are no security considerations related directly to the implementation of this standard. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).