NFT royalty design attempts to solve the problem of automatically executing secondary sales royalties, but the existing methods will sacrifice the composability of NFTs.

Original Title: "How NFT royalties work: Designs, challenges, and new ideas"

Authors: Michael Blau, Scott Duke Kominers, Daren Matsuoka

Translators: Lynn, MarsBit

The automatic execution of secondary sales royalties has always been an important value proposition for NFTs. In an ideal world, creators can set royalties on-chain, and royalties will be automatically paid whenever their work is sold anywhere on the internet, without relying on markets and other third parties to honor royalties out of goodwill.

However, NFT royalties have never been truly enforced on-chain; this has been a misconception. The demand for enforcing on-chain royalties has exceeded the progress of making it a reality. The challenge is that it is difficult to distinguish NFT transfer sales that should pay royalties from other types of transfers, such as self-transfers between a user's own wallets, sending NFTs as gifts, and so on.

Newer royalty designs attempt to address this challenge by identifying different types of transfers and executing royalties at the appropriate times, but these mechanisms need to make significant trade-offs between strict royalty enforcement (ensuring royalty payments) and composability (the degree of interaction between NFTs and other on-chain applications).

Therefore, in this article, we will discuss the advantages and disadvantages of existing NFT royalty designs and how they balance royalty enforcement and composability. Then, we will introduce two new NFT royalty methods that use incentive mechanisms to encourage market participants to respect royalties. Our goal is not to advocate for a specific method, but to help builders consider different NFT royalty designs and related trade-offs.

What is "composability"?

Composability is a core feature of open-source software that allows developers to freely combine, modify, and mix project fragments like "Lego bricks" to create interesting new applications.

There are two basic ways in which applications can be combined with NFTs -- reading (checking ownership) or writing (facilitating transfer):

• Reading (checking ownership) means verifying blockchain data. Applications can interact with NFTs by verifying ownership of the NFT as a "gate" for further actions. For example, an NFT owner can access another NFT, play games, vote in governance processes, obtain licenses to use NFT media content, or participate in meetings or concerts. Additionally, people can use NFTs to link on-chain data to their wallet addresses (e.g., an NFT containing a username, and the person owning the NFT having that username on social media).
• Writing (facilitating transfer) means updating the blockchain state. NFT transfers update the ownership of the NFT on-chain. In the simplest case, people can directly transfer NFTs to other wallets. Applications can also combine with this transfer function in two ways: (1) representing owners transferring NFTs (e.g., in NFT markets) or (2) holding NFTs for a period of time (e.g., off-chain trading custody, NFT rental agreements, or lending agreements accepting NFTs as collateral).

It is crucial to distinguish between these different types of NFT composability. When we refer to "composability" in this article, we mainly mean "written" or "transferred" composability.

While anyone can verify NFT ownership on a public blockchain, existing royalty designs primarily restrict which wallets and smart contracts can execute transfers or own NFTs. Limiting "writing" may close off opportunities to use NFTs in DeFi, games, shared ownership through multisignature, or even gifting NFTs to friends, as well as applications where NFTs own other NFTs.

Now, let's take a closer look at existing royalty solutions and trade-offs.

Existing Solutions: Blocklists and Allowlists

One key reason why enforcing royalties is difficult is that it is challenging to distinguish NFT transfers that belong to sales (which should pay royalties) from other types of transfers. Specifically, because of the way default NFT standards implement transfer functionality, NFT smart contracts do not know if a transfer involves a sale price. Existing solutions attempt to provide more context around on-chain transfers (e.g., was this transfer a sale? or was it through a specific marketplace?).

The most popular designs for enforcing NFT royalties, namely blocklists and allowlists, take different approaches to restrict transfers while limiting the composability of "writing" or "transferring."

Both designs prevent transfers on two levels:

