Automatically enforced royalties on secondary sales have always been an important value proposition for NFTs. In an ideal world, creators could set royalties onchain that would be paid automatically whenever their work is sold anywhere on the internet, and without relying on marketplaces and other third parties to honor royalties out of goodwill.

However, NFT royalties were never actually enforced onchain; this has always been misunderstood. The demand for enforced onchain royalties outpaced progress toward making them a reality. The challenge is that it’s difficult to distinguish between the NFT transfers that are sales that should pay a royalty and other types of transfers, such as self-transfers between a user’s own wallets, sending an NFT as a gift, and so forth.

Newer royalty designs attempt to address this challenge by identifying different types of transfers and enforcing royalties when appropriate — but these mechanisms come with a significant tradeoff between strict royalty enforcement (guaranteed royalty payments) and composability (how much an NFT can interact with other applications onchain).

So in this post, we discuss the pros and cons of existing NFT royalty designs, and how they balance between enforcing royalties and enabling composability. We then introduce two new approaches to NFT royalties that leverage incentive mechanisms to drive market participants to respect royalties. Our goal is not to advocate for a particular approach, but to help builders consider different NFT royalty designs and associated tradeoffs.

But first, what is ‘composability’?

Composability is a core feature of open source software that allows developers to permissionlessly combine, mod, and remix pieces of projects like “lego bricks” to create interesting new applications.

There are two fundamental ways an application can compose with an NFT — either by reading (checking ownership) or writing (facilitating transfers):

• Reading (checking ownership) means validating blockchain data. An application can compose with an NFT by verifying ownership of the NFT as a “gate” to further actions. For example, owners of an NFT could get access to claim another NFT, play a game, vote in a governance process, acquire a license to use the NFT’s media contents, or attend a conference or concert. Also, people can use NFTs to associate onchain data with their wallet addresses (e.g., the NFT contains a username and the person that owns it has that username on social media).
• Writing (facilitating transfers) means updating blockchain state. An NFT transfer updates who owns the NFT onchain. In the most simple case, people can directly transfer NFTs to other wallets. Applications can also compose with this transfer functionality either by (1) transferring an NFT on an owner’s behalf (e.g., in the context of an NFT marketplace) or (2) taking custody of the NFT for a period of time (e.g., an escrow for an OTC transaction, an NFT renting protocol, or a lending protocol that accepts NFTs as collateral).

The distinction between these different types of NFT composability is important. When we refer to “composability” in this post, we are primarily referring to “writing” or “transfer” composability.

While anyone can verify ownership of an NFT on a public blockchain, existing royalty designs restrict which wallets and smart contracts are allowed to execute a transfer or own the NFT in the first place. Restricting “writing” can shut down opportunities to use NFTs in DeFi, games, shared ownership through a multi-sig, or even gifts to friends, as well as applications where NFTs own other NFTs.

Now let’s break down the existing royalty solutions and tradeoffs in more detail.

Existing solutions: blocklists and allowlists

One key reason why enforcing royalties is hard is because it is difficult to distinguish between the NFT transfers that are sales — and that should pay a royalty — and other types of transfers. More specifically, because of the way default NFT standards implement transfer functionality, NFT smart contracts have no idea if there is a sale price associated with a transfer. Existing solutions attempt to provide more context around transfers onchain (i.e., is this transfer a sale or not? Or did it occur through a particular marketplace?) by restricting transfers.

The most popular designs for enforcing NFT royalties, blocklists and allowlists, take different approaches to restricting transfers and, along with them, “write” or “transfer” composability.

Both designs revolve around preventing transfers at two levels:

1. Preventing transfers facilitated by marketplaces or applications that circumvent royalty payments.
2. Preventing transfers to certain account types: externally owned accounts or EOAs (wallets as most people use them today) vs. smart contract accounts. In other words, there are restrictions on which types of accounts are allowed to own an NFT.

