Discussion for EIP-2981: NFT Royalty Standard

[VexyCats]

TL;DR - ERC721s have a ton of creators and a few marketplaces, but no accepted means for transferring royalties from items being sold multiple times on secondary sales. This EIP is proposing a standard method that can be implemented by all marketplaces easily.

// SPDX-License-Identifier: MIT

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC165 standard, as defined in the
 * https://eips.ethereum.org/EIPS/eip-165[EIP].
 *
 * Implementers can declare support of contract interfaces, which can then be
 * queried by others ({ERC165Checker}).
 *
 * For an implementation, see {ERC165}.
 */
interface IERC721Royalties {
    
    
    /**
    @notice This event is emitted when royalties are received.

    @dev The marketplace would call royaltiesRecieved() function so that the NFT contracts emits this event.

    @param creator The original creator of the NFT entitled to the royalties
    @param buyer The person buying the NFT on a secondary sale
    @param amount The amount being paid to the creator
  */
    event RecievedRoyalties (address indexed creator, address indexed buyer, uint256 indexed amount);
    
    /**
     * @dev Returns true if this contract implements the interface defined by
     * `interfaceId`. See the corresponding
     * https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section]
     * to learn more about how these ids are created.
     *
     * This function call must use less than 30 000 gas.
     */
    function supportsInterface(bytes4 interfaceId) external view returns (bool);
    
     /**
     * @dev Returns true if implemented
     * 
     * @dev this is how the marketplace can see if the contract has royalties, other than using the supportsInterface() call.
     */
    function hasRoyalties() external view returns (bool);

     /**
     * @dev Returns uint256 of the amount of percentage the royalty is set to. For example, if 1%, would return "1", if 50%, would return "50"
     * 
     * @dev Marketplaces would need to call this during the purchase function of their marketplace - and then implement the transfer of that amount on their end
     */
    function royaltyAmount() external view returns (uint256);
    
      /**
     * @dev Returns royalty amount as uint256 and address where royalties should go. 
     * 
     * @dev Marketplaces would need to call this during the purchase function of their marketplace - and then implement the transfer of that amount on their end
     */
    function royaltyInfo() external view returns (uint256, address);
    
      /**
     * @dev Called by the marketplace after the transfer of royalties has happened, so that the contract has a record 
     * @dev emits RecievedRoyalties event;
     * 
     * @param _creator The original creator of the NFT entitled to the royalties
     * @param _buyer The person buying the NFT on a secondary sale
     * @param _amount The amount being paid to the creator
     */
    function royaltiesRecieved(address _creator, address _buyer, uint256 _amount) external view;
}

Flow: (just suggestions, can be implemented however you like)

Constructor/deployment

Creator - the person who gets the royalties for secondary sales is set.
Royalty Amount - the percentage amount that the creator gets on each sale, is set.

NFT sold on marketplace

Marketplace checks if the NFT being sold has royalties implemented - if so, call royaltyInfo() to get the amount and the creator's address.

Calculates the amount needed to be transferred and then executes that transfer.

Calls royaltiesRecieved() so that the NFT contract has a record of receiving the funds during a sale.

---

Thoughts? Anything that should be added or removed to make it easier to be implemented?

The logical code looks something like this:

abstract contract Royalties {
    /*
     * bytes4(keccak256('supportsInterface(bytes4)')) == 0x01ffc9a7
     */
    uint256 private royalty_amount;
    address private creator;
 
    /**
    @notice This event is emitted when royalties are transfered.

    @dev The marketplace would emit this event from their contracts. Or they would call royaltiesRecieved() function.

    @param creator The original creator of the NFT entitled to the royalties
    @param buyer The person buying the NFT on a secondary sale
    @param amount The amount being paid to the creator
  */
 
  event RecievedRoyalties (address indexed creator, address indexed buyer, uint256 indexed amount);
    constructor (uint256 _amount, address _creator) internal {
        royalty_amount = _amount;
        creator = _creator;
    }

    
    function hasRoyalties() public pure returns (bool) {
        return true;
    }


    function royaltyAmount() public view returns (uint256) {
        return royalty_amount;
    }
    
    function royaltyInfo() external view returns (uint256, address){
        return (royalty_amount, creator);
    }
    
    function royaltiesRecieved(address _creator, address _buyer, uint256 _amount) external {
        emit RecievedRoyalties(_creator, _buyer, _amount);
    }
}

