OpenSea supports ERC721-C transaction functionality through Seaport Hooks, ensuring revenue for creators.

share
OpenSea supports ERC721-C transaction functionality through Seaport Hooks, ensuring revenue for creators.

After the upgrade in Cancun, OpenSea recently introduced Seaport Hooks, allowing creators to set trading conditions for NFT transactions. The first Hooks feature officially launched is to support the long-discussed ERC721-C in order to ensure that creators receive the royalties they deserve.

Background: ERC721-C

Royalty rules are not written in ERC721

Since royalty distribution for NFTs was not included in the core code of ERC721 and ERC1155 standards from the beginning, royalties were mostly distributed by contracts of NFT exchanges. However, this has led to inconsistent and chaotic royalty implementations across different markets.

For example, in the past, Blur waged war against OpenSea using optional royalty rules, and OpenSea eventually compromised by enabling optional royalty rules. However, later on, Magic Eden collaborated with Yuga Labs to launch a mandatory royalty market, and so forth.

Magic Eden established a royalty alliance, and several NFT projects successively withdrew from OpenSea and Blur.

The above phenomena indicate that creators or NFT contract creators do not have the authority to determine their own income.

ERC721-C: Bringing royalty rules on-chain

Therefore, in May of last year, the Limit Break team introduced a new NFT standard that inherits ERC721—ERC721-C to the industry, integrating royalty rules into NFT contracts. It also supports various related settings, such as custom royalties, sharing royalties with creators, and programmable royalty rules, for instance, setting addresses holding for a year exempt from royalties.

The most significant change with ERC721-C is that once royalty rules are written into the NFT contract, creators' earnings will not be diminished regardless of where the transaction takes place.

ERC721-C operational framework Source

ERC721-C and ERC1155-C are fully compatible with existing standards, allowing creators to choose their trading platform and interact only with contracts they consider secure and useful.

OpenSea to Enable ERC721-C Functionality

OpenSea announced that creators can now set up and execute ERC721-C contracts on OpenSea to protect their creative income.

Seaport Hooks: Custom NFT Trading Plugins

Two weeks ago, the team introduced Seaport v1.6, introducing the concept of Seaport Hooks. Seaport Hooks allow creators to set conditions that need to be met before transferring their NFTs or construct other trading modes for NFT transactions, somewhat similar to Uniswap V4's Hooks mechanism. For more information, refer to the official documentation.

Uniswap V4 is expected to be released in Q3. What changes will Hooks bring?

Seaport Hooks: The NFT trading version of Uniswap Hooks.

Seaport Hooks Will Introduce ERC721-C

The first Seaport Hooks promoted by the official team enables creators to customize fees to obtain the mandatory royalty functionality of ERC721-C.

Whether or not creators have income, the original ERC721-C contracts cannot be traded on existing contracts on OpenSea. Through the functionality of Seaport Hooks, ERC721-C can be introduced to OpenSea, but the owner of the NFT contract must set the compatibility of ERC721-C in OpenSea Creator Studio.

Why is OpenSea only implementing these features now? This is because the Seaport Hooks feature is enabled by new code introduced in the recent Ethereum network upgrade, Dencun, which is also known as the Cancun upgrade.

Recommended reading: What impact does the Cancun upgrade have on users? Key points from the offline meetup at Ramble Bar
Reason for recommendation: The article mentions that besides the well-known EIP-4844, the Cancun upgrade also made changes to the underlying OPCode, which helps understand why Uniswap Hooks and Seaport Hooks were introduced recently.

Starting today, creators can deploy NFTs compatible with ERC721-C through OpenSea Creator Studio to obtain mandatory royalty functionality if the contract is compatible. For more information, please refer to the official documentation.