So creators face a significant tradeoff no matter which design they use, depending on how their NFT smart contract implements transfer “preventions”: The more strictly the creator prevents transfers, the less composable the NFT.

Blocklists

A blocklist is a list of specific smart contract addresses or applications that are not allowed to facilitate an NFT transfer. Creators add the addresses of specific marketplaces or applications that do not honor royalties to a blocklist inside their NFT smart contract; and if an NFT owner tries to transfer their NFT via a blocked application, the transaction will fail. You can learn more about blocklists here.

Think of a them like a firewall on your computer: You can freely roam the web, but firewalls will block websites that they consider unsafe. Here, the “firewall” blocks applications that are known not to respect royalties.

Pros

• The NFT is freely composable with most applications by default. This is because blocklists take an optimistic view that most applications honor royalties.
• Creators can instantly protect royalties. The creator can shut down any contract that they detect as circumventing royalties by adding it to the blocklist.

Cons

• Bad actors can get around blocklists. Bad actors can always spin up a new royalty-circumventing marketplace not on the blocklist.
• A blocklist cannot stop royalty circumvention proactively — only reactively. New marketplaces can be spun up at any time. Creators are forced to play the cat-and-mouse game of monitoring which marketplaces are circumventing royalties, and then add them to the blocklist.

The last bullet represents the biggest challenge. In order for blocklists to be effective, creators need to constantly monitor new applications onchain, keeping track of every possible new smart contract marketplace, analyzing it, and then deciding whether to block it. This is hard work; and even existing marketplaces may need to be re-examined over time as they upgrade their smart contracts.

Leaving a royalty-circumventing application off the blocklist means missing out on payments. Moreover, there’s a “leaky bucket” problem: If even one royalty-circumventing marketplace is left unblocked, it’s possible a disproportionate share of transactions flow to that marketplace in equilibrium.

One potential solution is to delegate blocklist curation to a third party. However, this reintroduces reliance on an intermediary to help enforce royalties, gives that entity market power, and could have various other consequences outside the scope of this post.

Allowlists

Allowlists explicitly specify the only smart contract addresses or applications allowed to facilitate an NFT transfer. With this strategy, creators only allow marketplaces or applications that guarantee royalty enforcement. An NFT owner can only transfer their NFT via an allowlisted smart contract; if they try to transfer the NFT using a marketplace that’s not on the allowlist, the transfer transaction will fail.

Existing allowlist designs also contain optional components such as: (1) restrictions on which types of wallets are allowed to own an NFT, often permitting just EOAs rather than smart contract accounts; and (2) restrictions on whether peer-to-peer transfers are allowed.

Pros

• NFT transfers cannot occur through applications that are not on the allowlist, such as royalty-circumventing marketplaces. The allowlist only approves transfers facilitated by smart contracts that the creator knows honor royalties. Every other marketplace is blocked by default. It would be challenging for NFT transfers to occur through royalty-circumventing marketplaces, depending on how the allowlist and marketplace are implemented (see cons below).
• Creators don’t need to track and add new royalty-circumventing marketplaces, as in the blocklist model. There is less urgency around monitoring new applications after a creator has added one or more royalty-honoring marketplaces to their allowlist.

Cons

