status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 2981 (#3123)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
VexyCats 2020-11-21 15:08:45 +08:00 committed by GitHub
parent 0001217002
commit 1027add490
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
EIPS/eip-2981.md
View File

@ -1,7 +1,7 @@
---
eip: 2981
title: ERC-721 Royalty Standard
author: Zach Burks (@vexycats)
author: Zach Burks (@vexycats), James Morgan (@jamesmorgan)
discussions-to: https://github.com/ethereum/EIPs/issues/2907
status: Draft
type: Standards Track
@ -20,10 +20,10 @@ This extension provides even more flexibility to the [ERC-721 specification](./e
## 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.
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 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.
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](./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.
@ -33,8 +33,6 @@ Without a set standard of way to do royalties, we won't have any effective means
This is poor UX and easily fixed with an accepted standard.
## Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
@ -75,7 +73,7 @@ import "./ERC165.sol";
* @dev Implementation of royalties for 721s
*
*/
abstract contract Royalties is ERC165 {
interface IERC2981 is ERC165 {
/*
* ERC165 bytes to add to interface array - set in parent contract implementing this standard
*
@ -84,19 +82,12 @@ abstract contract Royalties is ERC165 {
* _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) {}
function royaltyInfo(uint256 _tokenId) external returns (address receiver, uint256 amount);
}