OpenSea has just announced changes to their royalty model, which includes blacklisting known zero-royalty markets.
Let’s talk about how OpenSea does filtering, the features they add, and whether filtering can still be circumvented.
Here are the highlights of Opensea’s official announcement:
“Today, we’re launching a tool for on-chain royalties on new collectibles. This tool is our first on-chain execution version. Starting Tuesday, November 8 at 12 p.m. ET, OpenSea will enforce royalties only on new collectibles that use on-chain execution tools such as these. Over the next few months, we’ll be rolling out more tools and improvements for on-chain execution, and we’ll be working with the community to get feedback along the way.
We recognize that this is the first step, so we are committed to communicating with our community about solutions for existing collectibles. Considering how difficult it is to charge on-chain fees for existing NFT collections, we won’t be making any changes to existing collections until at least December 8, 2022. For the sake of transparency, considerations for what happens after December 8 are completely open – we’re considering a variety of options, from continuing to enforce off-chain fees for certain subsets of collections, to allowing optional royalties, to cooperating with other on-chain enforcement options for creators. We recognize that not all creators, NFT collectibles, and communities are the same, and we wanted to create a long-term policy that reflects this.
On-chain execution tools for new NFT collections
Our initial on-chain tool is a simple code snippet that creators can add to future NFT contracts as well as existing upgradeable contracts. This code restricts NFT sales to markets that impose royalties. Starting Tuesday, November 8 at 12 noon ET, OpenSea will check new NFT collectibles to see if their items can be sold on the market without mandatory royalties. OpenSea will impose royalties on new collections that use on-chain execution tools. OpenSea does not enforce royalties for new collections that do not implement on-chain execution.
To add this code to a new or upgradeable contract, follow the instructions here.
There’s no doubt that a technical decision like this involves a trade-off: enforcing royalties on-chain requires sacrificing some of the censorship-resistant and permissionless nature of NFTs. Nonetheless, we believe that creators should have the right to build the collections and communities they want, and buyers and sellers should continue to be free to choose which NFT collectibles they participate in and don’t participate in. ”
Their code is already open source: https://github.com/ProjectOpenSea/operator-filter-registry.
The file that contains most of the filtering logic is here: https://github.com/ProjectOpenSea/operator-filter-registry/blob/main/src/OperatorFilterRegistry.sol.
As we can see in the screenshot below, this code uses a very similar principle to the QQL blacklist. For those unfamiliar, the QQL blacklist works by checking if a given operator (the contract that facilitates the transfer) has been blacklisted.
When transferring on-chain, the function (line 56) is called to ensure that the operator and the operator’s codehash are not blacklisted. The NFT contract needs to be inherited from the OperatorFilter class:https://github.com/ProjectOpenSea/operator-filter-registry/blob/main/src/example/ExampleERC721.sol#L14.
There are two main differences between OpenSea’s approach and QQL’s approach.
The first difference is that OpenSea has a built-in subscription feature, which allows any contract to subscribe to an existing blacklist. The subscription logic is on lines 114 and 309. Projects do not maintain their own blacklists, but use existing blacklists.
OpenSea will have its own list, but projects do not need to use this list. However, projects must filter out specific addresses to be eligible for royalties (i.e. blur, looksrare, x2y2, and Sudoswap addresses).
The second difference is that OpenSea’s logic also checks if an operator’s codehash is blocked. Codehash is essentially a unique identifier for the actual contract code. If someone wants to bypass address blocking, they can deploy the contract to multiple addresses.
This is no longer possible because OpenSea’s code checks the contents of the contract itself (line 70).
But in theory, this check can still be bypassed by making small changes to the code so that the codehash changes.
Ultimately, it’s almost impossible to implement a blacklist to block every contract you want to block. There are many ways to write/deploy contracts to bypass these checks. However, this blacklist should be very effective.
This is how OpenSea filtering works. I’m curious to know what decisions they make in the future, and how pervasive creator royalties will be in the future.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/opensea-launches-on-chain-mandatory-royalty-tool-is-the-nft-market-going-to-change/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.