• Creators need to approve all individual applications that want to facilitate an NFT transfer. Both the blocklist and allowlist require some level of onchain monitoring. With a blocklist, creators need to monitor for royalty-circumventing applications so they will not miss out on royalty payments. Allowlists, on the other hand, impose permissioned composability. Creators won’t miss out on royalty payments, but they can miss out on innovative new applications built around NFTs in general. Let’s say there is a developer who builds a unique marketplace concept for NFTs (that also enforces royalties!). That developer would need to reach out to NFT creators, prove that they honor royalties, and ask permission to get added to each NFT’s allowlist. This is a high-friction process.
• There are still ways to circumvent royalties, depending on how a marketplace is implemented and what restrictions creators place on NFT transfers. For example, it may still be possible to circumvent a royalty payment through allowlisted/royalty-honoring marketplaces if they permit an NFT to sell for $0. In this case, someone could build a royalty-circumventing marketplace on top of the royalty-honoring marketplace, and facilitate $0 sales on the royalty-honoring marketplace while transferring the actual payment on the side. Since the sale would be $0, the royalty to the creator would be $0 (i.e., a 5% royalty of $0 is $0).
• Allowlists can be overly restrictive. The strictest version of an allowlist also comes with restrictions around which types of wallets are allowed to own the NFT (EOAs or smart contract accounts) and around peer-to-peer (p2p) transfers. Restricting smart contracts from owning an NFT is meant to defend against NFT wrapping (discussed below) and can be overly restrictive in a world where everyone is using smart contract wallets. Restricting p2p transfers means that anytime there is a transfer, it must flow through an allowlisted marketplace. The reason for this restriction is to prevent OTC (over-the-counter) p2p sales where the creator would miss out on a royalty. Restricting p2p transfers makes it challenging for NFT owners to transfer NFTs among their own wallets or directly between friends.

The tradeoff

Both allowlists and blocklists introduce a tradeoff between strict royalty enforcement and open composability. The blocklist model enables open composability by default, but it is easier to circumvent royalties. With an allowlist, it is easier to enforce royalties, but you substantially limit which applications an NFT can interact with.

And this tradeoff isn’t just about blocklists vs. allowlists: Any way that we permission which apps and operations an NFT can interact with will limit the composability and the functionality of the NFT.

It’s possible that improved technical approaches can reduce the degree of tradeoff. But the fundamental issue remains.

Exploring new frameworks for NFT royalties

Creators are still battle-testing allowlists, but as more use cases for NFTs arise, it’s worth exploring beyond the bounds of the blocklist/allowlist model to improve the tradeoff between royalty enforcement vs. composability.

The strategies we explore here slightly reframe both the problem and existing royalty mechanisms through the lens of incentive design: We aim to introduce incentives that drive NFT marketplaces and/or consumers to actively choose to respect royalties. This offers the possibility of allowing more composability in principle.

We illustrate two different ways this can work below. The first mechanism builds on the allowlist model in a way that’s more open, more composable, and more encouraging of permissionless innovation on top of NFTs. The second mechanism, which we call “right of reclaim,” provides consumers with a strong incentive to use royalty-respecting marketplaces whenever they sell NFTs, making it possible to maintain open composability while still enabling a significant degree of royalty payment.

Our goal is not to suggest a single “solution,” but rather to expand the set of options: How can we ensure creators get more royalties in a way that doesn’t restrict composability and rely solely on goodwill?

Approach 1: A mechanism for combining an allowlist with staking

We can expand the existing allowlist model with a staking mechanism that enables marketplaces and other applications to permissionlessly acquire allowlist membership.

Today, a creator has to manually add marketplaces or applications to their allowlist, and third-party developers have to ask the creator for permission to be added. This can slow new application innovation and adoption, and it puts the responsibility on the creator to vet new applications to ensure they enforce royalties. Delegating allowlist curation to a third party may likewise slow down the process.

Introducing a staking model for allowlist membership would permit new applications to optimistically add themselves to the allowlist by staking money or other resources as a commitment to enforce royalties (“optimistically” as in trust then verify, as opposed to assuming bad actors). By default, NFT owners could then immediately interact with new applications as soon as they provide an appropriate stake; and if an application misbehaves, the creator can slash the stake and remove the application from the allowlist. We might even imagine a hybrid model where, if an application proves honest over time, the creator could officially add the application to the allowlist and return the stake.

There are a few open questions with this design approach. We outline them here so that others can share further thinking and research.

How would creators implement the arbitration of slashing? The criteria for slashing — which is whether royalties are enforced — can be challenging to detect and prove onchain. Application developers need to trust that the creator would not slash their stake and remove them from the allowlist when slashing is not deserved.

