EIP-2981 (NFT Royalty Standard)

The standard introduces a single, mandatory function: royaltyInfo(uint256 _tokenId, uint256 _salePrice). This function returns the royalty recipient address and the royalty amount to be paid for a given token and sale price. It enables marketplaces to query and execute payments without prior knowledge of the creator's payment structure.

Leading NFT marketplaces have integrated EIP-2981 to enforce creator royalties. Key adopters include:

• OpenSea: Uses it as the primary method for honoring creator-set fees on its Seaport protocol.
• LooksRare & Blur: Query the standard, though their enforcement policies vary.
• Rarible: Supports it within its marketplace aggregator. This widespread integration creates a baseline for royalty compliance across the ecosystem.

NFT collections implement EIP-2981 by adding the royaltyInfo function to their token contract (e.g., ERC-721 or ERC-1155). Common patterns include:

• Fixed Percentage: A global royalty for all tokens (e.g., 5%).
• Token-Level Customization: Royalties stored per token in a mapping.
• Tiered Systems: Royalty rates based on token traits or collection tiers. Libraries like OpenZeppelin's ERC2981 provide a base implementation for developers.

EIP-2981 is an on-chain standard but is not automatically enforced; compliance depends on marketplace integration. Key limitations have led to supplementary solutions:

• Operator Filter Registries (EIP-2981+): Allow creators to block sales on non-compliant marketplaces.
• Royalty Enforcement Layers: Protocols like Manifold's Royalty Registry act as an on-chain directory for overriding or supplementing the basic standard.
• Off-Chain Agreements: Some ecosystems use signed messages to define terms outside the smart contract.

By providing a predictable, automated revenue stream, EIP-2981 fundamentally shifts NFT business models. It enables:

• Sustainable Income: Creators earn a percentage of all secondary sales in perpetuity.
• Programmable Splits: Royalties can be split between multiple parties (e.g., artist, studio, DAO) directly within the royaltyInfo function.
• Transparent Attribution: The on-chain record clearly links revenue to the original creator's address.

EIP-2981 interacts with and is often extended by other Ethereum Improvement Proposals:

• ERC-721 & ERC-1155: The core NFT standards it augments.
• EIP-5516: A proposed standard for soulbound tokens that could integrate royalty logic.
• EIP-5496: A proposed standard for multi-privilege management, which could govern royalty settings. Understanding these relationships is key for developers building complex NFT ecosystems.

EIP-2981 is an informational standard, not an enforcement mechanism. It provides a royaltyInfo function that returns a recipient address and amount, but it does not automatically transfer funds. Enforcement depends entirely on the marketplace or protocol integrating the standard. This creates a trust dependency on secondary market operators to honor the returned values.

The royaltyInfo function is called during a sale transaction, making it a potential attack vector. Key considerations:

• Reentrancy Guards: The function should be view/pure to prevent state changes, but custom logic must be audited.
• Gas Limits: Complex royalty calculation logic (e.g., tiered royalties) can run out of gas, causing transaction failures. Implementations should be gas-efficient and have predictable upper bounds.
• Input Validation: The function must safely handle the _salePrice parameter and any other inputs.

Royalty parameters (recipient, basis points) are often set by a contract owner or admin. This introduces centralization risks:

• Privileged Function Control: A compromised admin private key could redirect all future royalty payments.
• Upgradeable Contracts: While useful for fixing bugs, upgradeable implementations add complexity and potential proxy contract vulnerabilities.
• Immutable Alternatives: Some projects use immutable, constructor-set royalty parameters to eliminate admin risk, sacrificing future flexibility.

EIP-2981 must coexist with core NFT standards, leading to integration challenges:

