a16z Crypto Partner: The Development History, Operating Mechanism, and New Opportunities of NFT Royalties

Video Title: Understanding NFT royalties | Michael Blau
Speaker: Michael Blau, Partner at a16z Crypto

Compiled by: Qianwen, ChainCatcher

People initially had a very optimistic vision for NFTs: NFT smart contracts would enforce secondary royalties on-chain, so as long as a creator's NFT was traded in the secondary market, the creator would earn money. This sounded fantastic—assets circulating on the internet would generate profits for creators every time they changed hands or were sold.

However, the reality is that smart contracts cannot enforce NFT royalties on-chain. In this talk, I will introduce some background knowledge, discuss NFT royalties, how they work, the evolution of different royalty standards, and potential solutions to the issue we just outlined. Finally, I will give you some advice.

Royalties

According to Investopedia, royalties are payments made to an individual or company for the ongoing use of their asset. Suppose you are an artist who created a very cool piece of art and sold it. If that NFT changes hands, is resold, or traded in any market, a certain percentage of the sale price will be returned to the original creator.

ERC721 and Royalties

ERC721 is a standard that defines the specifications for on-chain NFTs, including their code and state management. If you really read the relevant specifications, you will find that there is actually no requirement to enforce any payments or royalties on-chain. As shown in the figure, this piece of code is the open-source implementation of the ERC721 transfer function by Zeppelin. Essentially, it defines the logic of how an NFT is transferred from one wallet to another.

If you examine this code line by line, you will find that there is no mention of sale prices, the percentage taken from sale prices, etc. The standard does state that you can include fees in the transfer function in some way. But even so, there is no relevant standard. Therefore, if a project wants to enforce fees on transfers, it must operate on a project-specific basis, but there is no comparability or interoperability between projects.

Challenges

So, what are our current challenges? The first scenario is that if you want to charge a fee, let’s simplify the issue; perhaps we won't use a percentage royalty but rather a flat fee of one dollar: you can transfer the NFT at any time, and the creator will take one dollar from you. However, users in the ecosystem can wrap the NFT at any time. For example, they pay you one dollar, but instead of sending the NFT to another wallet, they send it to a smart contract that locks the NFT and issues a new NFT to you. This wrapped NFT would have no royalty restrictions and could be freely traded in the blockchain ecosystem. Another issue is: what if you want to transfer it to yourself? If you want to move your NFT from one wallet to another, you shouldn't have to pay a fee. The third scenario is that the more you add to the transfer function, whether fees or other rules, the more you essentially limit the composability of the NFT.

How Royalties Actually Work

The reality is that markets fulfill these royalties behind the scenes, so as a creator, what you need to do— is that you have to manually go to each market and tell them that this is my royalty, and inform them how much royalty I want to receive if my NFT sells.

In a field that values composability and interoperability, this operation is simply impractical. We now know that there are many markets on the blockchain, and anyone can easily create or deploy a market, potentially leading to an infinite number of markets. Asking a creator to manually request their royalties from every market is too high a demand. So, if we cannot enforce royalties in smart contracts— we also do not want to inform every market of our royalty information. Before we discuss solutions to the problem, I would like to talk about the evolution of NFT royalties.

Evolution of Royalties

EIP2981 is the NFT royalty standard. However, this standard does not enforce royalties, although this is a common misconception. What it does is collect your royalty information: creator information, the percentage of royalties they should receive, etc., and places this information on-chain, within the smart contract.

Markets only need to query your NFT contract to understand what they should do. As shown in the figure, a small snippet of code here demonstrates the so-called royalty information; you can see that it receives sales, prices, and then returns information to you—who should be paid and how much.

The purpose of this is that if a market sees your NFT contract trading on their platform, they can query this function to understand the data and fulfill your royalties.

But there is a small problem: the standard is not backward compatible at all. Therefore, if you created an NFT on-chain before the standard was introduced, you are locked out and cannot do anything. If your NFT contract is upgradeable, that’s not too bad. But the reality is that most people have not done this; most are just using other standards, such as open Blend contracts or other variants of ERC721 contracts.

The second issue is that there are no standards among markets. For example, before the idea of 2981 emerged, many market platforms like Foundation, Zora, and Wearable launched their own versions of standards. They did the same thing: returning the information needed to pay royalties, but with different specifics— for example, they might refer to royalty information as royalty data, perhaps not returning the actual royalty amount but only the royalty percentage and basis points. Thus, there really is no standard for markets to follow.

