Registry for royalties payment for NFTs

Abstract

This standard allows anyone to pay royalties for a certain NFT and also to keep track of the royalties amount paid. It will cumulate the value each time a payment is executed through it and make the information public.

Motivation

There are many marketplaces which do not enforce any royalty payment to the NFT creator every time the NFT is sold or re-sold and/or providing a way for doing it. There are some marketplaces which use specific system of royalties, however that system is applicable for the NFTs creates on their platform.

In this context, there is a need of a way for paying royalties, as it is a strong incentive for creators to keep contributing to the NFTs ecosystem.

Additionally, this standard will provide a way of computing the amount of royalties paid to a creator for a certain NFT. This could be useful in the context of categorising NFTs in terms of royalties. The term “debt“ is used because the standard aims to provide a way of knowing if there are any royalties left unpaid for the NFTs trades that took place in a marketplace that does not support them and, in that case, expose a way of paying them.

With a lot of places made for trading NFTs dropping down the royalty payment or having a centralised approach, we want to provide a way for anyone to pay royalties to the creators.

Not only the owner of it, but anyone could pay royalties for a certain NFT. This could be a way of supporting a creator for his work.

Specification

The keywords “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.

Every contract compliant with ERC-6786 MUST implement the interface defined as follows:

Contract Interface

// @title Royalty Debt Registry
/// Note: the ERC-165 identifier for this interface is 0x253b27b0

interface IERC6786 {

    // Logged when royalties were paid for a NFT
    /// @notice Emitted when royalties are paid for the NFT with address tokenAddress and id tokenId
    event RoyaltiesPaid(address indexed tokenAddress, uint256 indexed tokenId, uint256 amount);

    /// @notice sends msg.value to the creator of a NFT
    /// @dev Reverts if there are no on-chain informations about the creator
    /// @param tokenAddress The address of NFT contract
    /// @param tokenId The NFT id
    function payRoyalties(address tokenAddress, uint256 tokenId) external payable;

    /// @notice Get the amount of royalties which was paid for a NFT
    /// @dev 
    /// @param tokenAddress The address of NFT contract
    /// @param tokenId The NFT id
    /// @return The amount of royalties paid for the NFT
    function getPaidRoyalties(address tokenAddress, uint256 tokenId) external view returns (uint256);
}

All functions defined as view MAY be implemented as pure or view

Function payRoyalties MAY be implemented as public or external

The event RoyaltiesPaid MUST be emitted when the payRoyalties function is called

The supportsInterface function MUST return true when called with 0x253b27b0

Rationale

The payment can be made in native coins, so it is easy to aggregate the amount of paid royalties. We want this information to be public, so anyone could tell if a creator received royalties in case of under the table trading or in case of marketplaces which don’t support royalties.

The function used for payment can be called by anyone (not only the NFTs owner) to support the creator at any time. There is a way of seeing the amount of paid royalties in any token, also available for anyone.

For fetching creator on-chain data we will use ERC-2981, but any other on-chain method of getting the creator address is accepted.

Backwards Compatibility

This ERC is not introducing any backward incompatibilities.

Test Cases

Tests are included in ERC6786.test.js.

To run them in terminal, you can use the following commands:

cd ../assets/eip-6786
npm install
npx hardhat test

Reference Implementation

See ERC6786.sol.

Security Considerations

There are no security considerations related directly to the implementation of this standard.

Copyright

Copyright and related rights waived via CC0.