• Preventing transfers facilitated by markets or applications that circumvent royalty payments.
• Preventing transfers to certain types of accounts: externally owned accounts or EOAs (the wallets most people use) and smart contract accounts. In other words, there are restrictions on which types of accounts are allowed to own NFTs.

Therefore, creators using either design have to make significant trade-offs based on how their NFT smart contracts implement transfer "prevention": the stricter the prevention of transfers, the lower the composability of NFTs.

Blocklists

Blocklists are lists of specific smart contract addresses or applications that are not allowed to facilitate NFT transfers. Creators add addresses of specific markets or applications that do not pay royalties to their NFT smart contract's blocklist; if an NFT owner attempts to transfer their NFT through a blocked application, the transaction will fail. You can learn more about blocklists here.

Think of them as firewalls on a computer: you can freely browse the web, but the firewall will block sites it deems unsafe. Here, the "firewall" blocks applications known to not respect royalties.

Advantages

By default, NFTs can freely combine with most applications. This is because blocklists optimistically assume that most applications respect royalties.

Creators can immediately protect royalties. Creators can shut down any contracts they find circumventing royalties by adding them to the blocklist.

Disadvantages

Bad actors can bypass the blocklist. Malicious actors can create a new market that circumvents royalties at any time and is not on the blocklist.

Blocklists cannot actively prevent royalty circumvention, only passively. New markets can emerge at any time. Creators have to play a "cat and mouse" game, monitoring which markets are circumventing royalties and then adding them to the blocklist.

The last point is the biggest challenge. To make blocklists effective, creators need to constantly monitor new applications on-chain, analyze each potential new smart contract market, and decide whether to block it. This is a daunting task; even existing markets may need reevaluation as smart contracts upgrade.

Excluding royalty-circumventing applications from the blocklist means missing out on payment opportunities. Additionally, there is a "leaky bucket" problem: if even one market circumventing royalties is not blocked, there is a possibility of disproportionate flows of transactions to that market in equilibrium.

A potential solution is to delegate blocklist management to a third party. However, this would reintroduce reliance on intermediaries to help enforce royalties, empower that entity over markets, and may lead to various other consequences beyond the scope of this article.

Allowlists

Allowlists explicitly specify the unique smart contract addresses or applications allowed to facilitate NFT transfers. With this strategy, creators only allow markets or applications that can guarantee royalty enforcement. NFT owners can only transfer NFTs through smart contracts in the allowlist; if they attempt to use a market not on the allowlist to transfer NFTs, the transfer transaction will fail.

Existing allowlist designs also include optional components, such as (1) restricting which types of wallets are allowed to own NFTs, typically allowing only EOAs and not smart contract accounts, and (2) restricting whether peer-to-peer transfers are allowed.

Advantages

NFT transfers cannot be facilitated by applications not on the allowlist, such as markets that circumvent royalties. The allowlist only approves transfers facilitated by smart contracts, and creators know that these contracts respect royalties. All other markets are defaulted to be blocked. It will be challenging to facilitate NFT transfers through markets that circumvent royalties, depending on the implementation of the allowlist and the market (see the disadvantages below).

Creators do not need to track and add new markets that circumvent royalties, as in the blocklist model. After adding one or more royalty-exempt markets to the allowlist, the urgency of monitoring new applications decreases.

Disadvantages

Creators need to approve all individual applications that wish to facilitate NFT transfers. Both blocklists and allowlists require a certain level of on-chain monitoring. With the use of a blocklist, creators need to monitor applications circumventing royalties to avoid missing out on royalty payments. On the other hand, the allowlist dictates the permitted composability. Creators will not miss out on royalty payments, but they may miss out on innovative applications built around NFTs. For example, a developer creates a unique market concept for NFTs (also requiring royalty payments!). The developer needs to contact the NFT creator, prove their respect for royalties, and request to be added to the allowlist for each NFT. This is a high-friction process.

