EIP-2981: NFT Royalty Standards

First, let's define the big terms.

EIP stands for Ethereum Improvement Proposal. It's a formal proposal for changing or improving the Ethereum protocol.

An NFT, or Non-Fungible Token, is a type of digital asset on a blockchain that represents ownership or proof of authenticity of a unique item or specific item, such as art, music, or collectibles, usually stored on a decentralized network. Unlike cryptocurrencies like Bitcoin or Ethereum, which are fungible (interchangeable), NFTs are unique and cannot be exchanged on a one-to-one basis. Each NFT has distinct properties, making it unique.

Here are some types of NFTs: digital arts, collectibles (cryptoPunks), gaming assets, virtual land, music NFTs, utility NFTs, Domain names.

Royalties are payments made to the owner of a creative work or intellectual property (e.g., music, books, patents, or software) for the use or sale of that work. They are typically a percentage of revenue or a fixed amount per unit sold or used, paid by the licensee (e.g., a publisher, producer, or distributor) to the creator or rights holder.

A marketplace is an online platform where buyers and sellers can trade goods or services. In the context of NFTs, a marketplace is a digital space (e.g., OpenSea, Rarible) built on a blockchain where users can buy, sell, or trade non-fungible tokens (NFTs). The royalty mechanism often follows a standard, where the creator embeds the royalty rate into the token's metadata. Although, one marketplaces may impose their own default royalty rates or limits.

EIP-2981 was created on the 15th of September, 2020, by Zach Burks, James Morgan, Blaine Malone, James Seibel and is currently in the final phase. It enables NFT creators to receive a percentage of sales whenever their work is resold on any marketplace.

This proposal only provides a mechanism for retrieving the royalty payment information, which specifies how much to pay to which address for a given sale price. The actual funds transfer is something which the marketplace should execute.

This EIP requires EIP-165 (Standard Interface Detection), which creates a standard method to publish and detect what interfaces a smart contract implements. EIP-2981 requires EIP-165 to ensure that smart contracts can reliably identify whether a given contract supports the EIP-2981 royalty standard. This prevents errors or assumptions when trying to fetch royalty information from contracts that don’t support it.

The giving of royalties is voluntary. This is because not all NFT transfers are the result of sales, some can be wallets moving or consolidating their NFTs. This means that while the standard provides a way for NFT contracts to specify royalty information (via the royaltyInfo function), there is no enforcement mechanism within the Ethereum blockchain or the EIP-2981 standard itself to mandate that marketplaces or buyers actually pay those royalties. Marketplaces are left with the option to adopt this standard and then enforce it within their space. If a marketplace chooses not to implement this EIP, then no funds will be paid for secondary sales.

Purpose/Motivation

There are many marketplaces for NFTs with multiple unique royalty payment implementations that are not easily compatible or usable by other marketplaces. This enables accurate royalty payments regardless of which marketplace the NFT is sold or re-sold at. It provides a standard method of specifying royalty payment information which can be retrieved across any type of NFT marketplace and is not restricted to marketplaces that implement EIPs-721 and 1155.

EIP-2981 Specifications

1. Marketplaces that support this standard should implement some method of transferring royalties to the royalty recipient.

2. Marketplaces must pay the royalty in the same unit of exchange as that of the salePrice function passed to royaltyInfo().

3. Implementers of this standard must calculate a percentage of the salePrice function when calculating the royalty amount regardless of the currency. If the royalty fee calculation results in a remainder, implementers may round up or round down to the nearest integer.

4. The royaltyInfo() function is not aware of the unit of exchange for the sale and royalty payment. With that in mind, implementers must not return a fixed/constant royaltyAmount, wherein they’re ignoring the _salePrice. Also, implementers if this EIP must not determine the royaltyAmount based on comparing the salePrice with constant numbers. In both cases, the royaltyInfo() function makes assumptions on the unit of exchange, which must be avoided. The percentage value used must be independent of the sale price.

5. The implementer may choose to change the percentage value based on other predictable variables that do not make assumptions about the unit of exchange. One approach is to use the number of transfers of an NFT to decide which percentage value is used to calculate the royaltyAmount. Another example could be using a different percentage value for each unique tokenId.

6. Marketplaces that support this standard should not send a zero-value transaction if the royaltyAmount returned is 0. This would waste gas and serve no useful purpose in this EIP.

7. Marketplaces that support this standard must pay royalties no matter where the sale occurred (whether on-chain, off-chain sales such as auction houses, or over the counter) or in what currency. The exact mechanism for paying and notifying the recipient will be defined in future EIPs.

Functions and Parameters

Function involved: royaltyInfo,

Parameters: _salePrice, royaltyAmount, _tokenId.

salePrice is the amount the EIP is being sold and royaltyAmount of the amount to be paid for royalty.

The royaltyInfo function is a standardized function in EIP-2981 that returns the royalty recipient and the royalty amount for a given NFT sale. It’s designed to be queried by marketplaces or other contracts to facilitate royalty payments to creators when an NFT is resold.

function royaltyInfo(uint256 tokenId, uint256 salePrice) where tokenId is the unique identifier of the NFT which is only relevant for EIP-721 and EIP-1155 tokens.

Related EIPs

EIP-721: A standard interface for non-fungible tokens, also known as deeds. This standard allows for the implementation of a standard API for NFTs within smart contracts. This standard provides basic functionality to track and transfer NFTs.

EIP-1155: A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens). Existing standards such as ERC-20 require deployment of separate contracts per token type.