Who should get the slashed stake? On the one hand, giving slashed stake to the creator may be a way to partially compensate them for the royalty circumvention that triggers the slashing event. But if slashed stakes do not go to the creator, creators are less incentivized to slash maliciously. There could be inspiration in the EIP-1559 transaction fee mechanism on Ethereum, where the transaction base fee is burned rather than sent to validators.

What should the size of the stake be? The value of the stake would need to have some relation to the amount of royalties an application may produce for a given creator. A small stake size might work for less popular or niche applications. However, marketplaces that facilitate a large volume of NFT sales would need to put up more stake, and it’s possible that the level of stake would need to scale over time with both collection value and transaction volume.

Do we need to aggregate stake across multiple NFTs? If so, how? Developers may need to stake resources to every individual NFT collection they want to compose with, which is a prohibitively large burden. However, if the developer stakes to one collection and proves to be honest, it could lower the burden for other NFT creators to add the new application to their allowlists. Similarly, we might imagine a strategy where a marketplace uses a large, single stake to commit to enforce royalties on a wide range of collections.

Approach 2: A mechanism for allowing ‘right of reclaim’

Right of reclaim is a new approach that moves beyond the enforcement vs. composability tradeoff (and beyond blocklists/allowlists) by using incentives to encourage royalty payments whenever an NFT sale occurs — without restricting permissionless composability. The core of the strategy is a refinement of what it means to “own” an NFT onchain.

Every NFT has two potentially different owners of record, which we refer to as the asset owner and title owner:

• An asset owner is the wallet that holds an NFT (the wallet we generally refer to as the “owner” today);
• A title owner is the last wallet to pay a royalty to the NFT creator (or title transfer fee, defined below).

With the right of reclaim mechanism, if the asset and title owner of an NFT differ — that is, if the asset owner wallet is different from the title owner wallet — then the title owner can always reclaim the NFT to their wallet at any time. The asset owner can remove this “reclaim risk” by paying a title transfer fee to the creator to become the title owner.

Right of reclaim is not renting, but there are similarities to renting NFTs. For example, ERC-4907 is a “rental NFT” standard that also has a notion that an NFT has two “owners.”

For simplicity, we assume that the only way to transfer title ownership involves money through a title transfer fee. But in practice, there could be other mechanisms for title transfer — such as the title transferring automatically after a sufficiently long time period, or designing a mechanism for the creator to directly trigger a title transfer to the current asset owner.

In this model, the title transfer fee becomes the new “royalty”; and royalty-respecting marketplaces would bundle paying the title transfer fee into a sale transaction. Note that this means royalties would no longer be a direct function of the sale price; the title transfer fee is a fixed fee, in contrast to the variable “percentage of sale price” fees used for NFT royalties historically. That said, the creator could optionally update the title transfer fee over time.

The risk of the title owner reclaiming the NFT helps differentiate through people’s behavior between which NFT transfers are sales (and should pay a royalty) and which transfers are not. Specifically, this new ownership model incentivizes NFT transfers that involve a sale between counterparties to pay a royalty (i.e., a title transfer fee) because otherwise the seller could reclaim the NFT immediately after “selling” it and collecting payment.

At the same time, this framework permits free transfers between personal wallets or transfers as gifts.

Let’s walk through a few transfer examples to see how this plays out in practice:

• If I transfer an NFT to my own personal wallet… only asset ownership will transfer to the new wallet and my original wallet is still the title owner, but there is no risk of me reclaiming it from myself.
• If I transfer the NFT to a friend as a gift… only asset ownership will transfer, and I will retain title ownership. My friend can use it however they choose (including selling it; we discuss how marketplaces should handle this below) and can rely on social trust that I won’t reclaim the NFT. If my friend wants full title ownership, they can pay the title transfer fee to the creator at any time. Alternatively, I can pay the title transfer fee when I send the gift NFT in the first place.
• If I transfer the NFT via a marketplace sale or an over-the-counter (OTC) transaction outside a marketplace (e.g., I will transfer you the NFT directly if you give me 100 USDC)… the buyer is strongly incentivized to pay the title transfer fee to remove the risk that I reclaim the NFT after taking the buyer’s money.