There are still methods to circumvent royalties, depending on the implementation of the market and the restrictions on NFT transfers by the creator. For example, if NFTs can be sold at a price of $0, it is still possible to circumvent royalty payments through the allowlist/royalty-honoring market. In this case, someone can establish a market that circumvents royalties on top of the royalty-honoring market, facilitate sales at $0 on the royalty-honoring market, and transfer the actual payment on the side. As the sale amount is $0, the royalties received by the creator will be $0 (i.e., 5% royalties on $0 is $0).

The allowlist may be overly restrictive. Even the strictest version of the allowlist will limit which types of wallets can own NFTs (EOAs or smart contract accounts) and peer-to-peer (p2p) transfers. The restriction on smart contract ownership of NFTs aims to prevent NFT wrapping (discussed below), and in a world where everyone uses smart contract wallets, this restriction may be too stringent. Restricting p2p transfers means that transfers must always go through markets listed on the allowlist. The restriction on p2p transfers is to prevent over-the-counter (OTC) p2p sales, which would deprive creators of royalties. Restricting p2p transfers makes it very difficult for NFT owners to transfer NFTs directly between their own wallets or to friends.

Trade-offs

Both allowlists and blocklists strike a balance between strict royalty enforcement and open composability. The blocklist model defaults to supporting open composability but is more susceptible to royalty circumvention. With the allowlist, royalty enforcement is easier, but it significantly restricts which applications NFTs can interact with.

This trade-off is not just a matter of blocklists versus allowlists: any way we allow NFTs to interact with applications and operations limits the composability and functionality of NFTs.

Exploring New NFT Royalty Frameworks

Creators are still testing allowlists, but as more NFT use cases emerge, it is worth exploring how to go beyond the limitations of the blocklist/allowlist model and improve the balance between royalty enforcement and composability.

The strategies we are discussing here start from the perspective of incentive mechanism design and involve some rethinking of the problem and existing royalty mechanisms: our goal is to introduce incentive mechanisms that encourage NFT markets and/or consumers to actively choose to respect royalties. This, in principle, provides the possibility of allowing more composability.

Below, we will illustrate two different methods. The first mechanism is based on the allowlist model, which is more open, more composable, and more encouraging of permissionless innovation on NFTs. The second mechanism, which we call "reclaim rights," provides a powerful incentive mechanism for consumers to use royalty-respecting market platforms when selling NFTs, while still largely achieving royalty payments while maintaining open composability.

Our goal is not to propose a single "solution," but to expand the range of choices: how can we ensure that creators receive more royalties without limiting composability and relying entirely on goodwill?

Method 1: Mechanism Combining Allowlist with Staking

We can extend the existing allowlist model through an authorization mechanism that allows markets and other applications to qualify for the allowlist membership without permission.

Currently, creators must manually add markets or applications to their allowlist, and third-party developers must apply to creators for permission. This may slow down innovation and adoption of new applications and make creators responsible for reviewing new applications to ensure they enforce royalties. Delegating the planning of the allowlist to a third party would also slow down the process.

Introducing a staking mode for allowlist membership allows new applications to optimistically add themselves to the allowlist by staking funds or other resources as a commitment to enforce royalties (optimistically meaning trust and verify, rather than assuming bad actors). By default, NFT owners can immediately interact with new applications as long as they provide the appropriate stake; if the application behaves improperly, the creator can reduce the stake and remove the application from the allowlist. We can even envision a hybrid mode where if an application proves itself honest over a period, the creator can formally add the application to the allowlist and return the stake.

There are still pending issues with this design approach. We outline these issues here for further consideration and research by others.

How will creators enforce stake reduction? The standard for reduction - i.e., whether royalties are enforced - is challenging to detect and prove on-chain. Application developers need to trust that creators will not reduce their stake unfairly and remove them from the allowlist when it should not be reduced.