So how can we make EIP 2981 backward compatible while solving this problem? This is where the centralized royalty registry (manifold royalty registry) comes into play. It is a typical on-chain registry. It serves two purposes. First, it consolidates all existing standards, foundational standards, rare variable standards, and EIP291 into one standard. It encompasses all these standards, so it doesn’t matter which standard you are implementing.

Secondly, it enables backward compatibility. Therefore, even if you have not directly implemented EIP2981 in your contract, you can access this registry, input your copyright information, and then use that table.

Now, let’s look at a simple example. As shown in the figure, this is a snippet from the copyright registration website, which is their user interface. You input a smart contract address, a specific token ID within that smart contract, and a sale price, and the registry will return who should be compensated and how much based on the sale price you entered in the user interface.

This registry is decentralized, and creators can set it up and then leave it alone. They can upload their royalty information in one go without needing to take further action. If they wish, they can simply come to the registry to query this one place to get all the information they need. This makes it convenient for creators and markets, but there is still a small issue. The problem is that markets can still ignore the rights of the registry.

Operator Filter

The above operation only decentralizes the information of the royalty data itself and does not compel markets to do anything; markets may not respect royalties. So how can we get closer to this goal? This is where the operator filter comes into play.

The operator filter is an advanced feature. It is a blocklist that allows creators to prevent their works from being sold on markets or interacting with certain applications. It applies not only to markets but also to any application.

The best part of this idea is that you can enforce it on-chain. This is something you can put in the contract that can execute how your NFT interacts with other parts of the ecosystem. Because in most cases, any NFT application generally requires users to approve a smart contract to transfer an NFT on their behalf. Therefore, in the context of a market, users may approve transferring their assets, NFTs to the market, thus listing them on the market. If there is a matching party, the market will bid and offer, and then they will transfer the money to you as the seller and the NFT from your wallet to the buyer's wallet. This market essentially operates as a smart contract on-chain.

You can use the operator filter to block them. It does two cool things. The first is to block specific addresses. You can view the market as a smart contract on-chain located at a specific address, and I can directly ban that address. But we also know that others can redeploy the code and bypass your blocklist. A clever solution is the code hash, which is a unique digital fingerprint of the source code of the application or market itself. Therefore, we will obtain the unique digital fingerprint of the source code and block that fingerprint. So even if someone copies the market 30 times on-chain, it doesn't matter; the blocklist will still prevent them.

So how do we set up the filter? As a creator or project, you have two options. The first option is that you can curate your own blocklist, and you can trust yourself very much. You can become an excellent on-chain detective. You can keep up with the latest developments of every market and application. You can understand the latest trends of every market and application, judge whether to allow your NFTs to interact with those applications, and create your blocklist on-chain.

The second option is to outsource it to another team; one team I recommend is called CORI, which is also a research institution. It is basically composed of many popular companies and markets in the ecosystem, such as Zora, OpenSea, NiftyGateway, etc. We decide who can join this market and who can join that market, leaving the rest to this team.

There will be some trade-offs between the two. In the first version, you have complete control. In the other version, you have complete control, but you may not agree with all the decisions made by CORI.

Summary

As we initially stated, we cannot enforce royalties on-chain, but perhaps we can obtain royalty data on-chain. Let’s use a centralized royalty registry to put this information on-chain, and then we can get closer to enforcement.

If you want to use NFTs in your project, you can use the operator filter, even if you don’t want to block anyone. Because deploying this filter requires almost no effort. You can directly add operator filter code to your smart contract and leave some possibilities open, as the industry is changing every day, and we don’t know what will happen tomorrow.

Finally, discussions about royalties are changing every day. Some of the things I talked about today have emerged in the past few months, so let’s not make any hasty decisions. If you are going to create an NFT, make sure the NFT is scalable. Scalability and upgradeability are completely different; for any technician, you know you can easily create an upgradeable smart contract. This is certainly an option, but if you don’t want to do that because you don’t want to have all the control and want to do more in terms of decentralization, you can make your NFT scalable.

There are many standards in the current ecosystem, perhaps not so popular, but they do exist, such as modular NFTs, centralized NFT contracts, and centralized royalty registries, and their NFTs are also scalable. You can add plugins to your NFTs; in the case of the operator filter, you need to complete a lot of on-chain code. If I had launched a centralized NFT a few months ago when the operator filter had not yet appeared, due to the structure of the contract, adding plugins and using the operator filter would be very simple for me. So you need to give yourself this option because we really don’t know what will happen in the future.