A Guide to NFT Royalties // How They Work and Why They Matter
For artists and creators, NFTs are overflowing with promise. The reality is that NFTs are drastically changing the ways in which a creators' work is viewed and sold. As a result, the ecosystem has recently been the source of a lot of attention.
One of the most profound and new capabilities for a creator of NFTs is the potential income to come from residual and perpetual royalties. Prior to NFTs, the vast majority of secondary art sales provided no benefit to the original artists, sometimes with their artwork reselling for hundreds or thousands of times more than the initial sale from the artist. With NFTs, the ability for a robust secondary market with the digital provenance to allow for built-in royalties was suddenly possible.
If you’ve already created a NFT project, are in the process of creating one, or are simply interested in how NFTs can provide automated, residual income to creators as their work circulates, then keep on reading. The goal of this article is to offer actionable advice on how to add NFT royalties to your projects.
What is an NFT? A non-fungible token (NFT) is a cryptocurrency token that is indivisible and unique. For more information, you can read this article. If you’re interested in the making of an NFT, then you’ll find this post useful.
What is an NFT royalty? NFT royalties give the creator a percentage of the sale price each time their NFT creation is sold on a marketplace. Many creators have already been able to realize a newfound passive income stream from NFT royalty payments.
For those unfamiliar with the burgeoning domain of NFT royalties, it’s worth providing a brief overview. Since its release over one year ago EIP2981 has become the community's choice as the official Non-Fungible Token (NFT) royalty standard. The basic idea behind the EIP2981 was to decentralize the royalty information for an NFT by moving it from discrete centralized databases onto the Ethereum blockchain, all in a cost-effective manner.
Currently the vast majority of NFT royalty information is stored centrally by NFT marketplaces such as OpenSea. It became clear to those marketplaces early on that enabling royalty payments was imperative for the overall growth of the ecosystem. To facilitate this feature, the fastest approach was for marketplaces to collect royalty information (e.g. royalty recipient addresses, percentage payout per sale) from NFT creators and store it in their application’s databases.
Generally speaking, this strategy worked well. However, as more NFT marketplaces launched offering new and compelling features, it became clear that centralized royalty information was not conducive to the needs of creators across the diversity of marketplaces. The reason for this is that if one marketplace amasses all of the royalty information, then NFT creators are inherently constrained to a single platform if they want to receive royalties for their work. Competing marketplaces will not be privy to the royalty information that is needed to construct and send royalty payments to creators. Therefore, creators are incentivized to stay on the platform that pays them. Gatekeeping royalty information in this way only serves to create more customer lock-in. EIP2981 provides the ecosystem with an alternative storage model for royalty information that aims to tackle the aforementioned drawbacks caused by the siloing of data.
Since the release of EIP2981, the NFT royalty landscape has been evolving at a rapid pace. Much credit must be attributed to NFT marketplace Manifold.xyz, who have been instrumental in pushing the broader NFT space forward. In late 2021, they led the open source release of the NFT Royalty Registry (royaltyregistry.xyz), in collaboration with many other major NFT marketplaces including OpenSea, NiftyGateway and Coinbase NFT. The release of the Royalty Registry marked a pivotal moment that enabled marketplaces, creators, and owners to easily opt into on-chain royalties en masse.
What’s the difference between EIP2981 and the Royalty Registry?
While related, EIP2981 and the Royalty Registry are different pieces of the puzzle which, together, make a standardized approach to royalties viable. EIP2981 is an Ethereum Improvement Proposal that has been finalized and accepted by the Ethereum community. It is a written document that tells developers how to attach on-chain royalty information to their NFT projects in a way that is compliant with the EIP, and through doing so ensures compatibility with everyone else who follows the same EIP. In contrast, the Royalty Registry is a set of smart contracts that exist on EVM compatible blockchains (Ethereum & Polygon at the time of writing) that facilitate the retrieval of on-chain royalty information. As the name suggests, the royalty registry is a registry; one that hopes to become the canonical way for users to find royalty information for any NFT that has been minted.
Some readers may be asking themselves why there is a need for a registry at all as NFT projects that are compliant with EIP2981 already contain all the royalty information themselves. The need for this registry is due to the enormous number of NFTs that have already been minted without any royalty information on-chain (aka pre-EIP2981). While EIP2981 provides a way for NFT creators to embed royalty data; there is a long tail of NFTs that had been deployed before the EIP was finalized and thus lack the necessary embedded royalty information. Deploying a royalty registry means that royalty information from NFTs that were created both pre and post-EIP2981, can be stored and retrieved from a single, agreed-upon data store, using well-defined interfaces.
Typical usage of the Royalty Registry would be via a new message call to the registry's smart contracts; the message call requests the royalty information of a given NFT, identified through the usage of its token ID and contract address (as per the ERC721 specification). It is important to note that this message call does not require creating and submitting a transaction to the blockchain, and so is cost free. Once the message call is invoked, the relevant data is immediately returned.
We can see where this inbound message call gets consumed, from the Royalty Registry’s Github documentation:
```
-- CODE language-js --
function getRoyaltyView(
address tokenAddress,
uint256 tokenId,
uint256 value
)
public view override returns(
address payable[] memory recipients,
uint256[] memory amounts
)
```
Once provided with a `tokenId` and a `tokenAddress` by the message call, the registry then proceeds to find the information for that NFT regardless of whether it supports EIP2981 or not.
In an ideal world, all NFTs to ever exist would have support for EIP2981, but unfortunately they don’t. The registry provides us with the necessary level of indirection to add royalty data to NFTs that didn’t originally support on-chain royalties, while also supporting newer NFTs that have adopted EIP2981.
The Royalty Registry also provides a caching system that optimizes lookups over time, which in turn reduces the costs on marketplaces. This caching mechanism relates specifically to instances when the invocation of the registry contract is not a message call as previously described, but instead is a state changing transaction. An example of such a transaction would be through an on-chain NFT marketplace, let's call them `NFTMart`, whose smart contracts need to interact with the Royalty Registry. In this scenario, if NFTMart sells the same NFT more than once, then retrieving the royalty information for that NFT becomes more cost effective after the first retrieval as they are able to refer to the data in the cache, which takes fewer on-chain operations. Fewer operations means lower ‘gas’ fees, which directly reduces the cost of royalty information lookup.
How the Royalty Registry supports existing NFTs
Existing NFT creators that missed the EIP2981 boat might be frustrated and thinking, “I wish I released my collection a little later”. If you are that person, don’t fret! With some help from EIP2981 and EIP1167 (a minimal proxy contract pattern), Manifold.xyz has created a gas efficient way for users to deploy and register royalty information for their existing NFTs, even if they were deployed pre-EIP2981.
They’re referred to as “override contracts”, and they’re what the Royalty Registry uses under the hood when a query arrives that asks for your NFT’s royalty information. From a high level, an override contract will be queried by the Royalty Registry if your NFT collection’s contract address has not directly implemented EIP2981. The override contract is a workable alternative to directly implementing EIP2981 for storing royalty information on-chain in a compliant way.
It’s important to note that successfully creating and registering a new override contract for a given ERC721 contract is predicated upon both contracts being deployed by the same private key. However, there are exceptions to this, especially if the original private key is inaccessible for some reason. In these circumstances, the owner of the inaccessible private key has the option to contact the Royalty Registry working group directly, which currently means raising a Github issue and undergoing a review process. Manual changes such as these to the Royalty Registry require a quorum of signatures from participants in the Royalty Registry Gnosis safe multisig to be put into effect.
The ‘overrideAllowed’ function is the code responsible for enforcing these authorization rules at the smart contract level. Without these security mechanisms, any actor could effectively change the royalty information of any NFT, which could have numerous negative outcomes including the ability to redirect the wallet address royalties are sent to. Upon deployment of an override contract, the deployer has a choice to set token or global level royalties; useful for those collections that have differing or complex royalty structures. The easiest way to do all of the above is through Manifold’s user interface which can be found here.
Supporting new NFTs
You can, of course, continue deploying your ERC721 contract unchanged with the plan of deploying an override contract later which will contain the royalty data. While technically possible, that’s not an optimal strategy as it is likely not gas efficient. Ideally, you should include EIP2981 support directly within your contract code, and this has proven to be painless to implement. OpenZeppelin continues to provide excellent guard rails in the form of the EIP2981 interface to help you get started. If you are looking for a reference contract implementation, a great resource can be found here on Github.
It’s highly encouraging to see how many platforms have decided to support EIP2981 by default. This means that any new NFT project launched via the platform's tooling will already handle all of the EIP2981 implementation details. A good example of a major marketplace adopting EIP2981 is Nifty Gateway’s integration, which can be seen on-chain here (Royalties.sol). With this in place, all new drops on the Nifty Gateway platform will have EIP2981 compliant on-chain royalties baked into each NFT.
NFTs that are created with native support for EIP2981 have the additional advantage that they are automatically picked up by the royalty engine and made easily available to everyone that uses the registry.
Conclusion
We’ve learned about how the Royalty Registry and EIP2981 work together, and know that the registry was one of the last remaining pieces to make on-chain royalties easier to manage. Building on that understanding we developed a working knowledge of how to integrate on-chain royalties into projects, along with the benefits of doing so. Those benefits can be summarized as:
- Royalty information has the most utility when it's on-chain.
- To obtain an NFT’s royalty information, query the Royalty Registry for it.
- Stay compatible with the Royalty Registry by implementing EIP2981 on your NFT smart contract.
- For NFT contracts that do not support EIP2981, deploy an override contract via Manifold’s easy to use interface to participate in the open royalty ecosystem.
Ultimately, the goal of democratizing royalty information can only be fully realized with the help of the wider community. Following the practices laid out in this article will not only help creators increase their likelihood of receiving royalty payments, but you’ll also be supporting an important effort to increase the overall transparency of NFT royalty payments. We now know that on-chain royalties are a step change for the NFT royalty ecosystem.