Who should receive the reduced stake? On one hand, providing reduced shares to creators can partially compensate for the reduction event triggered by circumventing royalties. However, if the reduced shares do not belong to the creators, the motivation for creators to maliciously reduce shares will decrease. The transaction fee mechanism of EIP-1559 on Ethereum can provide some inspiration, where the base fee is burned instead of being sent to validators.

What should be the size of the stake? The value of the shares needs to have some relation to the potential royalty amount the application could bring to a specific creator. For less popular or niche applications, a smaller scale of shares may be feasible. However, markets that facilitate a large number of NFT sales will require a larger stake, and the level of shares may need to be linked to the value of the collection and trading volume over time.

Do we need to aggregate stakes across multiple NFTs? If so, how will this be achieved? Developers may need to inject resources into every collection of NFTs they want to compose, which will be a huge burden. However, if developers inject resources into one collection and prove themselves honest, it can alleviate the burden on other NFT creators to add the new application to their allowlist. Similarly, we can also envision a strategy where markets use a large, single stake to commit to collecting royalties for a large number of works.

Method 2: Mechanism Allowing "Reclaim Rights"

"Reclaim rights" is a new approach that goes beyond the balance between enforcement and composability (and beyond blocklists/allowlists), using incentive mechanisms to encourage royalty payments when NFTs are sold without limiting permissionless composability. The core of this strategy is to refine the meaning of "ownership" of NFTs on-chain.

Each NFT has two potentially different records of ownership, which we refer to as asset ownership and ownership ownership:

• Asset ownership refers to the wallet holding the NFT (commonly referred to as the "owner" now);
• Ownership ownership refers to the last wallet that paid royalties to the NFT creator (or transfer fee, as defined below).

Under the "reclaim rights" mechanism, if the asset owner and the ownership owner of an NFT are different, meaning the wallet of the asset owner is different from the wallet of the ownership owner, the ownership owner can reclaim the NFT to their own wallet at any time. The asset owner can become the ownership owner by paying a transfer fee to the creator, thus eliminating this "reclaim risk."

Reclaim rights are not leasing, but they have similarities to leasing NFTs. For example, ERC-4907 is a "leasing NFT" standard that also involves the concept of an NFT having two "owners."

For simplicity, we assume that the only way to transfer ownership ownership is through a monetary transfer of the ownership transfer fee. However, in practice, there could be other ownership transfer mechanisms - such as automatic ownership transfer after a sufficient period of time, or designing a mechanism for the creator to directly trigger ownership transfer to the current asset owner.

In this model, the ownership transfer fee becomes a new "royalty"; royalty-respecting markets will bundle the payment of the ownership transfer fee with the sale transaction. It is important to note that this means royalties will no longer be a direct function of the sale price; the ownership transfer fee is a fixed cost, unlike the variable "sale price percentage" fee historically used for NFT royalties. In other words, creators can selectively update the ownership transfer fee over time.

The risk of ownership owners reclaiming NFTs helps distinguish between which NFT transfers are considered sales (and should be subject to royalties) and which transfers are not. Specifically, this new ownership model encourages non-liquid fund transfers between parties involved in sales to pay a licensing fee (i.e., the ownership transfer fee), as otherwise the seller could reclaim the non-liquid funds immediately after "selling" them and receiving payment.

At the same time, this framework allows for free transfers between individual wallets or transfers as gifts.

Let's consider a few examples of transfers and how they would operate in practice:

• If I transfer an NFT to my own personal wallet… only the asset ownership will transfer to the new wallet, and I will retain ownership. However, I do not have the risk of reclaiming it.
• If I gift an NFT to a friend… only the asset ownership will transfer, and I will retain ownership. My friend can use it freely (including selling; we will discuss how markets should handle this below) and can rely on social trust that I will not reclaim the NFT. If my friend wants full ownership, they can pay the ownership transfer fee to the creator at any time. Alternatively, I can also pay the ownership transfer fee when sending the gift NFT.
• If I transfer an NFT through a market sale or over-the-counter (OTC) transaction outside of a market (e.g., if you give me 100 USDC, I will directly transfer the NFT to you)… the buyer has a strong incentive to pay the ownership transfer fee to eliminate the risk of me reclaiming the NFT after taking their money.