[MicahZoltu]

What stops people from just transferring the asset via a wrapper to avoid paying on-transfer royalties? Perhaps time based royalties would be better, as those cannot be avoided (essentially, you are renting the asset rather than buying it).

[VexyCats]

@MicahZoltu there is no implementation for on-transfer royalties. The NFT marketplace that facilities the trade would be the one who is doing the transfer of funds.

So the smart contracts for something like Opensea, or Mintable, would facilitate the sell, and during the function handling the sell and transfer from seller to buyer, it would check if there are royalties and if so - send the % of the sale to the creator.

This means that using a wrapper doesn't really work, as wrapping a NFT would change the information on most NFT marketplaces - such that your game item from say Gods Unchained, would not be under the same contract as all Gods Unchained items. (although this is mainly for artwork and other content not gods unchained cards, but the example still applies - wrapping an NFT would change how its displayed on marketplaces and most likely deter buyers, and/or be flagged by the marketplace as a scam/fake ).

[MicahZoltu]

Would participation be voluntary by OpenSea or Mintable then? If so, why is a standard necessary? Is it just to provide a common mechanism by which individual NFTs can advertise their requested royalty rate?

[VexyCats]

Yes, participation is voluntary - just as following the ERC165 standard is voluntary.

Currently there are 3 NFT marketplaces that all use different formats of royalties and one NFT on one marketplace with royalties, does not get seen/abided by on others.

This proposal is simply a standard way to implement royalties that each marketplace can use, so that NFTs with royalties can be accepted across all marketplaces.

