EIP-2981

EIP-2981: NFT Royalty Standard is an interface that allows an NFT smart contract to signal how royalty payments should be distributed to its creators or rights holders whenever the NFT is sold on a secondary market. The core function, royaltyInfo(uint256 tokenId, uint256 salePrice), returns the recipient address and the royalty amount for a given sale price. This provides a universal, on-chain mechanism for marketplaces to query and automatically execute royalty payments, moving beyond off-chain metadata or platform-specific implementations.

The proposal addresses a critical need for creator sustainability in the NFT ecosystem by embedding royalty logic directly into the token's contract. Prior to its adoption, royalty enforcement was fragmented and relied on the voluntary compliance of individual marketplaces. EIP-2981 establishes a standardized data structure that any compliant marketplace can integrate, ensuring creators receive a programmable percentage (e.g., 5-10%) of all subsequent sales. This is a significant shift from the initial sale model, enabling ongoing revenue for artists and projects.

Implementation involves the NFT contract returning two values: the recipient (the address to pay) and the royaltyAmount (calculated as a function of the salePrice). The royalty can be a fixed amount or a percentage, and it can even vary per token ID within a collection. While EIP-2981 sets the standard for signaling royalties, it does not enforce payment; enforcement depends on marketplace integration. Major platforms like OpenSea, LooksRare, and Rarible have adopted this standard, making it the de facto method for on-chain royalty information.

It's important to distinguish EIP-2981 from enforcement mechanisms. The standard is a read-only function—it informs a marketplace of the royalty details but does not automatically transfer funds. Some marketplaces may choose to ignore it, leading to the development of more complex, enforceable alternatives. However, its widespread adoption has made it a foundational layer for NFT economics, providing a clear, contract-level specification for creator compensation that is independent of any single platform's policies.

EIP-2981 is an Ethereum Improvement Proposal (EIP) that establishes a standardized, on-chain interface for NFT Royalties. The '2981' is its unique sequential identifier within the EIP repository, following proposals like EIP-721 (NFTs) and EIP-1155 (Multi-Token). The proposal's title, "NFT Royalty Standard," directly describes its purpose: to create a predictable, universal way for smart contracts to signal how royalties should be paid to creators on secondary sales. This naming convention follows the Ethereum ecosystem's practice of using descriptive titles and numerical IDs for technical specifications.

The concept's origin lies in addressing a critical gap in the initial NFT standards. While EIP-721 and EIP-1155 defined how to create and transfer non-fungible tokens, they did not include a native mechanism for enforcing or even reporting royalty payments. Prior to EIP-2981, royalty logic was implemented in an ad-hoc manner by individual marketplaces or within custom contract code, leading to fragmentation and incompatibility. The proposal was authored by Zach Burks, James Morgan, Blaine Malone, and James Seibel, and was motivated by the need for composability and interoperability across the entire NFT ecosystem, from minting platforms to decentralized exchanges.

EIP-2981 functions as an extension to existing token standards. It introduces a single, straightforward function: royaltyInfo(uint256 tokenId, uint256 salePrice). This function returns the royalty recipient's address and the amount to be paid, calculated from the sale price. By standardizing this how-to-pay signal, it allows any marketplace or smart contract to programmatically discover and respect creator royalties without prior integration with specific NFT contracts. This design is etymologically and functionally an interface, a core software concept defining a contract's external calls, making it a natural fit for Ethereum's smart contract environment.

The adoption of EIP-2981 has made "royaltyInfo" a key term in the NFT developer lexicon. Its implementation does not enforce payments—that is left to the marketplace or exchange executing the sale—but it provides the necessary and authoritative data for enforcement. This standard has become foundational, influencing subsequent discussions and proposals around royalty enforcement mechanisms (like EIP-5218) and is widely supported by major NFT platforms. Its origin story is a classic example of the Ethereum community identifying a market-wide need and collaboratively developing a minimal, elegant standard to solve it.

EIP-2981 introduces a simple, gas-efficient function called royaltyInfo that any smart contract can implement. This function takes a token's sale price and its unique ID as inputs and returns two outputs: the address of the royalty recipient (e.g., the original creator or a designated wallet) and the exact royalty amount to be paid. This mechanism operates at the smart contract level, making the royalty logic an immutable and verifiable part of the NFT's code. Marketplaces and other platforms that integrate the standard can query this function to programmatically calculate and disburse royalties during a sale, without relying on off-chain metadata or manual processes.

The standard's design is intentionally flexible to support various royalty models. It can calculate royalties as a fixed amount or, more commonly, as a percentage of the sale price. For example, a contract might specify a 5% royalty, so a sale for 10 ETH would return 0.5 ETH as the royalty amount. Crucially, EIP-2981 is per-token aware, meaning royalty rates and recipients can be configured individually for each NFT within a collection, allowing for unique terms per artwork or edition. This is a significant advancement over blanket collection-wide rates.

For the ecosystem, EIP-2981 solves a critical interoperability problem. Before its adoption, each marketplace had its own proprietary and often off-chain method for handling royalties, leading to fragmentation and enforcement issues. By providing a universal, on-chain interface, it allows any compliant marketplace—from OpenSea to a niche decentralized application—to discover and honor the creator's intended royalties automatically. This creates a more reliable and fair revenue stream for creators, as the payment logic is enforced by the blockchain itself whenever a sale occurs on an integrated platform.

The following Solidity code provides a minimal, standards-compliant implementation of the EIP-2981: NFT Royalty Standard. It defines a RoyaltyInfo struct and implements the required royaltyInfo function, which returns the recipient address and royalty amount for a given token sale price. This function is invoked by marketplaces and other platforms to automatically pay out royalties to creators on secondary sales. The example uses a fixed royalty basis points (e.g., 500 for 5%) and a single recipient for simplicity, but more complex logic can be built on this foundation.

Key components of the implementation include: the supportsInterface function for ERC-165 interface detection, ensuring compatibility; the royaltyInfo function signature (uint256 _tokenId, uint256 _salePrice); and the calculation royaltyAmount = (_salePrice * royaltyBasisPoints) / 10000. The royalty amount is derived by multiplying the _salePrice by the royaltyBasisPoints (where 10,000 basis points equals 100%) to ensure precision without floating-point numbers. This function must return the payment recipient and the calculated amount.

To integrate this, a marketplace's smart contract would call the royaltyInfo function on the NFT contract using a static call. For instance, OpenSea, Rarible, and other major platforms query this function to determine how much ETH or other currency to send to the royaltyRecipient when an NFT is sold. Developers can extend this pattern to support per-token or per-tier royalty configurations by modifying the logic inside royaltyInfo, perhaps by reading from a mapping that stores settings for individual _tokenId values.