Does the market platform need to change its operation to accommodate this model?

In principle, it does not need to. However, reclaim rights mean that any NFT purchased on the market carries the risk of being reclaimed, which is a poor user experience - the buyer's NFT could be reclaimed! A better strategy is for the market platform to bundle the purchase of non-transferable agreements with the payment of the ownership transfer fee, thereby transferring ownership to the new buyer at the time of sale. In this model, supporting royalty payments will go hand in hand with ensuring a better market experience.

Both reclaim rights and allowlist/blocklist mechanisms cannot effectively prevent NFT wrapping unless you prevent all smart contracts from owning NFTs, which is very restrictive (especially considering the increasing abstraction of accounts).

With reclaim rights, wrapping contracts must pay the ownership transfer fee to gain ownership and create legitimate wrapped NFTs. This essentially becomes an exit fee, the cost of leaving the NFT ecosystem. Additionally, if popular wrapping contracts emerge, they can be easily identified on-chain.

NFT creators can prevent any NFT whose ownership owner is a malicious wrapping contract from participating in the NFT ecosystem, community activities, or other related utilities. Assuming a wrapping contract is identified and blocked from entering the community, and the NFT owner wants to "re-enter" the ecosystem. In this case, they can pay a re-entry fee to transfer ownership out of the wrapping contract.

More broadly, publicly available information on whether the asset owner is also the ownership owner may be beneficial. Reducing non-ownership owner access throughout the ecosystem could greatly incentivize NFT buyers to pay royalties. For example, prominently displaying NFTs that have not paid royalties/ownership transfer fees in markets or wallets can prompt consumers to choose to pay royalties.

Assumptions

The reclaim rights framework relies on two key assumptions:

• Creators agree that the ownership transfer fee becomes a "royalty," and royalties are no longer a direct percentage of the sale price.
• Creators can accept the possibility of their NFTs being wrapped to circumvent royalties (but still subject to the aforementioned exit and re-entry fees), and that you can easily identify and block community access to wrapped NFTs.

[Note: All the discussed models (blocklist, allowlist, reclaim rights) cannot effectively prevent NFT wrapping unless you prevent all smart contracts from owning NFTs. Of course, there are also non-malicious forms of wrapping, such as bridging NFTs to different blockchains. However, NFT bridging is a complex topic and is beyond the scope of this article].

If creators cannot accept these assumptions, then the reclaim rights design cannot exist in isolation. We hope to further expand these features and components in future work, and we hope that other members of the community can also contribute to solving this important issue together.

We also recognize that reclaim rights deviate from existing thinking about NFT ownership. Nevertheless, there are already NFTs with similar ownership structures, such as ENS with registrants and controllers.

-

In designing NFT royalty solutions, we believe that as an industry, we are all working towards the same goal: protecting composability, maintaining digital property rights, and ensuring fair compensation for creators of stunning works.

With more and more use cases for NFTs emerging, from collectibles to digital sodas, there is no one-size-fits-all solution. Every creator (and every NFT) is different. Builders and creators should have a simple way to understand the various royalty designs and their trade-offs in order to choose a design that suits their unique goals. The more design space we can expand, the better.

This industry has the potential to greatly improve the way creators make a living from their work, and perhaps the best way is yet to come. Royalty enforcement models are a new thing, and many are still experimenting. If you have any novel ideas after reading this article, please share them with us!

Acknowledgments: The author thanks Stephanie Zinn, Robert Hackett, Sonal Chokshi, Chris Dixon, Eddy Lazzarin, Joe Bonneau, Valeria Nikolaenko, and Tim Roughgarden for their valuable ideas and feedback.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。