Of course if the marketplace chooses not to accept royalties that have been implemented then there is nothing that creator can do, other than not use that marketplace (but doesn't stop others from selling the NFT on there after purchase).

Hence the need for a standard way to implement royalties that can be accepted across the board.

[VexyCats]

If anyone has a suggestion on an implementation for

function royaltiesRecieved(address _creator, address _buyer, uint256 _amount) external view;

Please let me know - currently, it emits the event RecievedRoyalties but on testing, I realized its public and anyone can spam that event with fake data.

Since most marketplaces do not send ETH via calling the method and sending ETH in the same call - making it payable and checking the msg.value also isn't a good way.

Open to suggestions.... it doesn't NEED to be included actually, its just a nice way for the creator/others to see that royalties have been received based off secondary sales, which otherwise would be hard to identify

[martinkrung]

I have background in art, and a standard for royalties would be critical for market adoption. This would be a big shift for artist. Because even successful artist do not get any share if their work is resold in the secondary market.

They sell cheap when they are unknown and if they have success all the others are making a fortune out of it. I even think this would lead to better quality. Because many artists tend to get in a loop and produce more of the same: the market wants recognizable art, and they need to make a living out of it, so they end up delivering the same shit over and over again.

I did some research like 20 years back and this is only partly true. For most small-town artist there is no secondary market anyway. But crypto may change this.

And about wrapping: If NFT are really used in the high roll art market not respect the royalties will not happen, because nobody will buy something with shady legal background.

[jamesmorgan]

Hi everyone, a few thoughts on the standard and some use cases which may help:

• It would be good to open the query methods up to be on a per token basis, some tokens may have different royalties than others and it may not be a platform wide fix %. Also if its per token the recipient address can be defined which may be a multi-sig or another construct which would allow joint access to it if the token is a collaborator.

• It would be good to allow a list of recipients - often tokens are part of a collaboration and may nee the funds splitting up between a list of people.

Standards are great, thanks for driving this initiative.

[MicahZoltu]

Open to suggestions.... it doesn't NEED to be included actually, its just a nice way for the creator/others to see that royalties have been received based off secondary sales, which otherwise would be hard to identify

Given that it can be spoofed maliciously, I would just remove it. Apps will have to do other things to monitor royalty payments.

[MicahZoltu]

Consider renaming creator to royaltyRecipient in the code for clarity. Royalty recipient should probably be transferable in most cases, and so creator isn't really accurate.

[dievardump]

What about a

payRoyalties(address _royaltyRecipient, address _buyer) payable

that will actually perform a check that there is a value sent and redirect to _creator.
It would also fire the event RecievedRoyalties, to which I would personaly also add the caller, helping to identify what contract actually did the royalties payment.

[VexyCats]

Will rename creator to `royaltyRecipient.

@dievardump - there is no way to check for a value other than if that value is over the lowest amount possible. As the contract doesn't know what the NFT sold for, and therefore doesn't know how much royalties should be transferred. Unless you have an alternative suggestion?

Also since the marketplace contract is already transferring funds from the buyer to the seller - I believe its best to leave that responsibility on them and not the standard `to transfer the actual royalty payment.

@MicahZoltu For the event - what about a requirement that the marketplace must emit that event if they follow the standard? That would be the only requirement that they would need to follow in using this standard?

[VexyCats]

I've updated the EIP to reflect the comments, and suggestions from everyone.

Including adding independent token royalties, such that one NFT can have a royalty amount different from another.

I've changed the percentage to a fixed point scaled to 10,000 as well to offer lower percentages possible.

Please review and let me know if anyone has any feedback

[dievardump]

@VexyCats - The problem is, as long as royaltiesRecieved doesn't perform a check if the current call has any value in it, anybody can call it with a fake amount, which will result in a fake event. Or a contract could say "I paid the fee" but didn't.
I didn't mean for payRoyalties to check that the value is the right one, I mean for payRoyalties to check that there is any value with the current call (if this NFT has a royalty fee), and that this value is used as the event royalties amount (and also transferred to royaltyRecipient/store for royaltyRecipient to claim later). This way, there is no spoof possible, as the event will correspond to a real value transferred.

We are currently developing an app that will onboard artists and the royalties question is very present. There are several ways to try to put it in place, but a standard that could be followed by the community and especially the marketplaces would be much welcome.

To be honest, a standard where the Marketplace would call a function on the ERC721 contract any time something is bought, even if there is no royalties, would also be very welcome, as this would facilitate for example to activate a lot more different system than just royalties on buy, but also for example royalties in the form of the Hardberger tax (or any other you can name).

So a more generic function like the one following (also with a token equivalent as not everything is sold using ETH):

 /**
     * @dev Called by the marketplace when a sell happened
     * @dev Expects msg.value to be of the amount of the royalties if there are 
     * @dev can emit RecievedRoyalties event;
     * 
     * @param _index Index of the NFT
     * @param _buyer The person buying the NFT
     * @param _soldAmount The amount this NFT has been bought
     */
function marketSell(uint _index, address _buyer, uint256 _soldAmount) external payable;

then if there are royalties on the specified nft, the contract could verify that the call value correspond to the percentage, send the value to the royaltiesRecipient, and emit the event.

But if for example there is a Harbergertax in place (which is also Royalties), it could easily store the sell price, and start the process of getting taxation.
This would allow a brand new horizon for royalties systems, as long as Marketplaces follow the standard.

About the current implementation :

• I would also do everything per NFT id
• I would remove hasRoyalties(), and just use royaltyAmount(uint index), which would return 0 if there is none. That saves one external call.

[VexyCats]

@dievardump Thanks for the feedback, here are my thoughts.

Accepting payment on the function to emit the event, therefore marking the function as payable as your code does - would not work. As the creator should be getting the royalties and not the contract. Implementing a payment to the contract would require all royalty enabled contracts to handle the withdrawal of royalties on their NFT contract.

Also - checking for a msg.value doesn't really solve anything in terms of spoofing - I can simply send 0.0000000000001 eth as the value (pretty much worthless amount) and it would fire the event. I'd pay more in a gas fee than the amount sent to spoof.

Finally, all of this comes down to implementation details and not standard specific details. So it really doesn't matter/fit into the scope of the standard itself but rather how someone chooses to implement it.

I do understand an event spoofing might be an issue - although.... its not really an issue though?

Hear me out: If an event if fired - it doesn't affect anything, any person.... it would only affect a dapp using the events to log royalties. But even then - the dapp can simply check if there was actual ETH sent to the address specified when that event was fired and if so, log it as a true/successful payment. If it was spoofed and there was no ETH value then it doesn't get logged.

So I don't think the royalties event being spoofed is an issue at all - although if it doesn't fit the criteria for a standard then we should discuss a way to rework it.

Again - its not technically needed, but its one way to provide a means of notification that says - you received a royalty payment. Otherwise - how would a person be notified?

@MicahZoltu you've been quite helpful here - any thoughts?