EIP-2981: ERC-721 Royalty standard - Standardized means of accepting royalties for NFT marketplaces across the ecosystem

EIPS/eip-2981.md

@@ -0,0 +1,181 @@
+---
+eip: 2981
+title: ERC-721 Royalty Standard
+author: Zach Burks (@vexycats)
+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 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](./eip-721.md). 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 compatible with 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 worthless if the NFT is sold on another marketplace, defeating the purpose of any royalty system. 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](./eip-721.md). 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
+    );
+```
+
+
+```solidity
+pragma solidity ^0.6.0;
+import "./ERC165.sol";
+
+/**
+ * @dev Implementation of royalties for 721s
+ *
+ */
+abstract contract Royalties 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 the royalty amount that was set and only return that amount
+     *       @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 royaltyAmount(uint256 tokenId) public view returns (uint256) {}
+
+    /**
+     *      @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 view returns (uint256, address) {}
+
+}
+
+
+```
+
+### 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](https://creativecommons.org/publicdomain/zero/1.0/).