EIPs/EIPS/eip-2981.md

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

Simple Summary

A standardized way to handle royalty payments for ERC-721 tokens, including publicly viewable information and notification of payment event.

Abstract

This extension provides even more flexibility to the ERC-721 specification. It is possible to set a royalty amount that can be paid to the creator on any marketplace that implements this ERC

Motivation

There are many marketplaces for NFTs and the ones that support royalties are using their own standard version of royalties that are not easily compaitble or usable by other marketplaces. Just as in the early days of Ethereum, smart contracts are varied by ecosystem and not compatible. This would solve that issue such that an NFT created, purchased, or sold on one marketplace, provides the royalties that the creator is entitled too, regardless of the next marketplace/ecosystem it is sold at.

Many of the largest ERC-721 marketplaces have implemented a form of royalties that is not compatible across the board and therefore making it much harder to enforce if the NFT is sold on another marketplace, not fulfulling the potential of any royalty system put in place. This standard is a proposed way to minimally implement royalties that can be accepted across any type of NFT marketplace smart contracts. This standard allows for a royalty standard to be accepted on all marketplaces - leaving the funds transfer up to the marketplace itself, and only providing a means to fetch the royalty amounts and a event to be fired off when transfer has happened.

This extension provides even more flexibility to the ERC-721 specification. It is possible to set a royalty amount that can be paid to the creator on any marketplace that implements this ERC. If a marketplace chooses not to implement this ERC then of course no funds are paid for secondary sales. But seeing as how most NFT marketplace have developed some sort of royalty system themselves - and all of them are singular and only work on their own contracts - there needs to be an accepted standard way of providing royalties - if the creator so chooses to set royalties on their NFTs.

Without a set standard of way to do royalties, we won't have any effective means to provide royalties across the board, this obviously hampers the growth and adoption of NFTs, as the flexibility of the token and the UX is poor.

"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 is poor UX and easily fixed with an accepted standard.

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 accepting royalty payments and receiving royalty information

The _RoyaltyAmount MUST be calculated as a percentage fixed point with a scaling factor of 10000 (X/10000) - such as "50000" - for 5%. This is REQUIRED to maintain uniformity across the standard. The max and min values would be - 100% (1,000,000) and 0.00001% (1).

Marketplaces that support this standard MAY implement any method of calculating or transferring royalties to the royalty recipient.

Marketplaces that support this standard MUST emit the event, royaltiesReceived, after sending a payment.

/**
    @notice This event is emitted when royalties are transferred.
    @dev The marketplace would emit this event from their contracts. 
    @param royaltyRecipient - The address of who is entitled to the royalties
    @param buyer - The person buying the NFT on a secondary sale
    @param tokenId - the token buying purchased/traded
    @param amount - The amount being paid to the creator
*/
    event ReceivedRoyalties(
        address indexed royaltyRecipient,
        address indexed buyer,
        uint256 indexed tokenId,
        uint256 indexed amount
    );

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()')) == 0x46e80720
     * bytes4 private constant _INTERFACE_ID_ERC721ROYALTIES = 0x46e80720;
     * _registerInterface(_INTERFACE_ID_ERC721ROYALTIES);
     */
    /**
    
    /**
     *      @notice Called to return both the creator's address and the royalty percentage - this would be the main function called by marketplaces unless they specifically        *       need just the royaltyAmount
     *       @notice Percentage is calculated as a fixed point with a scaling factor of 10,000, such that 100% would be the value (1000000) where, 1000000/10000 = 100. 1%          *        would be the value 10000/10000 = 1
     */
    function royaltyInfo(uint256 _tokenId) external returns (address receiver, uint256 amount); 
}
  
  

Event ReceivedRoyalties to be used by marketplaces when transferring royalty payments

  /**
    @notice This event is emitted when royalties are transferred.
    @dev The marketplace would emit this event from their contracts. 
    @param royaltyRecipient - The address of who is entitled to the royalties
    @param buyer - The person buying the NFT on a secondary sale
    @param tokenId - the token buying purchased/traded
    @param amount - The amount being paid to the creator
*/
    event ReceivedRoyalties(
        address indexed royaltyRecipient,
        address indexed buyer,
        uint256 indexed tokenId,
        uint256 indexed amount
    );

Examples

The Royalty ERC being used on a ERC-721 during deployment:

Deploying an ERC-721 and setting the royalty amount and creator

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 purchased/sold on your marketplace implemented royalties (note using address.call() is completely OPTIONAL and is just one method)

function checkRoyalties(address _token) internal  returns(bool){
   (bool success,) = address(_token).call(abi.encodeWithSignature("royaltyInfo()"));
    return success;
    }

Transferring funds and calling the event to be emitted

   _recipient.transfer(amount);
   IERC2981(_tokenAddress).royaltiesReceived(_recipient, _buyer, amount);

Rationale

Fixed percentage to 10^5 (10000)

Having the flexibility to set any percentage a creator likes is important - although the reality of having users want a 0.00000000001% fee is not very likely. Instead the value can be limited to 5 decimal places with the lowest percentage being 0.00001% and the cap at 100%.

Emitting event for payment

Choosing to emit an event for payment is important as each NFT contract is standalone, and while a marketplace contract can emit events that an item is sold, the royalty recipient might not be aware/watching the marketplace for a secondary sale of their NFT and therefore would never know they got a payment except for having an increased amount of ETH in their wallet randomly. So calling a function on the parent contract of the NFT being sold is an easy way for the recipient to check on the payments received by their secondary sales.

Backwards Compatibility

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.