Royalties - Demystified 💰
What are they, how they work, and proposal for a cross-platform registry
One of the most important aspects of NFTs are royalties, the ability for the original artist to earn revenue whenever their works are re-sold. Artist royalties are not a new concept, tracing back to the 1800’s. However, the largest marketplaces in the NFT ecosystem built royalties into their platform right from the get-go, setting the precedent for this to be standard practice.
Basics of an NFT (required knowledge)
An NFT is not an asset that stands on its own. It is made up of two core components:
A smart contract (coded to ERC721 or ERC1155 specifications)
A token identifier
An NFT is the combination of the smart contract (which acts as the owner registry and logic engine for the NFT) and the token identifier. Whenever you mint something on a platform like OpenSea, your NFT is an identifier on their smart contract, governed by their smart contract rules.
How do royalties actually work?
Royalties are administered and paid out by each marketplace. Each marketplace has its own logic on how to determine the royalties for any given NFT and how they are distributed.
One common misconception is that if you encode your royalties into your smart contract, every marketplace will adhere to it. This is NOT TRUE.
To explain why, let’s consider a sale of an NFT. A sale is actually a transaction made up of two actions:
A transfer of funds from the buyer to the seller
A transfer of the NFT from the seller to the buyer
The facilitator of these two actions is the marketplace. They ensure that the amount of funds and the NFT is agreed upon by both parties, and facilitates these two transactions. The marketplace is the only ones that can validate the terms of sale. Hence, they are the only ones that can apply royalty rules (i.e. take a proportion of funds and distribute to the NFT creator).
The reasons that ERC721/ERC1155 smart contract cannot enforce royalties are two-fold:
The smart contract never touches the funds transferred
The smart contract has no way to tell whether or not the NFT transfer was a sale, or simply from someone moving the NFT from one wallet to another
The smart contract can publish the appropriate royalties, but it is up to the marketplace to adhere to it. Some marketplaces read the royalty data from the smart contract (e.g. Rarible and Foundation) and others require you to add a separate configuration to their site (e.g. OpenSea). Zora relies on tight integration between the token contract and the Zora marketplace contract in order for royalties to be properly paid out (i.e. a Zora token resold on OpenSea won’t pay out royalties unless it is also configured on OpenSea).
Contract Enforced Royalties - Why they don’t work
One might posit, “well, couldn’t we just”:
modify the smart contract to force every transfer to also take in the funds for the sale
lock down the transfer and force the owner to check with us before any transfer
add in code that will pull back the NFT if we find someone didn’t pay royalties
You could do this, to force royalties to be paid out, but each proposal has a significant drawback.
Modifying the smart contract to force the transfer of funds through it
The major drawback of this approach is that it is easily bypassed while adding unnecessary complexity. You could bypass it by simply doing the following:
Perform the transfer/sale with a nominal amount of ETH (or other funds)
Perform final settlement with the full amount
The main reason this can be done is because the token smart contract has no way of validating what the agreed upon sales price is. The only time this could be true is if the pricing mechanism is built right into the logic itself (using something like a bonded curve), but that completely removes any price discovery and caps the value of the NFT.
Lock down the transfer function so that every transfer needs approval from the creator/artist
The major drawback of this is that it is an extremely heavyweight administrative problem, and very collector unfriendly. If anything were ever to happen to the approval process, the NFT is locked to a wallet forever. Any NFT’s implemented in this way would certainly take a significant value hit due to this risk.
Adding in the ability for the artist to recall the NFT
Again, similar to above, it reduces the permanence aspect of the NFT. The risk is that there is a disagreement between the artist/creator and the owner. In reality, to protect the artist’s brand, this would likely never be invoked (as it would set really bad precedent). There ARE a few examples of this however, most notably ENS (where the NFT is pulled back upon expiry). However, that is made known upfront: you are not buying the domain name, but rather renting it with a yearly renewal fee.
A Global Standard - Why it is good but insufficient
There has been a lot of movement to standardize the royalty specification. The idea is that a global standard would make the adherence to royalties easier for marketplaces. EIP-2981 is one such proposal, and in our opinion, it is a good one. It provides a good default and addresses the majority of use cases. But we do not think this is sufficient because:
It leaves old smart contracts and tokens out in the cold
Certain marketplaces may require royalty specifications that are a bit more complex than that specified (e.g. how royalties would be computed in bundled sales)
Manifold’s Proposal - A Community Owned and governed “Royalty Registry”
A preface to this section: based on our conversations with many marketplaces, we believe that every marketplace WANTS to collect and distribute royalties. Any primary marketplace certainly wants to ensure this happens to maintain their relationships with artists, and most secondary marketplaces also do primary sales. There is a mutual incentive to ensure that royalties are paid out, so we do not believe that poorly behaving marketplaces (i.e. ones that actively market as zero royalties and ignore royalty specifications) will gain significant traction. The issue isn’t enforcement, it is adoption and cross-platform compatibility.
We believe that creating a “Royalty Registry” which allows for easy and consistent way of looking up royalty information for any token will go a long way in ensuring that marketplaces and sellers will pay them. We have written a draft of what a royalty registry would look like here:
https://github.com/manifoldxyz/royalty-registry-solidity
It provides a common interface for any marketplace to look up the royalties for any NFT. It automatically supports any smart contracts coded to the EIP-2981, Rarible, Foundation or Manifold specs (and to some extent, Zora) without any additional configuration. It allows for any legacy smart contracts to add a royalty implementation.
We think that a lookup registry like this would go a long way in unifying royalties across marketplaces. No longer will you need to configure your smart contract on each marketplace to ensure royalties are set up.
From a governance standpoint, the best outcome would be that the major marketplaces come together and govern such a registry in a DAO like structure. You can think of this like ENS, but for royalty lookups. The governing body would be able to add new specs as necessary, and even increase the functionality of this registry to handle things like:
royalty payout logic
web3 application for lookups
splits configuration and deployment
It is our hope that the largest marketplaces and protocol developers in the space can come together to support this initiative.