-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC-2571: Creators’ Royalty Token standard #2571
Comments
Hey there, |
Hi @insiderq,
|
Hello. I really like where you guys are coming from, you are absolutely right when it come to the fact that promising second-hand remuneration to creators is what could make them switch from old world licensed creation to NFT backed creation. However, I feel like most of your functionalities listed could be left at the token publisher discretion instead of being part of the Standard. A Standard goal is to promote inter-operability by describing interaction channels and shared predicate/postulate contracts for each of those channels, not to describe what must happen "inside the box" of each implementation.
Do you feel that following the following standard would prevent you guys from implementing any of your desired features ? All of those can be implemented under the hood of the proposed function getPublisherFeeRate() public view returns (uint256);
function getCreator(uint256 tokenId) public view returns (address payable);
function getCreatorFeeRate(uint256 tokenId) public view returns (uint256);
function getTradeExpires(bytes32 tradeHash) public view returns (uint256);
function getTradePrices(bytes32 tradeHash) public view returns (uint256);
function setPublisherFeeRate(uint256 feeRate) external;
function setCreator(uint256 tokenId, address payable creator) public;
function setCreatorFeeRate(uint256 tokenId, uint256 feeRate) external;` And the rest be implemented under the throw conditions and payable mutability of the Transfer/Approve functions, which are already part of the ERC-721 standard. event ReadyForSale(
address buyer,
uint256 tokenId,
uint256 price,
uint256 expireBlockNumber);
function readyForSale(address buyer, uint256 tokenId, uint256 price, uint256 expireBlockNumber) external;
function cancelTradeOrder(address buyer, uint256 tokenId) external;
function tradeAndDistributeFees(address payable seller, uint256 tokenId) external payable; |
@Nokhal
This standard is to distribute fees as a percentage of the NFT sale, not as a fixed fee under this 2571 standard. It's pretty hard to know this in existing DEXs because we have to use price oracle or get them to support this to get sales price. That's why, we designed 2571 to be tightly coupled with DEX functions, unlike 2665. |
First of all. Great job! Are you guys still working on this? Are there any competing standards besides 2665? |
Within this standard, can an argument be used to define a minimum fee in order to prevent a sale for a minimal amount which would circumvent a fee, while still allowing for percentage where the percentage would be more than the minimum? |
Looove this standard. Is there any reason I can't just implement for my DAPP it and hope for the best? |
You are free to go, it's CC0 licensed, « You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. » |
Is this post still active? |
It seems Rarible and OpenSea implemented their own Royalty fees and activity on this EIP vanished |
Hi, anyone has code sample implementation of ERC2571 with ERC721 ? Thanks, |
We are currently implementing a sample project. |
Looks like the Royalty standard for 721s and 1155s will be EIP-2981. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2981.md |
It will indeed be difficult for 2571 to gain adoption compared to 2981 unless 2571 is drastically simplified imo. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Simple Summary
A standard interface for non-fungible tokens that enables artwork creators to receive a fee not only when their works are sold for the first time, but also their works are resold.
Abstract
This standard outlines a smart contract interface based on ERC-721, which is a standard for non-fungible tokens. The key issue of using it is that an original author who creates an item cannot receive any fees after giving or selling it to another. Creators' Royalty Token enables creators to get a fee whenever the token is transferred, which has a function of the decentralized exchange. Hence, a partial amount of the transaction value will always be paid to the creator.
Motivation
It is predicted that a lot of creators who design a piece of artwork would associate their items with non-fungible tokens based on ERC-721. The expected issue in this case is that the artwork would be resold on the secondary market, such as OpenSea, even though the artist cannot get any fees. This problem often happens even in the real world, and that makes creators disappointed.
The new functionality is possible with the design of receiving a fee for the sale whenever non-fungible tokens are transferred. You do not need to embed any code but use this interface instead of ERC-721 so that artwork creators can receive a fee. Currently, we are developing a product called Conata and will implement the token based on this 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.
Smart contracts implementing the ERC-2571 standard MUST implement all of the functions in the ERC-2571 interface.
Smart contracts implementing the ERC-2571 standard MUST implement the ERC-721.
The token contract MUST implement the above contract. The implementation MUST follow the specifications described below.
Creators' Royalty Token Overview
Creators' Royalty Token
Buyer
Everyone can buy non-fungible tokens via Creators' Royalty Token contract. The buyer pays ETH as the token price. Paid ETH is distributed to Publisher and Creator as a trade fee.
Seller
The owner of a non-fungible token can sell it via Creators' Royalty Token contract. The seller sends the non-fungible token to a buyer.
Creator
Creators produce artworks such as characters, music and digital arts. Their artworks are published as non-fungible tokens.
Publisher
Publishers mint a Creators’ token instead of the creator. The role of them is to advertise artworks and enhance their brand images. The Creators' address should be set if there is no publisher. In this case, creators manage their token themselves.
View Functions
The view functions detailed below MUST be implemented.
getPublisherFeeRate function
function getPublisherFeeRate() public view returns (uint256)
Get the fee rate used on a publisher.
returns: Fee rate of the publisher
getCreator function
function getCreator(uint256 tokenId) public view returns (address payable)
Get the creators' address.
params: tokenId: tokenID used on ERC721
returns: Address of the creator
getCreatorFeeRate function
function getCreatorFeeRate(uint32 tokenId) public view returns (uint256)
Get the fee rate according to the tokenId.
params: tokenIdassetType: tokenID used on ERC721
returns: Fee rate of the asset type
NOTE: If the contract has a large number of tokenIDs, you can optionally set the classification as an asset type by token digits and link the classification to the creator instead of using the tokenID. In that case, the contract has to have a state valuable that plays a role as a filter.
NOTE: If the contract has a large number of tokenIDs, you can optionally set the classification as an asset type by token digits and link the classification to the creator instead of using the tokenID. In that case, the contract has to have a state valuable that plays a role as a filter.
(implementation)
NOTE: This function emits the event named ReadyForSale.
Trade and Distribution Fees
function tradeAndDistributeFees(address payable seller, uint256 tokenId) external payable
Call this function to transfer the ownership of the artwork and distribute fees to the author. In this function, the two functions are invoked; _signAndPayTransfer and _changeTransfer.
_changeTransfer
is a private function that returns ETH to the sender, which is the remaining number of the transaction. The code below is the implementation example.NOTE: The Transfer event, which is defined on the ERC-721, is emitted by this function.
Example) Creators' Royalty Tokens related sequence flow on Conata Project.
Cancel TradeOrder
function cancelTradeOrder(address buyer, uint256 tokenId) external
Call this function so that the buyer could cancel the order of the trade.
Setter Function
function setPublisherFeeRate(uint256 feeRate) external
The feeRate argument CAN be set as a publisher fee rate by the owner of the contract.
function setCreator(uint256 tokenId, address payable creator) public
The creator argument MUST be the address of an account that created the artwork. The owner of the contract CAN map the tokenId and creator address.
function setCreatorFeeRate(uint256 tokenId, uint256 feeRate) external
The feeRate argument CAN be set as a creator fee rate by the owner of the contract.
Rationale
Based on ERC721
ERC-721 is widely applied to many projects that use non-fungible tokens such as CryptoKitties. Since a creators' artwork is registered as non-fungible tokens, this standard inherits ERC-721.
Each artwork has a unique token ID. Also, the token will be transferred through ERC-721 _transferFrom function in tradeAndDistributeFee function, though there are some restrictions to transfer tokens as explained in the following section.
Limited Transfer
This standard doesn’t provide a general transfer function, by which non-fungible tokens holders can transfer their non-fungible tokens freely whenever they want. This is because creators can’t get royalties if it is possible. Transfer is executed with tradeAndDistributeFees function, and every time holders transfer their non-fungible tokens, the creators can get royalties through the function.
Decentralized Exchange Function
This standard provides DEX through readyForSale function and tradeAndDistributeFee function. In order to allow a buyer to purchase a non-fungible token, the token’s holder (seller) passes a buyer’s address and a token ID as arguments to readyForSale function, and stores the hash value of the arguments with the seller’s own address. After that, the buyer calls tradeAndDistributeFee, which checks the hash value, and transfers the NFT and distributes the fees if the hash value is correct.
Fee Distribution
In this standard, not only creators but also publishers can get some fees. Furthermore, publishers can set the fee rate like OpenSea, which is one of the most famous non-fungible token secondary markets. A fee rate for publishers is set through setPublisherFeeRate and A fee rate for creators is set through setCreatorFeeRate.
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: