Author: a16zcrypto
Translation: PlaidCat (ERC6551 Space)
Automatically enforced royalties on secondary sales have always been an important value proposition of NFTs. In an ideal world, creators can set royalties on-chain, and royalties are automatically paid whenever their work is sold anywhere on the Internet, without relying on the goodwill of the marketplace and other third parties to fulfill royalties.
However, NFT royalties have never actually been enforced on-chain; this has been misunderstood. The need for on-chain enforced royalties has outstripped progress toward achieving this goal. The challenge is that it is difficult to distinguish which NFT transfers are sales for which royalties should be paid, and which are other types of transfers, such as self-transfers between users' own wallets, sending NFTs as gifts, etc.
Newer royalty designs attempt to address this challenge by recognizing different types of transfers and enforcing royalties when appropriate — but these mechanisms present significant trade-offs between strict royalty enforcement (guaranteeing royalty payments) and composability (the ability of NFTs to interact with other on-chain applications).
Therefore, in this post, we discuss the pros and cons of existing NFT royalty designs and their balance between enforcing royalties and achieving composability. We then introduce two new NFT royalty approaches that leverage incentives to drive market participants to respect royalties. Our goal is not to advocate for a particular approach, but rather to help builders consider different NFT royalty designs and their associated tradeoffs.
First of all, what is composability?
Composability is one of the core features of open source software, allowing developers to combine, modify, and mix and match project fragments like Lego blocks to create interesting new applications without permission.
Applications can interact with NFTs in two basic ways — either reading (checking ownership) or writing (facilitating transfers):
Reading (checking ownership) means verifying blockchain data. Applications can interact with NFTs by verifying NFT ownership as a "gate" for further actions. For example, an NFT owner can claim another NFT, play a game, participate in a governance process, obtain a license to use NFT media content, or attend a conference or concert. In addition, people can use NFTs to associate on-chain data with their wallet addresses (for example, an NFT contains a username, and the owner of the NFT can use that username on social media).
Writing (facilitating transfers) represents updating the blockchain state. NFT transfers update the chain about who owns the NFT. In the simplest example, people can directly transfer NFTs to other wallets. Applications can also combine with this transfer functionality in one of the following ways: (1) transferring NFTs on behalf of the owner (e.g., in the case of an NFT marketplace) or (2) temporarily escrowing NFTs (e.g., non-OTC escrow, NFT rental agreements, or lending agreements that accept NFTs as collateral).
It’s important to distinguish between these different types of NFT composability. When we refer to “composability” in this article, we’re primarily referring to “write” or “transfer” composability.
While anyone can verify ownership of an NFT on a public blockchain, existing royalty designs restrict which wallets and smart contracts can perform transfers or own the NFT in the first place. Restricting "writes" could stifle opportunities to use NFTs for DeFi, gaming, shared ownership through multi-signatures, and even gifting to friends and applications where NFTs own other NFTs.
Now let’s break down the existing royalty solutions and weigh the pros and cons in more detail.
Existing solutions: blacklist and whitelist
A key reason why enforcing royalties is difficult is that it is difficult to distinguish which NFT transfers are sales - i.e. royalties should be paid - from other types of transfers. More specifically, because the default NFT standard implements the transfer function, the NFT smart contract has no way of knowing whether the transfer is related to the sale price. Existing solutions attempt to provide more context about the transfer on-chain by restricting transfers (i.e., is this transfer a sale? Or does it happen through a specific marketplace?).
The most popular designs for enforcing NFT royalties — blacklists and whitelists — employ different approaches to restricting transfers, and along with that, restrict the composability of “writes” or “transfers.”
Both designs revolve around preventing diversion on two levels:
1. Prevent diversion facilitated by marketplaces or applications that circumvent royalty payments.
2. Prevent transfers to certain account types: Externally Owned Accounts (EOA) (wallets that most people use today) vs. Smart Contract Accounts. In other words, there are certain restrictions on which types of accounts can own NFTs.
Therefore, regardless of which design a creator uses, they face a significant trade-off depending on how their NFT smart contract implements transfer "prevention": the more strictly the creator prevents transfer, the less composable the NFT will be .
blacklist
A blacklist is a list of specific smart contract addresses or applications that are not allowed to facilitate NFT transfers. Creators add the addresses of specific marketplaces or applications that do not honor royalties to a blacklist inside their NFT smart contract; if an NFT holder attempts to transfer their NFT through a blocked application, the transaction will fail. You can learn more about blacklists here.
Think of them as a firewall on your computer: you can browse the web freely, but the firewall blocks sites they deem unsafe. In this case, the "firewall" blocks applications that are known not to respect royalties.
advantage:
NFTs can be freely combined with most applications by default. This is because the blacklist takes an optimistic view that most applications will fulfill their royalties.
Creators can protect royalties instantly. Creators can shut down contracts that are detected to bypass royalties by adding them to a blacklist.
shortcoming:
Bad actors can bypass blacklists. Bad actors can always start a new market that is not on the blacklist that bypasses royalties.
Blacklists can’t proactively stop the circumvention of royalties—only reactively. New marketplaces can launch at any time. Creators are forced to play a cat-and-mouse game, monitoring which marketplaces are circumventing royalties and then adding them to blacklists.
The last point is the biggest challenge. To make the blacklist effective, creators need to constantly monitor new applications on the chain, track every possible new smart contract market, analyze it, and then decide whether to block it. This is hard work; even existing markets may need to be re-examined as they upgrade their smart contracts.
Blacklisting a royalty-circumventing app means missed payments. In addition, there is a “leaky bucket” problem: if even one royalty-circumventing market is not blocked, a disproportionate amount of transactions may flow to that market.
One potential solution is to delegate the management of the blacklist to a third party. However, this reintroduces reliance on an intermediary to help enforce royalties, gives that entity market power, and could have a variety of other consequences that are outside the scope of this article.
whitelist
The whitelist specifies the only smart contract addresses or applications that are allowed to facilitate NFT transfers. With this strategy, creators only allow those marketplaces or applications that guarantee royalty enforcement. NFT holders can only transfer their NFTs through smart contracts on the whitelist; if they try to transfer NFTs using a marketplace that is not on the whitelist, the transfer transaction will fail.
Existing whitelist designs also contain some optional components, such as: (1) restricting which types of wallets are allowed to own NFTs, usually only allowing externally owned accounts (EOA) rather than smart contract accounts; (2) restricting whether peer-to-peer (p2p) transfers are allowed.
advantage:
NFT transfers cannot be made through applications not on the whitelist, such as royalty-bypassing marketplaces. The whitelist only approves transfers facilitated by smart contracts that the creator knows honors royalties. All other marketplaces are blocked by default. Depending on how the whitelist and marketplace are implemented, NFT transfers can be difficult to make through royalty-bypassing marketplaces (see Disadvantages below).
Creators do not need to track and add new royalty-bypassing marketplaces as they would in blacklist mode. After a creator adds one or more royalty-fulfilling marketplaces to the whitelist, monitoring for new applications is less urgent.
shortcoming:
Creators need to approve every single application that wishes to facilitate the transfer of an NFT. Both blacklisting and whitelisting require some level of on-chain monitoring. With blacklisting, creators need to monitor applications that bypass royalties to avoid missing out on royalty payments. Whitelisting, on the other hand, imposes composability of licensing. Creators won’t miss out on royalty payments, but they may miss out on innovative new applications built around NFTs. Let’s say there is a developer who builds a unique NFT marketplace concept (that also enforces royalties!). That developer needs to contact the NFT creators, prove that they enforce royalties, and request to be added to the whitelist for each NFT. This is a high-friction process.
It may still be possible to bypass royalties, depending on how the marketplace is implemented and the restrictions that creators place on NFT transfers. For example, if NFTs are allowed to be sold for $0, it may still be possible to bypass royalty payments through whitelisted marketplaces. In this case, someone could build a market that bypasses royalties and facilitate $0 sales on the royalty-fulfilled marketplace, while transferring the actual payment on the side. Since the sale price is $0, the creator's royalty is $0 (i.e., a 5% royalty on $0 is $0).
Whitelists may be too restrictive. The most restrictive version of the whitelist also places restrictions on the types of wallets (EOA or smart contract accounts) that are allowed to own NFTs and peer-to-peer (p2p) transfers. Restricting smart contracts to own NFTs is intended to prevent NFT wrapping (see below), but in a world where everyone uses smart contract wallets, this may be too restrictive. Restricting p2p transfers means that any transfer must be made through a marketplace on the whitelist. The reason for this restriction is to prevent creators from missing out on royalties in over-the-counter (OTC) p2p sales. Restricting p2p transfers makes it difficult for NFT holders to transfer NFTs between their own wallets or directly between friends.
trade off
Both whitelists and blacklists introduce a tradeoff between strict royalty enforcement and open composability. The blacklist model enables open composability by default, but makes it easier to bypass royalties. With whitelists, it is easier to enforce royalties, but it greatly limits the applications that NFTs can interact with.
This trade-off is more than just a blacklist vs. whitelist: any approach that limits the applications and operations with which NFTs can interact will limit the composability and functionality of the NFTs.
Improved technical approaches may reduce the magnitude of this trade-off. But the fundamental problem remains.
Exploring a new framework for NFT royalties
Creators are still testing whitelists, but as more NFT use cases emerge, it will be worth exploring the boundaries beyond the blacklist/whitelist model to improve the tradeoff between royalty enforcement and composability.
The strategy we explore here slightly reframes the problem and existing royalty mechanisms through the lens of incentive design: our goal is to introduce incentives that push NFT markets and/or consumers to actively choose to respect royalties. This offers the possibility of allowing more composability in principle.
We show two different approaches below. The first mechanism improves on the whitelist model to make it more open, more composable, and more encouraging of permissionless innovation based on NFT. The second mechanism, which we call “recycling rights,” provides consumers with strong incentives to use royalty-respecting marketplaces when selling NFTs, thereby maintaining open composability while still achieving significant of royalty payments.
Our goal is not to suggest a single “solution” but to expand the range of options: How can we ensure that creators receive more royalties without limiting composability or relying entirely on goodwill?
Method 1: Combining the whitelist with the staking mechanism
We can extend the existing whitelist model with a staking mechanism to enable marketplaces and other applications to obtain whitelist membership in a permissionless manner.
Currently, creators must manually add marketplaces or apps to their whitelists, and third-party developers must request permission from the creator to be added. This slows innovation and adoption of new apps, and puts the onus on creators to audit new apps to ensure they enforce royalties. Delegating the management of whitelists to third parties could also slow down the process.
Introducing a staking model for whitelist membership would allow new applications to pledge funds or other resources as a guarantee of a commitment to enforce royalties ("optimistically" meaning trust and then verify, rather than assuming malicious actors). By default, NFT holders can immediately interact with new applications that provide appropriate staking; if an application misbehaves, the creator can slash the staking and remove it from the whitelist. We can even imagine a hybrid model where if an application proves its honesty over time, the creator can formally add it to the whitelist and refund the staking.
There are some unresolved issues with this design approach. We list them here so that others can share further thoughts and research.
How can creators implement arbitration for stake slashing? The criteria for stake slashing — whether royalties were paid — can be challenging to detect and prove on-chain. Application developers need to trust that creators will not slash their stake when they shouldn’t be slashed and remove them from the whitelist.
Who should get the slashed stake? On the one hand, giving the slashed stake to the creators could be a way to partially compensate them for the royalties they lose by triggering the slashing event. But if the slashed stake does not go to the creators, the creators have no incentive to slash maliciously. Inspiration can be found in Ethereum's EIP-1559 transaction fee mechanism, where the base fee of the transaction is destroyed instead of sent to the validator.
What should the size of the stake be? The value of the stake needs to have some relationship to the amount of royalties that the application is likely to generate for a given creator. Smaller stake amounts may be appropriate for less popular or niche applications. However, marketplaces that facilitate large volumes of NFT sales will need to offer more stakes, and the level of stake may need to increase incrementally as the value of the collection and trading volume increases.
Do we need to aggregate stakes across multiple NFTs? If so, how? Developers may need to stake resources for each individual NFT collection they want to combine, which is a significant burden. However, if developers stake a collection and prove their honest behavior, this may reduce the burden on other NFT creators to add new applications to their whitelists. Similarly, we can imagine a strategy where the market uses a large number of single stakes to promise royalties across a wide range of collections.
Method 2: Mechanisms that allow for “reclaiming rights”
Reclaim Rights is a new approach that transcends the tradeoff between execution and composability (and blacklisting/whitelisting) by creating incentives to encourage the payment of royalties every time an NFT is sold. At the heart of this strategy is a refinement of the definition of “owning” an NFT on-chain.
Each NFT has two possible different owners of record, which we call the asset owner and the title owner:
The asset owner is the wallet that holds the NFT (what we usually call “owner” today);
The title owner is the last wallet to pay royalties (or title transfer fees, see below) to the NFT creator.
This design approach helps ensure that creators receive more royalties without limiting composability.
Reclaim right mechanism
If the asset owner and the ownership owner of the NFT are different, that is, if the asset owner's wallet is different from the ownership owner's wallet, then the ownership owner can recycle the NFT back to their wallet at any time. The asset owner can become the ownership owner by paying the ownership transfer fee to the creator, thereby eliminating this "recycling risk".
Reclaim rights are not leases, but they have similarities to leasing NFTs. For example, ERC-4907 is a "lease NFT" standard, which also has the concept of two "owners".
For simplicity, we assume that the only way ownership can be transferred is by paying a transfer fee. However, in practice, there may be other mechanisms for transferring ownership, such as automatically transferring ownership after a long enough period of time, or designing a mechanism that allows creators to directly trigger the transfer of ownership to the current asset owner.
In this model, title transfer fees become the new "royalties"; markets that respect royalties will bundle the payment of title transfer fees into sales transactions. Note that this means that royalties are no longer directly tied to the sales price; title transfer fees are fixed fees, in contrast to the "percentage of sales price" fees that have historically been used for NFT royalties. However, creators can choose to update title transfer fees over time.
The risk of the owner reclaiming the NFT helps distinguish which NFT transfers are sales (royalties should be paid) from which transfers are not through human behavior. Specifically, this new ownership model incentivizes the payment of royalties (i.e., ownership transfer fees) for NFT transfers between buyers and sellers, because otherwise the seller can reclaim the NFT immediately after "selling" the NFT and receiving the payment.
At the same time, this framework allows free transfers between personal wallets or as gifts.
Let's look at how this works in practice with a few transfer examples:
1. If I transfer the NFT to my own personal wallet**, only the ownership of the asset will be transferred to the new wallet, my original wallet will still be the owner of the ownership, but I will not have the risk of recovery from myself.
2. If I transfer an NFT to a friend as a gift**, only the ownership of the asset will be transferred, and I will retain ownership. My friend can use it as he pleases (including selling it; we discuss how the market should handle this below), and can rely on social trust that I will not recycle the NFT. If my friend wants full ownership, they can always pay the ownership transfer fee to the creator. Alternatively, I can pay the ownership transfer fee when sending the gift NFT.
3. If I sell through the marketplace or do an OTC transaction outside the marketplace (e.g., you give me 100 USDC and I transfer the NFT directly to you)**, the buyer is strongly incentivized to pay the title transfer fee to eliminate the risk of me recovering the NFT after I get the buyer's money.
Do markets need to change the way they work to accommodate this model?
In principle, no. However, redemption rights mean that any NFT purchased on the marketplace is subject to redemption risk, which is a bad user experience - the buyer's NFT will be recycled over and over again! A better strategy would be for the marketplace to bundle payment of a transfer fee with the purchase of an NFT, thereby transferring ownership to the new buyer at the same time the sale occurs. With this model, supporting royalty payments goes hand in hand with ensuring a better marketplace experience.
Neither the redemption rights mechanism nor the allowlist and blocklist mechanisms can prevent royalty circumvention through wrapping of NFTs — unless you prohibit all smart contracts from holding NFTs, which is very limiting (especially given the growth of account abstraction).
Under the redemption rights mechanism, the packaging contract must pay a transfer fee to obtain ownership and thus become a legal packaging NFT. This actually becomes an exit fee, the price of leaving the NFT ecosystem. In addition, if a popular packaging contract appears, it is easy to identify the contract on the chain.
Any NFT whose ownership is deemed to be a malicious wrapper contract can be blocked by the NFT creator from participating in the NFT's ecosystem, community activities, or other related utilities. If a wrapper contract is identified and blocked from the community, and an NFT owner wants to "re-enter" the ecosystem, they can pay a fee to transfer ownership away from the wrapper contract as a re-entry fee.
More broadly, it could be beneficial to reveal information about whether the owner of an asset is also the owner of the title. Reducing access to non-ownership owners throughout the ecosystem could become a significant incentive for NFT purchasers to pay royalties. For example, a marketplace or wallet that prominently displays NFTs for which royalties/ownership transfer fees have not been paid may push consumers to choose to pay royalties.
Assumptions
The right-to-recovery framework relies on two key assumptions:
1. Creators accept that transfer fees become “royalties” and that royalties are no longer a direct percentage of the sales price.
2. Creators accept the possibility that their NFTs may be wrapped to circumvent royalties (knowing that there are still exit and re-entry fees), and can easily identify and block community access to wrapped NFTs.
If creators don’t accept these assumptions, then the right to reclaim design cannot exist on its own. There are other features and components that relax these assumptions, and we hope to expand on these in the future—and we hope others in the community will expand on these as we collectively work to solve this important problem.
We also recognize that redemption rights deviate from the existing NFT ownership mentality. However, NFTs with similar ownership structures already exist today (such as ENS, which has registrants and controllers).
Conclusion
When designing NFT royalty solutions, we believe the entire industry is working toward the same goals: maintaining composability, safeguarding digital property rights, and ensuring creators are fairly compensated for producing great work.
As more NFT use cases emerge—from collectibles to digi-fizzy—there is no one-size-fits-all solution. Every creator (and every NFT) is different. Builders and creators should have an easy way to understand the various royalty designs and their tradeoffs to choose the one that best meets their unique goals. The more we expand the design space, the better.
The industry has the power to significantly improve the way creators make a living from their work, and perhaps, the best is yet to come. Royalty enforcement models are new and many people are still trying them. If you have any novel ideas after reading this article, please share them with us!