iTranslated by AI
An Overview of NFT Royalty Mechanisms on Ethereum
Introduction
The mechanism that allows a portion of the fee in the secondary market to be returned to the creator is often cited as one of the benefits of turning a work into an NFT. This fee is what we call a royalty.
Providing continuous rewards to creators increases the sustainability of a project, creating a win-win situation for NFT holders as well.
However, it is important to note that simply turning a work into an NFT does not mean royalties will automatically flow in. It naturally depends on including royalty information within the NFT itself, but it also depends on the design of the marketplaces where they are bought and sold.
Therefore, I would like to summarize the royalty mechanism and how to integrate it in a way that is easy to understand, even for those who are about to develop NFTs.
Prerequisites
- NFTs issued with ERC721/ERC1155 are the target
- Assuming royalty distribution in secondary sales
tl;dr
- Royalty distribution also depends on the marketplace.
- Creating or trading NFTs across different marketplaces may result in not receiving royalties.
- If you have already issued an NFT but forgot to set the royalties, there is the Royalty Registry.
What are Royalties in NFTs?
Basically, NFTs are bought and sold on marketplaces like OpenSea. There are many types of marketplaces, such as those that handle a wide range of categories horizontally, those specialized in specific categories, and those specialized in specific in-game items.
The distribution of royalties basically depends on the implementation method of the application layer, such as the marketplace.
Timing of Distribution
When buying and selling NFTs, marketplace fees and creator royalties are distributed. At this time, fees are automatically collected at the rate set by the marketplace, but royalties must be set independently by the NFT creator.
Implementation Methods for Distribution
This varies by marketplace. The key difference lies in where the royalty information is stored. For example, there are methods such as traditional database management (off-chain) or implementation on smart contracts (on-chain).
Here are some representative examples:
| Marketplace | Standard |
|---|---|
| OpenSea | Off-chain |
| Rarible | Proprietary Standard (On-chain) |
| Foundation | Proprietary Standard (On-chain) |
| Coinbase NFT | ERC2981 + Royalty Registry |
What you need to be careful about here is that if the minting and trading of an NFT span multiple marketplaces, you might not receive royalties in some cases.
OpenSea is a clear example: when royalty information is stored in the operator's database, other marketplaces cannot access that royalty information. Therefore, NFTs minted through OpenSea's storefront cannot receive royalties unless they are traded on OpenSea. (Though one could argue that, given OpenSea's trading volume, it is not always necessary to assume trading on other marketplaces.)
Furthermore, ERC2981 is a royalty standard defined at the Ethereum protocol layer. Since this standard was created in 2020, many major marketplaces currently in use still do not support it. Coinbase NFT, which was recently released to the public, does support it, so I expect this kind of royalty mechanism will become the standard for future marketplaces (my hope).
I will explain the Royalty Registry later.
(Side note) How to split royalties among multiple addresses?
In the ERC2981 standard mentioned above, you can only specify a single address to receive royalties. Despite Foundation having a convenient feature called "Split" that distributes royalties to multiple people, having use cases restricted by protocol-side standards could hinder convenience.
However, this split-like functionality can be achieved by setting the recipient address to a contract address. In other words, you pool the received royalties within a contract and define the distribution rules within that contract. By utilizing a separate contract, there is no need for local optimization of the standard itself.
In general, there is a tendency at the protocol layer to avoid covering too many specifications, and as simple a configuration as possible is required. Naturally, these kinds of discussions are also taking place within the GitHub issues, so please refer to them if you are interested.
So, Can I Receive Royalties?
Patterns where you can receive royalties
- When minting and trading are completed within a single marketplace
- When royalties are set on OpenSea and the trade occurs within OpenSea
- When created with a custom contract (ERC2981 compliant) and traded on an ERC2981-compliant marketplace
Patterns where you cannot receive royalties
- When minting and trading span across marketplaces that use off-chain or proprietary standards
Patterns where you can receive royalties with some effort
- When minted on a marketplace with its own on-chain royalty standard and traded on a marketplace with a standard like Coinbase NFT
- When created with a custom contract (not ERC2981 compliant) and traded on a marketplace with a standard like Coinbase NFT
Receiving them "with some effort" means that additional settings must be configured on the Royalty Registry.
What is the Royalty Registry?
In a nutshell, it is a bulletin board where you can look up royalty recipient addresses. In other words, you can set royalty information without modifying an already deployed smart contract.
If you are the contract owner, you should be able to set it from the "configure" at the top, but please refer to the official documentation for details.
(Please note again that registering on the Royalty Registry is meaningless if the marketplace does not reference it.)
Summary
I have summarized the current state of royalty mechanisms on Ethereum. It is not as simple as just defining it in a contract; there are some complex aspects, such as distribution not occurring depending on which marketplace is used for the trade. I hope this provides some helpful insights.
As I researched the royalty mechanism, I felt that creating NFTs with a custom contract serves as a risk hedge, keeping future options open.
References
Discussion