The Minimum Royalty Standard (EIP-2981) is an Ethereum Improvement Proposal that defines a smart contract interface for non-fungible tokens (NFTs) to specify a royalty amount to be paid to the original creator or rights holder every time the NFT is sold on a secondary market. This standard provides a universal, on-chain mechanism for royalty enforcement, allowing any marketplace or platform to query the NFT's smart contract to determine the correct recipient and payment amount. By implementing a single, agreed-upon function—royaltyInfo(uint256 tokenId, uint256 salePrice)—it solves the previous fragmentation where each marketplace used its own proprietary system, often leading to royalty non-payment.
Minimum Royalty Standard (EIP-2981)
What is Minimum Royalty Standard (EIP-2981)?
EIP-2981 is a standardized, on-chain interface for enforcing creator royalties on secondary NFT sales across all marketplaces.
The core technical specification is elegantly simple. The royaltyInfo function takes the NFT's tokenId and the salePrice as inputs and returns two outputs: the receiver address (who gets the royalty) and the royaltyAmount (the specific fee to be paid). This amount is typically calculated as a percentage of the sale price, though the standard allows for any arbitrary logic. This design ensures composability and interoperability, as decentralized applications (dApps), aggregators, and marketplaces can all rely on this single function call to programmatically honor creator fees without requiring off-chain metadata or manual configuration.
EIP-2981 is considered a "minimum" or "baseline" standard because it defines the lowest common denominator for royalty information. It does not enforce payment—that responsibility remains with the marketplace executing the sale—but it provides the necessary data for enforcement. More complex royalty structures, such as split payments to multiple parties or time-based rules, can be built on top of this foundation. Its widespread adoption by major NFT collections and marketplaces has made it the de facto technical solution for on-chain royalty enforcement in the Ethereum ecosystem, promoting a more sustainable economic model for digital creators.
How EIP-2981 Works
EIP-2981 is a standardized interface for on-chain royalty information, enabling smart contracts to programmatically declare and pay royalties to creators on secondary market sales.
EIP-2981 defines a single, mandatory function, royaltyInfo(), that any marketplace or smart contract can call. This function takes a token's sale price as input and returns two outputs: the royalty recipient's address and the royalty amount to be paid. This mechanism provides a universal, on-chain source of truth for royalty data, replacing the need for off-chain registries or manual configuration by marketplaces. The standard is designed to be gas-efficient and backwards-compatible, allowing existing NFT collections to adopt it via a simple contract upgrade.
The core logic resides in the royaltyInfo(uint256 _tokenId, uint256 _salePrice) function. Implementations can calculate royalties as a fixed amount, a percentage of the sale price, or using custom logic (e.g., tiered rates). A common pattern is to store a basis points value (e.g., 500 for 5%) and a payout address. The function multiplies the _salePrice by the basis points, divides by 10,000, and returns the resulting amount. This design ensures that royalty calculations are transparent, verifiable, and executed deterministically on-chain with every sale.
For the system to function, both the NFT contract and the marketplace must support EIP-2981. The NFT contract implements the standard to declare royalties. A compliant marketplace, such as OpenSea or LooksRare, must query the royaltyInfo() function during a sale and automatically route the calculated royalty payment to the designated recipient before finalizing the transaction. This creates a trust-minimized and enforceable royalty system where payment is a precondition of the trade, not an optional courtesy.
A key feature of EIP-2981 is its support for modular royalty logic. Beyond simple percentages, contracts can implement complex rules: royalties that change over time, split payments between multiple recipients, or dynamic rates based on the token ID or sale price. This flexibility allows for sophisticated creator economies. However, the standard is permissionless; it does not force marketplaces to respect the returned values, leading to the concept of 'royalty-enforcing' versus 'royalty-optional' marketplaces in the ecosystem.
The adoption of EIP-2981 represents a significant shift from off-chain royalty specifications. Prior methods relied on marketplace-specific registries (like OpenSea's) which were centralized and not universally honored. By embedding royalty logic directly into the NFT's smart contract, EIP-2981 empowers creators with sovereign control over their revenue streams. Its success has made it the foundational technical primitive for on-chain creator monetization, influencing subsequent standards like EIP-5496 for multi-privilege management and shaping the development of fully enforceable royalty mechanisms.
Key Features of EIP-2981
EIP-2981 defines a standardized, on-chain interface for NFT marketplaces to programmatically query and pay royalties to creators, ensuring consistent and enforceable royalty payments across different platforms.
Standardized Interface
EIP-2981 introduces a single, universal function, royaltyInfo(), that any smart contract can implement. This function takes a token's ID and sale price as inputs and returns the recipient address and the royalty amount to be paid. This standardization eliminates the need for marketplaces to implement custom, per-collection logic for royalty payments.
On-Chain Enforcement
Unlike off-chain agreements, the royalty logic is embedded directly in the NFT's smart contract code. This allows any compliant marketplace to programmatically query the contract for the correct payment details during a sale, making the royalty terms transparent, verifiable, and executable by the blockchain itself.
Flexible Royalty Logic
The standard is intentionally minimal, specifying only the interface, not the implementation. This allows creators and developers to implement complex royalty logic within the royaltyInfo() function, such as:
- Fixed percentage of the sale price.
- Tiered royalties based on sale amount.
- Dynamic recipients (e.g., splitting payments between multiple parties).
Backwards Compatibility
EIP-2981 is designed as an optional extension to existing token standards like ERC-721 and ERC-1155. NFTs that do not implement the interface are treated as having zero royalties, ensuring older collections continue to function without issue. This allows for gradual adoption across the ecosystem.
Marketplace Agnostic
The standard's primary goal is to create a universal protocol for royalty information. Any marketplace (OpenSea, Blur, LooksRare) or secondary application that integrates EIP-2981 can automatically support royalties for any compliant NFT collection, reducing fragmentation and creating a consistent experience for creators.
Limitations & Considerations
While a major step forward, EIP-2981 has key limitations:
- It is an opt-in standard; marketplaces must choose to support it.
- It cannot force payment on non-compliant marketplaces or direct peer-to-peer transfers.
- The royalty is a suggestion from the contract; the final payment execution depends on the marketplace's implementation. This has led to discussions around more enforceable mechanisms.
Minimum Royalty Standard (EIP-2981)
An exploration of the Ethereum Improvement Proposal that defines a standardized, on-chain method for enforcing creator royalties on non-fungible tokens (NFTs).
EIP-2981 is a standardized smart contract interface that allows an NFT's royalty payment information—specifying a recipient address and a royalty fee—to be read directly from the token's contract. This provides a universal, on-chain mechanism for marketplaces and other platforms to programmatically discover and honor creator royalties during secondary sales, addressing the fragmentation and optionality that plagued earlier royalty models. The proposal defines a single, mandatory function, royaltyInfo(uint256 _tokenId, uint256 _salePrice), which returns the recipient and the royalty amount for a given token and sale price.
The technical implementation is elegantly simple for both creators and integrators. For creators, implementing EIP-2981 involves adding the royaltyInfo function to their NFT smart contract (e.g., an ERC-721 or ERC-1155), where the logic can define fixed fees, tiered rates, or even dynamic calculations. For marketplaces and other intermediaries, integration is a straightforward read call to the NFT contract; they query this function with the token ID and the sale price, receiving the exact amount to send to the royalty recipient, which is then typically deducted from the seller's proceeds before settlement.
A key design principle of EIP-2981 is its per-token-id granularity, allowing royalty schemes to vary between individual tokens within the same collection. This enables use cases like special editions with higher royalty rates or collaborative works where royalties are split between multiple creators. While EIP-2981 sets a vital standard for discovering royalties, it is important to note that it is an informational standard and does not itself enforce payment; enforcement depends on the marketplace or exchange respecting the returned data and executing the transfer.
The proposal's adoption has been widespread, becoming the de facto standard for major NFT marketplaces like OpenSea and Blur, which use it to determine royalty payments. Its success lies in its minimalism and backward compatibility; it doesn't require changes to core token standards and can be added to existing collections via upgradeable contracts or wrapper logic. However, the ecosystem has evolved with supplementary standards like EIP-5496 for managing multiple royalty "splits" and more complex on-chain enforcement mechanisms to address marketplace non-compliance.
Ecosystem Adoption & Usage
EIP-2981 defines a standardized, gas-efficient way for NFTs to signal royalty information on-chain, enabling universal support across marketplaces and applications.
Core Specification
EIP-2981 is an Ethereum Improvement Proposal that defines a single, mandatory function, royaltyInfo(), which any smart contract can implement. This function returns the recipient address and royalty amount for a given token sale price. The royalty amount is expressed in basis points (bps), where 1 basis point equals 0.01% (e.g., 500 bps = 5%). This standardization allows any marketplace or protocol to query and honor royalties without prior integration.
Marketplace Integration
Major NFT marketplaces like OpenSea, Blur, LooksRare, and Rarible have integrated EIP-2981 to automatically read and pay royalties. The process is seamless:
- A user lists an NFT for sale.
- The marketplace calls the token's
royaltyInfo()function. - Upon sale, the calculated royalty is automatically sent to the designated recipient. This integration is crucial for creator revenue, as it enforces royalties in secondary sales across compliant platforms.
Flexibility & Granularity
The standard offers significant flexibility for creators and developers:
- Per-Token Royalties: Royalties can be set for individual tokens within a collection.
- Dynamic Royalties: The
royaltyInfo()logic can be programmed to change based on sale price, time, or other on-chain conditions. - Protocol-Level Support: It is adopted by major NFT standards and tooling, including ERC-721 and ERC-1155 extensions, and is supported by developer libraries like OpenZeppelin.
Limitations & Ecosystem Context
While a critical standard, EIP-2981 has key limitations in the broader royalty landscape:
- It is not enforceable: It is a signal, not a mechanism. Marketplaces must voluntarily read and pay the royalty.
- Optional vs. Mandatory: It does not make royalties mandatory; collections can implement it with a 0% return.
- Competing Standards: It exists alongside other approaches like Creator Fee Enforcement on specific chains (e.g., Solana) and marketplace-specific policies, leading to a fragmented ecosystem.
Technical Implementation Example
Here is a simplified view of the core function from a smart contract:
solidityfunction royaltyInfo( uint256 _tokenId, uint256 _salePrice ) external view returns ( address receiver, uint256 royaltyAmount ) { // Example: 5% royalty receiver = royaltyReceiver; royaltyAmount = (_salePrice * 500) / 10000; // 500 basis points }
The function is gas-efficient as it performs a simple calculation, and it is backwards-compatible—existing NFTs can upgrade to support it.
Impact on Creator Economy
EIP-2981 has become the foundational layer for programmable creator earnings on Ethereum and EVM-compatible chains. Its adoption means:
- Predictable Revenue: Creators can rely on a consistent, on-chain mechanism for secondary sales.
- Interoperability: Royalties work across any wallet, marketplace, or aggregator that reads the standard.
- Innovation Foundation: It enables complex financial products like royalty financing and royalty streaming, where future royalty cash flows can be tokenized or used as collateral.
EIP-2981 vs. Other Royalty Models
A technical comparison of the standard on-chain royalty interface against common alternative implementations.
| Feature / Metric | EIP-2981 (Standard) | Centralized Registry | Transfer-Hook Enforcement | No On-Chain Standard |
|---|---|---|---|---|
Standardization | ||||
On-Chain Royalty Data | ||||
Royalty Recipient Flexibility | ||||
Gas Efficiency for Marketplaces | High | Medium | Low | High |
Immutable After Mint | ||||
Universal Marketplace Support | ||||
Implementation Complexity | Low | Medium | High | None |
Royalty Payment Guarantee | Optional | Enforced | Enforced | None |
Security & Implementation Considerations
The Minimum Royalty Standard (EIP-2981) defines a critical interface for on-chain royalty enforcement. Its implementation requires careful attention to security, gas efficiency, and integration patterns to function correctly across diverse marketplaces and NFT contracts.
Royalty Enforcement vs. Signaling
EIP-2981 is a signaling standard, not an enforcement mechanism. It provides a standardized way for an NFT contract to declare its royalty policy, but it does not enforce payment. Marketplaces must voluntarily query and respect the returned values. This creates a trust dependency where non-compliant marketplaces can bypass payments, highlighting the need for complementary fee-on-transfer or blocklist mechanisms for stronger enforcement.
Implementation Security Risks
Incorrect royaltyInfo function implementation can lead to critical vulnerabilities:
- Reentrancy: If the function makes external calls before state updates.
- Gas Griefing: An unbounded loop over token owners in the calculation logic can be exploited to cause out-of-gas errors.
- Centralization Risk: Using a mutable admin address to set royalties creates a single point of failure and potential rug-pull vector. Best practice is to immutably set recipients and percentages at deployment or use a decentralized governance mechanism.
Gas Optimization Patterns
The royaltyInfo function is called on every sale, so gas efficiency is paramount.
- Fixed-point Math: Use
uint96for basis points and pre-calculate values to avoid expensive on-chain division. - Storage Layout: Store royalty data in packed
structsor use immutable variables if fixed. - Fail Early: Use
requirestatements at the start to revert cheaply for invalid inputs (e.g.,_salePrice == 0). - Avoid Storage Reads in Loops: A common anti-pattern when calculating royalties for batch sales or split recipients.
Marketplace Integration Checks
For a marketplace to be EIP-2981 compliant, it must:
- Call the Standard Function: Query
royaltyInfo(uint256 _tokenId, uint256 _salePrice)on the NFT contract. - Handle All Return Values: Correctly process the
receiveraddress androyaltyAmount. - Forward Payments Securely: Transfer the amount to the
receiverwithin the same transaction as the sale, typically usingtransferorcall. A critical failure mode is storing the royalty amount for later withdrawal, which introduces custodial risk.
Interoperability with Other Standards
EIP-2981 must coexist with other NFT standards, which requires careful design:
- ERC-721 & ERC-1155: The royalty function is added alongside
supportsInterface. Contracts must returntruefortype(IERC2981).interfaceId. - Creator Fee Enforcement (EIP-5791): A newer, more complex standard that can be implemented alongside EIP-2981 for backwards compatibility.
- Secondary Fee Recipients (EIP-5507): Allows splitting royalties. An EIP-2981 implementation can call into an EIP-5507-compliant contract to determine the final recipient and amount.
Testing and Verification
Rigorous testing is essential for secure royalty implementations:
- Unit Tests: Verify
royaltyInforeturns correct values for various_salePriceinputs and edge cases (zero price, max uint). - Integration Tests: Simulate marketplace interactions to ensure royalties are paid in full and to the correct address within a sale transaction.
- Formal Verification: For high-value contracts, use tools to mathematically prove the royalty logic is free of overflows and always pays ≤ sale price.
- Interface Compliance: Use
supportsInterfacechecks to confirm the contract correctly advertises EIP-2981 support.
Common Misconceptions About EIP-2981
EIP-2981 is a pivotal standard for NFT royalties, but its design and limitations are often misunderstood. This section clarifies the most frequent points of confusion to provide a precise technical understanding.
No, EIP-2981 does not enforce or guarantee royalty payments; it is a royalty reporting standard, not an enforcement mechanism. The standard defines a smart contract function, royaltyInfo(uint256 tokenId, uint256 salePrice), that returns the address and amount owed for a given sale. It is a communication layer that tells a marketplace who should be paid and how much. Actual payment is the responsibility of the integrating platform (e.g., an NFT marketplace). The standard contains no logic to block transfers or withhold funds if the royalty is not paid, making its adoption voluntary for both creators and platforms.
Key Distinction:
- Reporting: EIP-2981 provides the royalty data.
- Enforcement: Requires additional on-chain logic (like transfer restrictions) or off-platform legal agreements.
Frequently Asked Questions (FAQ)
Common questions about the ERC-2981 standard for on-chain royalty enforcement in NFTs.
EIP-2981 is an Ethereum Improvement Proposal that defines a standardized, on-chain method for non-fungible tokens (NFTs) to report royalty payments to their original creators. It works by implementing a single, mandatory function, royaltyInfo(uint256 _tokenId, uint256 _salePrice), on the smart contract. This function returns the recipient address and the royalty amount (calculated from the sale price) that a marketplace should pay on every secondary sale. This provides a universal, permissionless way for any marketplace or protocol to discover and honor creator royalties without prior integration agreements.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.