• ERC-721 & ERC-1155: The royalty function is an optional extension. Marketplaces must check for interface support (IERC2981).
• Conflicting Standards: Competing royalty proposals (like Manifold's) can cause fragmentation. Contracts may implement multiple standards, but logic must be consistent to avoid returning different values.
• Marketplace Adoption: The standard's effectiveness is directly tied to its integration by major marketplaces like OpenSea, Blur, and LooksRare.

Dynamic royalty schemes that rely on external data are vulnerable to manipulation:

• On-Chain Data: Using a value like the current ETH/USD price from an oracle introduces oracle risk. A manipulated price feed could distort royalty amounts.
• Off-Chain Logic: If the salePrice is not the sole determinant (e.g., royalties based on trader reputation), the logic becomes more complex and potentially exploitable.
• Front-Running: While the function is view, transactions that depend on its output could be front-run if the state changes between simulation and execution.

Robust implementation requires thorough testing strategies:

• Unit Tests: Verify royaltyInfo returns correct values for various sale prices and token IDs.
• Integration Tests: Test interactions with marketplace mock contracts to ensure proper payment flow.
• Fuzz Testing: Use tools like Echidna or Foundry's fuzzing to test with random, high-volume _salePrice inputs.
• Formal Verification: For high-value contracts, consider using formal methods to mathematically prove the correctness of royalty logic.

The mechanisms that ensure royalty payments are actually collected. EIP-2981 is a permissionless standard that reports a royalty amount but does not enforce payment. Enforcement is typically handled by:

• Marketplace Compliance: Major platforms (e.g., OpenSea, Blur) voluntarily implement the standard.
• Smart Contract Enforcement: Creator-owned NFT contracts can embed logic to restrict transfers to non-compliant exchanges.
• Operator Filter Registries: Systems like OpenSea's allow creators to blacklist marketplaces that do not respect royalties.

The foundational non-fungible token (NFT) and multi-token standards upon which EIP-2981 operates. EIP-2981 is implemented as an extension to these standards.

• ERC-721: The standard for unique, indivisible NFTs. EIP-2981 adds a royaltyInfo function to these contracts.
• ERC-1155: A standard for semi-fungible tokens, allowing both unique NFTs and fungible collections in a single contract. It can also implement the EIP-2981 interface. The royaltyInfo function returns the recipient address and royalty amount for a given token sale.

Transactions where an NFT is sold by someone other than the original creator or issuer. EIP-2981 is specifically designed to facilitate royalty payments on these sales.

• Primary Sale: The initial mint/purchase from the creator. Royalties typically do not apply.
• Secondary Sale: Any subsequent resale on a marketplace. This is where the royaltyInfo function is called by the marketplace to determine the fee owed to the original creator or rights holder. Royalties are calculated as a percentage of the sale price.

The location of royalty information affects decentralization and reliability.

• On-Chain Royalties: The royaltyInfo logic and recipient are embedded in the NFT's smart contract code (EIP-2981). This is immutable and trustless.
• Off-Chain Royalties: Royalty parameters are stored on a centralized server or an NFT marketplace's database. This is mutable and requires trust in the host. EIP-2981 promotes on-chain royalties, making the terms verifiable and enforceable by any compliant platform.

The distribution of royalty revenue to multiple parties. While EIP-2981 specifies a single recipient address, that address can be a smart contract designed to split payments.

• Splitting Contracts: Addresses like 0xSplit or custom payment splitter contracts receive the royalty and automatically distribute it to a predefined list of addresses (e.g., multiple artists, a DAO treasury, or charity).
• Pro Rata Distribution: Funds are split according to fixed percentages or weights set in the splitting contract, automating revenue sharing.

How exchanges and platforms interact with the EIP-2981 standard. For royalties to be paid, marketplaces must actively support the standard.

• Integration Flow: When a sale occurs, the marketplace calls the NFT contract's royaltyInfo function, receives the payment details, and forwards the calculated amount to the designated recipient.
• Optional Compliance: As a standard, adoption is not mandatory. Some marketplaces may choose to ignore it, leading to royalty evasion.
• Fee Abstraction: The royalty is often deducted from the seller's proceeds and paid automatically before the seller receives funds.