Would marketplaces have to change how they work to adapt to this model?

In principle, not at all. However, right of reclaim means that any NFT purchased on a marketplace has reclaim risk, which is a bad user experience — buyers’ NFTs would be reclaimed left and right! A better strategy would be for marketplaces to bundle the purchase of an NFT with paying the title transfer fee, thereby transferring title ownership to the new buyer at the same time that the sale occurs. With this model, supporting royalty payments would go hand-in-hand with ensuring a better marketplace experience.

Neither the right of reclaim nor the allowlist and blocklist mechanisms prevent NFTs from being wrapped to circumvent a royalty — unless you prevent all smart contracts from owning the NFT, which is very restrictive (especially given the growth of account abstraction).

With right of reclaim, the wrapper contract must pay a title transfer fee to gain title ownership to make a legitimate wrapped NFT. This effectively becomes an exit fee, a price to leave the NFT’s ecosystem. Additionally, if a popular wrapper contract arises, it is easy to identify that contract onchain.

Any NFT whose title owner is known to be a malicious wrapper contract can be blocked by the NFT creator from participating in the NFT’s ecosystem, community events, or other associated utilities. Suppose a wrapper contract is identified and blocked from the community, and an NFT owner wants to “re-enter” the ecosystem. In that case, they can pay to transfer title ownership away from the wrapper contract as a re-entry fee.

More broadly, there may be benefits to surfacing information about whether the asset owner is also the title owner. Degrading access to non-title owners throughout the ecosystem may serve as a significant incentive for NFT purchasers to pay royalties. For example, marketplaces or wallets that prominently display NFTs with unpaid royalty/title transfer fees could drive consumers to opt into paying a royalty.

Assumptions

The right of reclaim framework relies on two key assumptions:

1. Creators are okay with the title transfer fee becoming the “royalty,” with royalties no longer being a direct percentage of the sale price.
2. Creators are okay with the possibility that their NFTs may be wrapped to circumvent royalties (with the knowledge that there is still an exit and re-entry fee as described above), and you can easily identify and block community access to wrapped NFTs.

[Note: None of the models discussed (blocklists, allowlists, right of reclaim) effectively prevent NFT wrapping unless you prevent all smart contracts from owning an NFT. There are certainly non-malicious forms of wrapping such as bridging an NFT to a different blockchain. However, NFT bridging is a complex topic outside the scope of this post.]

If creators are not okay with these assumptions, then the right of reclaim design can’t exist in isolation. There are a few other features and components that can be put in place to relax these assumptions, which we hope to expand on in the future — and which we hope others in the community can expand on as we collectively try to work on this important problem.

We also recognize that the right of reclaim departs from existing mental models around NFT ownership. That said, there are already NFTs that exist today that have similar ownership structures (such as ENS with a registrant and controller).

— \
When designing an NFT royalty solution, we believe we are all working toward the same goals as an industry: Preserving composability, maintaining digital property rights, and ensuring creators receive fair compensation for making amazing things.

As more use cases for NFTs arise — 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, in order to choose the one that fits their unique goals. The more we can expand the design space, the better.

This industry has the power to dramatically improve how creators earn a living from their work and, maybe, the best approaches are yet to come. Royalty enforcement models are new, and many are still experimenting with them. If you have any novel ideas after reading this post, please share them with us!

Disclaimer：

1. This article is reprinted from [a16zcrypto]. All copyrights belong to the original author [ Michael BlauScott, Duke Kominers, Daren Matsuoka]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.