NFT royalties: navigating the complexities of enforcement, composability, and future innovations

When NFTs first emerged, one of their key attractions was the prospect of receiving royalties from every subsequent sale of an NFT. Imagine a world where creators could set a royalty fee on the blockchain and receive a cut every time their art or digital collectible changed hands online. There would be no more reliance on platforms or buyers to be honest – it would just happen.

Here’s the catch: This “automatic enforcement” was largely a misconception. NFT royalties were never actually enforced on the blockchain itself. While demand for this feature grew rapidly, technology struggled to keep up. The core problem is that it is very difficult for the blockchain to distinguish between a genuine sale, where a royalty should be paid, and other types of transfer, such as moving an NFT between wallets, sending it as a gift or using it for another purpose.

Newer approaches to royalties are trying to tackle this by figuring out how to identify different types of transfers and only trigger royalties when it makes sense. However, these solutions often involve a tricky balancing act: the more strictly you enforce royalties, the more you might limit “composability.”

So, what exactly is “composability” in this context?

Understanding composability: NFTs as digital Lego bricks

Think of composability like digital Lego bricks. It’s a fundamental idea in open-source software where developers can freely combine, modify, and remix different pieces of projects to build new, exciting applications. With NFTs, composability means how easily and permissionless an NFT can be used or interacted with by other applications on the blockchain.

There are two main ways an application can “compose” with an NFT:

1. Reading (checking ownership): This is about an application verifying who owns an NFT. For example, if you own a specific NFT, you might get access to a special online event, unlock features in a game, get to vote in a community decision, or even claim another unique NFT. It’s like your NFT acts as a digital key or a membership card. People can also use NFTs to link specific data to their wallet addresses, like a unique username on social media.
2. Writing (facilitating transfers): This involves actually changing who owns the NFT on the blockchain. The simplest form is just sending an NFT from one wallet to another. But applications can also get involved in transfers. This could mean a marketplace automatically transferring an NFT on your behalf when you sell it, or a platform temporarily holding your NFT (like an escrow for a private sale, a rental service, or even using your NFT as collateral for a loan).

When we talk about “composability” in this discussion, we’re mostly focused on this “writing” or “transfer” aspect.

While anyone can easily check who owns an NFT on a public blockchain, many existing royalty designs try to control who or what kind of smart contract is allowed to transfer or even own the NFT in the first place. Restricting these “writing” capabilities can accidentally block NFTs from being used in cool new ways, like in decentralized finance (DeFi), gaming, shared ownership models (where multiple people control one NFT), or even simple gift-giving.

Now, let’s break down the current royalty solutions and their trade-offs in more detail.

Current solutions: blocklists and allowlists

The main reason it’s so hard to enforce royalties is that NFT smart contracts, by default, don’t know if a transfer is part of a sale or just a regular transfer. They don’t have information about a “sale price.” Existing solutions try to get around this by limiting how NFTs can be transferred.

The two most common ways to enforce NFT royalties are blocklists and allowlists. Both try to prevent transfers facilitated by marketplaces or applications that don’t pay royalties, and sometimes they even restrict who (or what kind of wallet) can own an NFT.

Here’s the critical point for creators: the stricter the rules they put on NFT transfers, the less “composable” their NFT becomes. It’s a constant compromise.

Blocklists: the “firewall” approach

Imagine a blocklist as a digital ‘blacklist’ of smart contract addresses or applications that are prohibited from facilitating NFT transfers. Creators add the addresses of marketplaces that do not honor royalties to this list. If an NFT owner tries to transfer their NFT through one of these blocked applications, the transaction simply fails.

Think of it like a firewall on your computer. While you can browse most of the internet freely, the firewall steps in and blocks access to websites it deems unsafe. In this case, the ‘firewall’ blocks applications that are known not to pay royalties.

Pros:

• Default Composability: By default, NFTs are highly composable with most applications because blocklists assume most apps will honor royalties.
• Quick Protection: Creators can quickly block any contract they discover is bypassing royalties.

Cons:

• Easy to Circumvent: Con artists can easily create new marketplaces that aren’t on the blocklist, bypassing the restrictions.
• Reactive, Not Proactive: Blocklists can’t stop royalty circumvention before it happens. Creators are stuck in a “whack-a-mole” game, constantly monitoring for new non-compliant marketplaces and adding them to the list. This is a huge, ongoing task, and even existing marketplaces might update their contracts, requiring re-evaluation.
• “Leaky Bucket” Problem: If even one major royalty-skipping marketplace isn’t blocked, it can siphon away a large chunk of transactions, costing creators significant royalty payments.

