Optional Royalty

Unlike enforced royalties embedded in the NFT's smart contract (e.g., ERC-2981), optional royalties rely on the goodwill and policy of the marketplace. Major platforms like Blur and OpenSea have implemented filters that honor royalties only for collections that enforce them on-chain, making payment a choice for traders on other platforms.

• Key Distinction: The fee logic resides in the marketplace's application layer, not the NFT's core contract logic.

To incentivize royalty payment, ecosystems developed tools allowing creators to penalize non-compliant platforms. The primary method was the creator-owned blocklist, where collections could deny trading on marketplaces that didn't enforce their fees.

• Example: OpenSea's Operator Filter Registry let creators block listings on marketplaces that bypassed their royalty settings. This approach was sunset after being deemed non-enforceable at the protocol level.

Optional royalties created a fundamental conflict between creator revenue models and trader liquidity preferences. This led to a "race to the bottom" where marketplaces competing for volume had incentives to make royalties optional or set them to 0%.

• Result: A shift in market structure, pushing innovation toward new enforceable royalty standards (like ERC-2981 with on-chain enforcement) and alternative monetization models for creators.

Optional royalties highlight the difference between technical enforcement and social consensus in web3 economics. While the Ethereum protocol itself does not mandate fees, previous market norms created an expectation of payment.

• Core Issue: It separates the asset's transfer mechanism (handled by the ERC-721 standard) from its commercial terms, placing the burden of enforcement on secondary infrastructure rather than the foundational ledger.

Traditional royalty systems rely on specific enforcement points that optional protocols circumvent:

• Marketplace-Level Enforcement: The platform's smart contract checks for and forwards royalties. Optional marketplaces simply omit this logic.
• Transfer Hook Enforcement: A smart contract (like ERC-721) calls a function on the NFT contract during transfer to validate and execute payments. Optional standards bypass these hooks.
• Registry-Based Enforcement: A central registry (e.g., EIP-2981) defines fees. Wallets or marketplaces can choose to ignore the registry's response.

ERC-2981 is a critical NFT royalty standard that provides a standardized, on-chain way to query royalty information but does not enforce payment. Its function royaltyInfo(tokenId, salePrice) returns the recipient address and fee amount.

Key for Optionality: Because it is a read-only standard, marketplaces can call this function, receive the fee data, and then programmatically choose to ignore it, making royalties truly optional at the application layer.

An enforcement mechanism where NFT contracts maintain a list of approved marketplace addresses. Transfers to non-approved operators (marketplaces) are blocked.

How Optionality Breaks It:

• Marketplaces can use proxy contracts or other technical workarounds to appear as an approved operator.
• Projects like Blur incentivized the creation of NFTs with blocked operator filters, effectively making the registry obsolete for new collections.
• This led to a technical arms race between enforcement and circumvention.

A direct technical method to bypass royalties involves manipulating the token transfer flow.

• Standard Flow: User -> Marketplace Contract -> NFT Transfer (with fee) -> New Owner.
• Bypass Flow: Traders use a private sale or a proxy contract to transfer the NFT peer-to-peer, then settle the financial terms off-chain or in a separate transaction. This severs the link between the asset transfer and the payment, making fee detection impossible.

The design of the marketplace's core smart contract dictates royalty behavior.

• Enforcing Marketplace: Has logic to call royaltyInfo, calculate the fee, and transfer that amount to the creator before sending the remainder to the seller.
• Optional Marketplace: Executes a simple swap: it transfers the NFT to the buyer and the payment to the seller in a single atomic transaction, with no intermediary logic to handle a separate royalty payment. The fee is effectively set to zero.

User-facing applications play a key technical role. Aggregators (like Blur, Gem) query multiple marketplaces and present the best price, which is often on platforms with zero royalties.

Their smart order routers are programmed to prioritize total cost, inherently favoring optional-royalty listings. This creates network effects where liquidity migrates to the lowest-fee venues, forcing technical adoption of optional standards across the ecosystem.

A fee, typically a percentage of the secondary sale price, paid to the original creator or rights holder of an NFT. This is the foundational economic right that optional royalty systems make enforceable at the protocol level. Key aspects include:

• On-chain vs. Off-chain: Historically enforced via marketplace policy, now moving to smart contract logic.
• Royalty Standards: Implemented through extensions like EIP-2981 for ERC-721 tokens.
• Value Proposition: Provides ongoing revenue for creators, aligning incentives with long-term project success.

The technical and economic mechanisms that ensure royalty payments are collected during NFT transfers. This is the core problem optional royalties aim to solve. Methods include:

• Transfer Hooks: Smart contract functions that execute logic (like fee payments) on every transfer.
• Marketplace Cooperation: Reliant on platforms to read and respect on-chain royalty specifications.
• Blocklist/Allowlist: Restricting trades to specific marketplaces that enforce the creator's terms.

A design pattern where transaction fees (like royalties) are paid by a party other than the primary transacting user, often abstracted into the token's economics. This improves user experience by:

• Hiding Complexity: Users see a net price without manually calculating royalties.
• Sponsoring Transactions: Protocols or dApps can subsidize fees to drive adoption.
• Relating to Optional Royalties: It represents an alternative UX approach, but doesn't remove the underlying fee obligation.

A decentralized NFT marketplace built on an Automated Market Maker (AMM) model. It is a canonical example of royalty-optional design because:

• Zero-Fee Default: The protocol itself charges no fees and does not enforce creator royalties.
• Pool-Based Trading: Liquidity is provided in pools, divorcing trades from traditional marketplace fee structures.
• Market Impact: Its popularity pressured other platforms to adopt similar optional models to remain competitive.

An Ethereum Improvement Proposal that defines a standardized, on-chain way to retrieve royalty payment information for NFT sales. It is the primary technical foundation for optional royalties.

• royaltyInfo Function: A smart contract method that returns the recipient address and royalty amount for a given sale price.
• Interoperability: Allows any marketplace to query and respect royalties consistently.
• Optional Compliance: The standard provides the data; enforcement is still up to the marketplace or transfer mechanism.