Written by: Michael BlauScot, Duke Kominers and Daren Matsuoka, a16z crypto Translated by: Yangz, Techub News
Automatic enforcement of secondary sale royalties has long been a key value proposition for the NFT industry. Ideally, NFT creators could set royalties on-chain, and whenever their creations were sold anywhere on the internet, the royalties would be automatically paid, without having to rely on the marketplace and other third parties to voluntarily pay royalties. However, it has been misunderstood that NFT royalties have never actually been truly enforced on-chain. Currently, the practicalities of enforcing royalties on-chain have not kept up with market demand. The challenge is that it is difficult to distinguish between NFT resales (for which royalties should be paid) and other types of transfers, such as flows between users’ own wallets, or sending NFTs as gifts. Some royalty designs attempt to address this challenge by recognizing different types of NFT transfers and enforcing royalties when appropriate, but these mechanisms require significant trade-offs between strict royalty enforcement (ensuring royalty payments) and composability (how well the NFT interacts with other applications on the chain). In this article, we will discuss the pros and cons of existing NFT royalty designs, and how they strike a balance between enforcing royalties and enabling composability. We then introduce two new approaches to NFT royalties that leverage incentives to get 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 the associated trade-offs.
First of all, what is composability?
Composability is a core feature of open source software, allowing developers to combine, modify, and mix and match parts of a project like "Lego" without limits to create interesting new applications. There are two basic ways to combine applications with NFTs: Reading (checking ownership) or Writing (facilitating transfers):
Reading means verifying blockchain data. Applications can combine with NFTs by verifying the ownership of NFTs as a "threshold" for further actions. For example, the owner of an NFT can obtain the right to claim another NFT, play a game, participate in voting governance, obtain permission to use NFT media content, or attend a meeting. In addition, people can also use NFTs to associate on-chain data with their wallet addresses.
Writing (facilitating transfers) means updating the blockchain state. NFT transfers update the NFT's owner on-chain. In the simplest case, one can directly transfer an NFT to another wallet. Applications can also be combined with this transfer functionality in two ways: transferring NFTs on behalf of the owner (such as in an NFT marketplace) or escrowing NFTs for a period of time (such as OTC escrow, NFT leasing agreements, or lending agreements that accept NFTs as collateral).
It’s important to distinguish between these different types of NFT composability. When we mention “composability” in this article, we’re primarily referring to “Writing,” which is the “transfer” of NFTs. While anyone can verify ownership of an NFT on a public blockchain, existing royalty designs limit which wallets and smart contracts can perform transfers or own NFTs in the first place. Restricting “Writing” could hinder opportunities to use NFTs in scenarios such as DeFi, gaming, shared ownership through multi-signatures, and gifting from friends. Below, let’s look at existing royalty solutions and trade-offs in more detail.
Existing solutions: blacklist and whitelist
A key reason why royalty enforcement is difficult is the difficulty in distinguishing between NFT resales (for which royalties should be paid) and other types of transfers. More specifically, due to the way the default NFT standard implements the transfer function, the NFT smart contract has no idea whether the transfer involves a selling price. Therefore, existing solutions attempt to provide more context around on-chain transfers (for example, is this transfer a resale? Or is it conducted through a specific marketplace?) The most popular NFT royalty enforcement designs at present are blacklist and whitelist mechanisms, which use different methods to restrict transfers, but also limit composability. Both mechanisms restrict transfers at the following two levels:
Prevent market or application-facilitated diversion that evades royalties.
Prevent transfers to certain account types, such as EOA (the wallet most people use today) and smart contract accounts. In other words, there are restrictions on which types of accounts are allowed to own NFTs.
Regardless of which design is used, NFT creators face a significant trade-off; generally speaking, the more stringent the creator's prevention of transfers, 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. NFT creators can add specific marketplaces or application addresses that do not pay royalties to the blacklist of their NFT smart contract; if the NFT owner attempts to transfer the NFT through these banned applications, the transaction will fail. You can learn more about blacklists here. Think of it like a firewall on your computer: we can browse the web freely, but the firewall will prevent us from visiting websites they deem unsafe. In the world of NFT royalties, the "firewall" blocks applications that are known to not respect royalties. Advantages
By default, NFTs can be freely combined with most applications. This is because most applications, except for blacklisted ones, respect royalties by default.
Instant protection of royalties. NFT creators can block any contracts they find that are evading royalties by adding them to a blacklist.
shortcoming
Bad actors can always circumvent blacklists and evade royalties by setting up new markets.
Blacklists cannot proactively prevent royalty evasion, they can only respond reactively. New markets can emerge at any time, so NFT creators have to play a game of “cat and mouse”, monitoring the market for royalty evasion and blacklisting it.
The last point is the biggest challenge: in order for the blacklist to be effective, the creator needs to constantly monitor new applications on the chain, track every new smart contract market that may appear, analyze it, and then decide whether to ban it. This is a daunting task. Moreover, as smart contracts are upgraded, even existing markets may need to be reviewed. If an application that evades royalties is accidentally missed, it means that the creator will miss a lot of royalties. In addition, there is a "short board" problem: as long as there is a "slippery fish", a disproportionate amount of transactions may flow to that market. A potential solution is to entrust the management of the blacklist to a third party. However, this reintroduces reliance on intermediaries, giving market power to that entity, which may have various other consequences beyond the scope of this article.
whitelist
A whitelist can explicitly specify the smart contract addresses or applications that are allowed to facilitate NFT transfers. NFT owners can only transfer NFTs through smart contracts in the whitelist, otherwise the transfer will fail. Existing whitelist designs also include some optional components, such as restrictions on which types of wallets are allowed to own NFTs, usually only EOAs rather than smart contract accounts; and restrictions on whether peer-to-peer transfers are allowed. Advantages
NFT transfers cannot be made through applications outside of the whitelist, thereby excluding royalty evasion markets.
Unlike blacklist mechanisms, creators do not need to track new markets for royalty evasion, and the urgency of monitoring is greatly reduced.
shortcoming
Creators need to approve all independent applications that wish to facilitate the transfer of NFTs. Both blacklists and whitelists require a certain level of on-chain monitoring. When using blacklists, creators need to monitor applications that evade royalties. On the other hand, creators may miss innovative applications built around NFTs due to the whitelist mechanism, thus limiting the composability of NFTs. Suppose a developer creates a unique market concept for NFTs (which also requires the payment of royalties), but the developer needs to contact the creator of the NFT, prove that they respect the royalties, and request to be added to the whitelist of each NFT. This process is cumbersome just to think about.
Additionally, there are ways to evade royalties, depending on how the market is implemented and the restrictions that creators place on the transfer of NFTs. For example, if selling NFTs for $0 is allowed, then by creating a version of the market that evades royalties based on a royalty-compliant market, first facilitating $0 transactions on the royalty market while transferring the actual payment on the tax-avoidance market, royalties can be evaded. Since the selling price is $0, the creator receives $0 in royalties.
Too much is as bad as too little. The most restrictive version of the whitelist would restrict which types of wallets can own NFTs (EOA or smart contract account) and peer-to-peer (P2P) transfers. The purpose of restricting smart contracts to own NFTs is to prevent NFT packaging (discussed below), which may be too restrictive in a world where everyone uses smart contract wallets. Restricting P2P means that whenever a transfer occurs, it must go through a whitelist-permitted market. The reason for restricting P2P is to prevent OTC (over-the-counter) transactions, which obviously prevent creators from receiving royalties. In addition, restricting P2P will make it difficult for NFT owners to transfer NFTs directly between their own wallets or between friends.
trade off
Whether it is a whitelist or a blacklist, there is a trade-off between strict royalty enforcement and open composability. The blacklist mechanism allows open combination by default, but is more prone to royalty issues. The whitelist mechanism makes it easier to enforce royalties, but it also greatly limits the possibilities of which applications NFTs can interact with. This trade-off is not just a matter of blacklists and whitelists. Any way we allow NFTs to interact with which applications and operations will limit the composability and functionality of NFTs. Improving technical means may make the trade-off easier, but the fundamental problem still exists.
Exploring a new framework for NFT royalties
NFT creators are still testing whitelisting mechanisms, but as more NFT use cases emerge, it’s worth exploring how to go beyond blacklists and whitelists to improve the tradeoff between royalty enforcement and composability. We refactored the above problems and existing royalty mechanisms from an incentive mechanism perspective: our goal is to introduce incentives that prompt NFT markets and consumers to actively choose to respect royalties. This also theoretically provides the possibility of allowing more composability. Below we will illustrate two different approaches. The first mechanism is based on the whitelist mechanism, but is more open, more composable, and more encouraging permissionless innovation based on NFTs. The second mechanism, which we call the "right of reclaim," incentivizes consumers to use a market platform that respects royalties when selling NFTs, thereby maintaining open composability while still largely realizing royalty payments. Our goal is not to propose a single "solution," but to expand the range of options: how can we ensure that creators get more royalties without restricting composability?
Method 1: Combining whitelisting with staking mechanism
We can extend the existing whitelisting mechanism with a staking mechanism, allowing marketplaces and other applications to obtain whitelist eligibility permissionlessly. Currently, NFT creators must manually add marketplaces or applications to their whitelists, and third-party developers must request permission from the creator to be added. This situation can slow innovation and adoption of new applications and put the onus on creators to vet new applications. Delegating the work of whitelisting to third parties will also slow the process. Combining whitelisting with a staking mechanism allows new applications to optimistically add themselves to the whitelist by staking funds or other resources as a promise to enforce royalties (optimistic here means trusting and then verifying, not assuming bad actors). By default, NFT owners can interact with new applications immediately as long as they provide appropriate staking; if the application misbehaves, the creator can forfeit the staking and remove the application from the whitelist. We can even imagine a hybrid model where if an application does not have tax avoidance issues for a period of time, the creator can officially add the application to the whitelist and return the staking. Of course, there are some unresolved issues with this design approach. How do NFT creators enforce forfeiture arbitration? The criteria for forfeiture, i.e. whether royalties are enforced, is challenging to detect and prove on-chain. Application developers need to trust that creators will not intentionally forfeit them or remove them from whitelists. Who can get the forfeited staked funds? On the one hand, providing creators with forfeited staked funds can partially compensate for their royalty losses, but if the forfeited staked funds do not belong to the creator, the creator’s motivation for malicious forfeiture will also be reduced. For this issue, the EIP-1559 transaction fee mechanism on Ethereum can give us some inspiration, in which the transaction base fee is destroyed instead of sent to the validator. How should the size of the stake be set? The value of the stake needs to have a certain relationship with the amount of royalties that the application may bring to a specific creator. For less popular or niche applications, smaller stake sizes should be feasible.However, for marketplaces that facilitate a large number of NFT transactions, larger stakes will be required, and stake levels may need to scale with the value and transaction volume of the NFT over time. Do we need to aggregate stakes across multiple NFTs? If so, how? Application developers may need to stake for each NFT series they want to combine, which would undoubtedly be a huge burden. However, if developers only need to stake on one of the NFT series and can prove that they are honest, the burden would be reduced. Similarly, one can also envision a strategy where the marketplace uses a large, single stake to promise to collect royalties on a large number of NFT series.
Method 2: Right of reclaim
The right of redemption is a new approach that goes beyond the trade-off between royalty enforcement and composability (and also beyond blacklist and whitelist mechanisms) and uses incentive mechanisms to encourage the active payment of royalties when NFT transactions occur without restricting permissionless composability. At the core of this strategy is the refinement of what it means to "own" an NFT on-chain. Each NFT has two possible different owners, which we call the asset owner and the title owner:
The asset owner is the wallet that holds the NFT (we now usually call it the “owner”);
The title owner is the last wallet to pay royalties (or title transfer fees) to the NFT creator.
Under the redemption right mechanism, if the asset owner and the title owner of the NFT are different, then the title owner can withdraw the NFT to his wallet at any time. The asset owner can become the title owner by paying the NFT creator a title transfer fee, thereby eliminating this "reclaim risk". Redemption rights are not equivalent to leasing, but they have similarities to leasing NFTs. For example, ERC-4907 is a "leasing NFT" standard, which also has the concept of two "owners" of NFTs. For simplicity, we assume that the only way to transfer the identity of the title owner is through a monetary transfer via a title transfer fee. (In practice, there can be other ownership transfer mechanisms - such as automatically transferring ownership after a long enough period of time, or designing a mechanism for the NFT creator to directly trigger the transfer of ownership to the current asset owner.) In this model, the title transfer fee becomes the new "royalty"; markets that respect royalties will bundle the payment of the title transfer fee with NFT transactions. It’s important to note that this means royalties will no longer be a direct function of the transaction price; the title transfer fee is a fixed fee, unlike the variable “percentage of transaction price” fee that NFT royalties have historically used. That is, creators can selectively update the title transfer fee over time. The risk of the title owner reclaiming the NFT helps distinguish whether the transfer of an NFT is a resale (payable royalties) through people’s behavior. Specifically, this new ownership model encourages the payment of royalties (i.e., title transfer fees) on NFT transfers between parties involved in a transaction, which the seller could otherwise reclaim immediately after “selling” the NFT and collecting payment. In addition, this framework also allows NFTs to be freely transferred between personal wallets or as gifts. Let’s look at a few examples to see what this looks like in action:
If I transfer the NFT to my own personal wallet... then only the ownership of the asset will be transferred to the new wallet, the original wallet will still be the owner, and there is no risk of recovery.
If I give an NFT to a friend as a gift… then only the ownership of the asset is transferred, and I remain the owner. My friend can use it however they want (including selling it; we’ll discuss how markets should handle this below) and can trust that I won’t take the NFT back. If my friend wants full ownership, they can always pay the NFT creator a transfer fee. Alternatively, I can pay the transfer fee when I send the NFT.
If I resell the NFT via a marketplace sale or an OTC transaction outside of the marketplace (e.g. if you give me 100 USDC, I transfer you the NFT directly)… then the buyer has a strong incentive to pay the title transfer fee to eliminate the risk of me taking back the NFT after receiving payment.
To accommodate this model, do marketplaces have to change the way they operate? In principle, not at all. However, the right of redemption means that any NFT purchased on the marketplace is at risk of being redeemed, which undoubtedly creates a bad user experience! A better strategy would be for marketplaces to bundle NFT purchases with the payment of a transfer fee, thereby transferring ownership to the new buyer at the same time as the sale. In this model, supporting royalty payments would go hand in hand with ensuring a better marketplace experience. It should be noted that neither the right of redemption nor the blacklist and whitelist mechanism can prevent the use of packaged NFTs to evade royalties (unless all smart contracts are prevented from owning NFTs, but this is extremely restrictive given the growth of account abstraction). It is just that with the right of redemption, the packaged contract must pay the transfer fee to obtain ownership of the NFT and thus make a legal packaged NFT. This is actually also the so-called exit fee, the price of leaving the NFT ecosystem. In addition, if a popular packaged contract appears, it is also easy to identify on the chain. NFT creators can prevent any NFT whose ownership owner is a malicious packaged contract from participating in the NFT ecosystem, community activities, or other related use cases. Assuming that a wrapper contract is identified and blocked from entering the community, if it wants to "re-enter" the ecosystem, it will need to pay a re-entry fee to transfer ownership away from the wrapper contract. More broadly, there may also be benefits to disclosing information about whether the asset owner is also the title owner. Reducing access rights for non-title owners throughout the ecosystem may greatly incentivize NFT buyers to pay royalties. For example, prominently displaying NFTs in the market or wallet for which no royalties/title transfer fees have been paid may encourage consumers to choose to pay royalties. Assumptions The reclaim rights framework relies on two key assumptions:
NFT creators agree that the ownership transfer fee becomes a "royalty" and that the royalty is no longer a direct percentage of the sales price.
NFT creators can accept the possibility that their NFTs will be wrapped to avoid royalties (but will still have to pay the exit and re-entry fees mentioned above), and can easily identify and block community access to wrapped NFTs.
Note: All of the patterns discussed are not effective in preventing NFT packaging unless all smart contracts are prevented from owning NFTs. Of course, there are some non-malicious forms of packaging, such as cross-chaining NFTs to different blockchains. Cross-chain NFTs are a complex topic and are beyond the scope of this article. If creators cannot accept these assumptions, then the design of reclaim rights cannot stand alone. We hope to further expand these features and components with other members of the community in future work. We also recognize that reclaim rights deviate from the existing mindset about NFT ownership. Nonetheless, NFTs with similar ownership structures already exist (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 goals, namely protecting composability, maintaining digital property rights, and ensuring that creators are fairly compensated for their amazing works. More and more NFT use cases are beginning to emerge, but there is no one-size-fits-all royalty solution. Every creator (and every NFT) is different. App builders and NFT creators should have an easy way to understand various royalty designs and their tradeoffs, so they can choose the one that fits their unique goals. The more we can expand the design space, the better. The NFT industry has the power to improve how creators make a living from their work, but the best ways may not be here yet. Royalty enforcement models are new, and many are experimenting. If you have any new ideas after reading this post, share them with us!
Author: TechubNews; from the ChainDD content open platform "DeDeHao", this article only represents the author's point of view, not the official position of ChainDD. For all "DeDeHao" articles, the originality and authenticity of the content are guaranteed by the contributors. If the article is plagiarized, falsified, etc., the legal consequences will be borne by the contributors themselves. If there are any infringements, violations, or other inappropriate remarks on the DeDeHao platform, please supervise the readers. Once confirmed, the platform will be offline immediately. If you encounter any problems with the content of the article, please contact WeChat: chaindd123