Delegating blocklist management to a third party is a possibility, but it reintroduces reliance on an intermediary, which can have its own complications.

Allowlists: the “permissioned access” approach

Allowlists are the opposite of blocklists. They explicitly list the only smart contract addresses or applications that are allowed to facilitate an NFT transfer. Creators using this strategy only permit marketplaces that guarantee royalty enforcement. If an NFT owner tries to transfer their NFT through a marketplace not on this approved list, the transaction fails.

Some allowlist designs also include extra restrictions, like only allowing regular user wallets (EOAs) to own NFTs, or even limiting peer-to-peer transfers.

Pros:

• Stronger Royalty Enforcement: Since only approved applications can facilitate transfers, it’s much harder for NFTs to be sold through royalty-circumventing marketplaces. Any marketplace that’s not explicitly approved is blocked by default.
• Less Monitoring for Creators (Potentially): Creators don’t need to constantly hunt for new royalty-skipping marketplaces like with blocklists. Once they’ve approved a few trusted platforms, the urgency to monitor for new con artists decreases.

Cons:

• High Friction for New Applications: Creators have to manually approve every single application that wants to facilitate NFT transfers. If a brilliant new marketplace emerges (that does honor royalties!), its developers would have to go to every single NFT creator, prove their compliance, and ask to be added to the allowlist. This slows down innovation.
• Still Possible to Circumvent (Subtly): Depending on how marketplaces are implemented, it might still be possible to bypass royalties. For instance, if an allowed marketplace permits $0 sales, someone could build a platform on top of it that facilitates “free” sales through the approved marketplace while handling the actual payment off-chain. Since the “sale” on the approved platform is $0, the royalty would also be $0.
• Overly Restrictive: The strictest allowlists can severely limit how NFTs can be used. Restricting smart contracts from owning NFTs can be problematic as smart contract wallets become more common. Restricting peer-to-peer transfers means all transfers must go through an approved marketplace, making it difficult to simply send an NFT to a friend or between your own wallets.

The core trade-off

Both blocklists and allowlists force creators to compromise. Blocklists offer more freedom and composability by default, but they can be easily circumvented. Allowlists make royalty enforcement easier, but they also significantly restrict what you can do with your NFT.

However, this isn’t just about blocklists versus allowlists. Any method that attempts to control the applications and operations with which an NFT can interact will necessarily limit its flexibility and functionality. While technical improvements might reduce the impact of this trade-off, the fundamental tension remains.

Exploring new frameworks for NFT royalties

Creators are still experimenting with allowlists, but as NFTs find more and more uses, it’s worth looking beyond the current models to improve that tough trade-off between royalty enforcement and composability.

Our focus here shifts to incentive design. Instead of trying to force royalty payments, what if we could incentivize marketplaces and consumers to choose to respect them? This approach could potentially allow for much more composability.

Here are two new ideas that leverage incentives:

Approach 1: combining allowlists with staking

This idea builds on the existing allowlist model, making it more open and flexible, and more welcoming of new innovations.

Currently, creators must manually add applications to their allowlists. This process is slow and places a significant burden on creators, who must vet every new app. However, with a staking model for allowlist membership, new applications could add themselves permissionlessly to an allowlist by providing a certain amount of money or other resources as a ‘deposit’ – demonstrating their commitment to enforcing royalties.

This would enable NFT owners to immediately use these new applications. If an application misbehaves by not paying royalties, the creator could ‘slash’ their staked deposit and remove them from the allowlist. We could even envisage a hybrid system in which, if an application proves itself over time, the creator officially adds it and returns its stake.

Open Questions with This Design:

• How to arbitrate slashing? Deciding whether royalties were truly circumvented can be hard to prove on-chain. Developers would need to trust that creators won’t unfairly “slash” their stake.
• Who gets the slashed stake? Should the creator get it (as partial compensation for lost royalties), or should it be “burned” (like Ethereum’s fee burning) to prevent creators from maliciously slashing for profit?
• What’s the right stake size? The stake would need to relate to the potential royalties an app might generate. Popular marketplaces might need to put up much larger stakes.
• Aggregating stake across NFTs? Would developers need to stake for every single NFT collection they want to work with? That would be impractical. Perhaps one large stake could cover many collections, or an app proving itself with one collection could make it easier to gain trust with others.

