a16z Crypto Partner discusses NFT Royalties How it Works, Evolution, and Solutions

a16z Crypto Partner on NFT Royalties How it Works, Evolution, and Solutions

Speaker: Michael Blau, Partner at a16z Crypto

Organized and compiled by: Qianwen, ChainCatcher

The initial vision for NFTs was very promising: NFT smart contracts would enforce secondary royalties on the chain, so whenever the creator’s NFT is traded on the secondary market, the creator would earn money. This is great because the asset can circulate on the internet, and every transfer or sale of the asset would bring profit to the creator.

However, the reality is that smart contracts cannot enforce NFT royalties on the chain. Regarding this topic, I will provide some background knowledge, talk about NFT royalties, how they work, the evolution of different royalty standards, and potential solutions to the problem we just outlined. Finally, I will give some recommendations.

• Why is data availability sampling important for blockchain scalability?
• How can NFT wearable devices lead the future of digital fashion?
• In-depth Analysis How did the blockchain data tool Dune rise rapidly?

Royalties

According to Investopedia, royalties are payments made to individuals or companies for the continuous use of their assets. Let’s say you are an artist and you create a very cool artwork and sell it. If the NFT changes hands, is transferred, traded, or sold on any market, a certain percentage will be deducted from the sales revenue and returned to the original creator.

Erc721 and Royalties

ERC721 is a standard that defines the on-chain specifications, code, and state management of NFTs. If you actually read the relevant specifications, you will find that there is no need to make any payments or enforce royalties on the chain. As shown in the code snippet below, this is the open-source code from Zeppelin that implements the transfer functionality of ERC721. Essentially, it defines the logic of how NFTs are transferred from one wallet to another.

If you go through this code line by line, you will find that there is no mention of the sale price or the percentage deducted from the sale price. The standard does mention that you can add fees to the transfer function in some way. But even so, there are no specific standards. Therefore, if a project wants to enforce fees on transfers, it must operate on a project-specific basis, but there is no comparability and interoperability between projects.

Challenges

So, what are our current challenges? The first scenario is, let’s simplify the problem, maybe you want to charge a fixed fee instead of a percentage royalty: you can transfer the NFT anytime, and the creator will receive 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 has no royalty restrictions and can be freely traded within the blockchain ecosystem. Another issue is: what if you want to transfer it to yourself? If you want to transfer 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 it’s fees or other rules, the more you limit the composability of the NFT.

The actual operation of royalties

The reality is that the market cashes in these royalties behind the scenes, so as a creator, what you need to do is – you must manually tell each market that this is my royalty, and tell them how much royalty I want to collect if my NFT is sold.

In a field that values composability and interoperability, this operation is simply not practical. We now know that there are many markets on the blockchain, and anyone can easily create or deploy a market, and there may be infinite markets. It is too demanding for a creator to manually request them from each market. So, if we cannot enforce royalties in smart contracts – we also don’t want to tell every market our royalty information. Before we discuss solving 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 misconception for many people. What it does is collect your royalty information: creator information, the proportion of royalties they should receive, etc., and put this information on the chain, in the smart contract.

All the market needs to do is query your NFT contract to know what it should do. As shown in the figure, a small piece of code here shows 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 doing this is that if the market sees your NFT contract trading on their market, they can query this function, understand the data, and cash in your royalties.

But there is a small problem: this standard is not backward compatible at all. So if you have created an NFT on the chain before the standard appeared, you are in a locked state and can’t do anything. If your NFT contract can be upgraded, the situation is not so bad. But the reality is that most people don’t do this, most people just use other standards, such as open Blend contracts or variants of other erc721 contracts.

The second problem is that the market has no standards. For example, before the idea of 2981 came up, many market platforms such as Foundation, Zora, and wearable launched their own versions of standards. They did the same thing: returning the information needed for royalty payment to you, but they differed in specific details – for example, they called royalty information royalty data, maybe not returning the actual royalty amount, but only returning the royalty percentage and basis points. Therefore, the market really has no standard to follow.

So, how can we make EIP 2981 backward compatible and solve this problem? This is where the manifold royalty registry comes in. It is a typical on-chain registry. It has two functions. First, it brings together all the current

The standard, basic standard, rare variable standard, and EIP291 are integrated into one standard. It includes all these standards, so it doesn’t matter which standard you are implementing.

Secondly, it also achieves backward compatibility. Therefore, even if you do not directly implement EIP2981 in the contract, you can still access this registry, enter your copyright information, and then use the registry.

Next, let’s take a look at a simple example. As shown in the figure, this is a fragment on the copyright registration website, which is the user interface they created. You enter a smart contract address, enter a specific token ID in the smart contract, and then enter a sale price. The registry will return who should receive the reward and how much reward should be received based on the sale price you entered in the user interface.

This table is decentralized, and the creator can set it and then leave it alone. They can upload their royalties and information here all at once, without any further action. If they want, they only need to come to the registry to query this one place to get all the information they need. This is convenient for both creators and the market, but there is still a small problem. The problem is that the market can still ignore the rights of the registry.

Operator Filter

The above operations only decentralize the information of the royalty data itself and do not force the market to do anything, and the market may not respect the royalties. So, how can we get closer to this goal? This is where the operator filter comes in.

The operator filter is an advanced feature. It is a blocking list that allows creators to block the sale of their works on the market or interact with certain applications. It applies not only to the market, but also to any application.

The best thing about this idea is that you can enforce it on-chain. This is something you can put in a contract that dictates 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 the market, users may approve transferring their assets and NFTs to the market, thus listing them on the market. If there is a match, the market will conduct bidding and offer, and then they will transfer the money to you as the seller and transfer the NFT from your wallet to the buyer’s wallet. This market is actually operating as an on-chain smart contract.

You can use the operator filter to block them. It does two cool things. The first thing is to block specific addresses. You can consider the market as an on-chain smart contract, which is located at a specific address, and I can directly ban this address. But we also know that others can redeploy the code and bypass your ban list. A clever solution is code hash, which is the 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 it. So even if someone copies the market 30 times on-chain, it doesn’t matter, the block list will still block them.

So how do we set up filtering? As a creator or project, you have two options. The first option is that you can plan your own blocklist and trust yourself. You can become an excellent on-chain detective. You can understand the latest developments in every market and application. You can understand the latest developments in every market and application, decide whether to interact your virtual currency with the application, and create your own blocklist on the chain.

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

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

Summary

As we initially said, 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 the chain, and then, if we can get closer to enforcement.

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

Finally, the discussion about royalties is 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 want to create an NFT, make sure it is scalable. Scalable is completely different from upgradable, and for any technician, you know that you can easily create an upgradable smart contract. This is certainly an option, but if you don’t want to do it because you don’t want to have all the control and want to do more in 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, centralized royalty registries, and their NFTs are also scalable. You can add plugins to your NFTs. In the example of operator filters, you need to complete a lot of on-chain code. If I had released a centralized NFT a few months ago, and the operator filter had not yet appeared at that time, because of the structure of the contract, it would be very easy for me to add plugins and use operator filters in that contract. So you should give yourself this selectivity, because we really don’t know what will happen in the future.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!