Approach 2: the “right of reclaim” mechanism

This approach aims to move past the enforcement vs. composability trade-off entirely by using incentives to encourage royalty payments without restricting open composability. It redefines what “owning” an NFT on the blockchain truly means.

Under this model, every NFT would have two different kinds of owners:

1. Asset Owner: This is the wallet that physically holds the NFT (what we usually consider the “owner” today).
2. Title Owner: This is the last wallet that paid a royalty (or a “title transfer fee,” which we’ll explain).

Here’s how “right of reclaim” works: If the asset owner and the title owner of an NFT are different, the original title owner can always reclaim the NFT back to their wallet. The current asset owner can remove this “reclaim risk” by paying a “title transfer fee” to the creator, thereby becoming the new title owner.

This isn’t quite like renting NFTs, though there are similarities. For instance, the ERC-4907 standard for rental NFTs also has two types of “owners.”

For simplicity, let’s assume the only way to transfer “title ownership” is by paying this fee. In this system, the “title transfer fee” effectively becomes the new “royalty.” Unlike traditional royalties (which are a percentage of the sale price), this fee would be fixed, though the creator could adjust it over time.

The threat of the original title owner reclaiming the NFT is what pushes people to pay the royalty. It helps distinguish between actual sales and other transfers:

• Transferring to your own wallet: You’re still the title owner, so no risk of reclaiming from yourself.
• Gifting an NFT to a friend: You’d remain the title owner. Your friend can use the NFT, trusting you won’t reclaim it. If your friend wants full “title” ownership, they can pay the fee to the creator. Alternatively, you could pay the fee when sending the gift.
• Selling an NFT (on a marketplace or privately): The buyer has a strong incentive to pay the title transfer fee to prevent you (the seller) from reclaiming the NFT after taking their money.

How would marketplaces adapt?

Ideally, marketplaces wouldn’t need a huge overhaul. The best approach would be for them to bundle the “title transfer fee” into the NFT purchase transaction. This way, the new buyer immediately gains both asset and title ownership, providing a seamless and secure experience.

What about NFT “wrapping”?

Neither “right of reclaim” nor blocklists/allowlists completely prevent NFTs from being “wrapped” to avoid royalties (unless you forbid all smart contracts from owning NFTs, which is too restrictive). With “right of reclaim,” a wrapping contract would need to pay the title transfer fee to legitimately wrap the NFT. This effectively acts as an “exit fee” to leave the NFT’s ecosystem. If a popular wrapping contract emerges, it can be easily identified.

Furthermore, if an NFT’s title owner is a known malicious wrapper, the creator could block those NFTs from community events or utilities. An owner of such a wrapped NFT could then pay to transfer the title ownership away from the wrapper (a “re-entry fee”) to rejoin the community.

More broadly, simply showing whether an NFT has an “unpaid royalty/title transfer fee” could incentivize buyers to pay it, as not having full “title” ownership might limit access to certain features or communities.

Key assumptions for “right of reclaim”

This framework relies on two main assumptions:

1. Fixed fee vs. percentage: Creators must be okay with royalties being a fixed “title transfer fee” rather than a percentage of the sale price.
2. Accepting wrapped NFTs (with controls): Creators must be okay with the possibility of their NFTs being wrapped, knowing that there’s an exit/re-entry fee system, and that they can identify and manage community access for wrapped NFTs.

If these assumptions aren’t acceptable, then “right of reclaim” needs to be combined with other features. We hope to explore these further in the future, and we encourage the community to contribute to this important discussion.

We also recognize that “right of reclaim” is a new way of thinking about NFT ownership. However, similar dual-ownership structures already exist, like with ENS domains (which have a “registrant” and a “controller”).

Ultimately, when designing NFT royalty solutions, we all share common goals: keeping NFTs flexible and usable (composability), protecting digital property rights, and ensuring creators are fairly compensated for their incredible work.

As NFTs continue to evolve beyond just collectibles, there won’t be a single, perfect solution. Every creator and every NFT is unique. Builders and creators need clear information about the various royalty designs and their trade-offs so they can choose what best fits their goals. The more options we have, the better.

This industry has the power to revolutionize how creators earn a living, and the very best solutions are likely still on the horizon. Royalty enforcement models are new, and many are still in the experimental phase. If you’ve got novel ideas after reading this, please share them!