Royalty Standard (ERC-2981)

The Royalty Standard (ERC-2981) is an Ethereum Request for Comments (ERC) that defines a standardized, on-chain method for Non-Fungible Token (NFT) smart contracts to signal royalty payment information to marketplaces and other ecosystem participants. It provides a single, universal function, royaltyInfo(), that returns the recipient address and the royalty amount due for a given token sale price. This solves a critical interoperability problem, as prior to its introduction, marketplaces relied on disparate, often off-chain methods to determine and enforce creator fees, leading to fragmentation and non-payment.

The core mechanism of ERC-2981 is elegantly simple. When a marketplace executes a secondary sale, it calls the royaltyInfo(uint256 tokenId, uint256 salePrice) function on the NFT's smart contract. The contract logic returns two values: the recipient (the Ethereum address to pay) and the royaltyAmount (calculated as a percentage of the salePrice). This amount is then typically sent to the recipient as part of the same transaction. The standard is permissionless and backwards compatible, meaning it can be added to existing NFT contracts via upgrade patterns and does not interfere with other standards like ERC-721 or ERC-1155.

A key design feature is its flexibility. Royalties can be implemented in various ways: as a fixed percentage (e.g., 5% of all sales), a tiered structure based on sale price, or even a custom logic that varies by token ID or other on-chain conditions. However, ERC-2981 is an information standard, not an enforcement standard. It defines how to communicate royalty data, but it does not force marketplaces to pay them. Enforcement ultimately depends on marketplace compliance and, increasingly, on supplemental mechanisms like operator filter registries that restrict trading to compliant platforms.

The adoption of ERC-2981 has become a benchmark for creator-centric NFT ecosystems. Major marketplaces like OpenSea, LooksRare, and Blur have integrated support, querying the standard to display and process royalty payments. For developers and CTOs, implementing ERC-2981 involves adding the royaltyInfo function and associated logic to an NFT's minting contract, often using widely-audited libraries from OpenZeppelin. This provides a clear, on-chain record of the creator's intended compensation, forming a foundational layer for sustainable digital asset economies.

ERC-2981, or the NFT Royalty Standard, is an Ethereum Request for Comment (ERC) that defines a standardized, on-chain method for non-fungible token (NFT) smart contracts to communicate royalty payment information to marketplaces and other secondary sale platforms. It introduces a single, mandatory function, royaltyInfo(uint256 tokenId, uint256 salePrice), which returns the recipient address and the royalty amount for a given token and sale price. This function acts as a universal API that any compliant marketplace can query to discover and execute royalty payments automatically, ensuring creators are compensated on secondary sales without relying on off-chain agreements or platform-specific policies.

The core logic resides within the royaltyInfo function. When a marketplace is processing a secondary sale, it calls this function, passing the specific tokenId and the final salePrice. The smart contract's internal logic then calculates the royalty, typically as a percentage of the sale price, and returns the result. For example, a contract might be programmed to send 5% of any sale to the original creator's wallet. This design allows for flexible implementation: royalties can be a fixed percentage, a fixed amount, or determined by complex logic based on the token ID or sale price, all while maintaining a consistent external interface for marketplaces.

A key innovation of ERC-2981 is its support for royalty splits and complex payout structures. The returned recipient address is not limited to a single wallet; it can be a smart contract itself, such as a multi-signature wallet or a custom payment splitter contract. This enables automatic distribution of funds among multiple parties—for instance, splitting royalties between an artist, a co-creator, and a DAO treasury. By encoding this logic on-chain, ERC-2981 removes the need for manual, post-sale distribution and provides a transparent, immutable record of the royalty terms attached to each NFT.

For maximum compatibility, ERC-2981 is designed to be backwards compatible with the widely adopted ERC-721 and ERC-1155 NFT standards. An NFT collection can implement ERC-2981 alongside its core token logic, adding royalty functionality without breaking existing integrations. Furthermore, the standard includes an optional supportsInterface function check, allowing platforms to easily detect if a contract supports royalties. While the standard enforces the reporting of royalties, it does not enforce their payment; it remains the responsibility of the marketplace or exchange to respect the information returned by the contract and forward the funds.

The core of an ERC-2981 implementation is the royaltyInfo function, which must return the recipient address and royalty amount for a given token sale. A basic implementation stores a default royalty for all tokens in the collection, as shown in the following minimal contract snippet:

solidityCopy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/interfaces/IERC2981.sol";

contract BasicERC2981 is IERC2981 {
    address private royaltyRecipient;
    uint96 private royaltyBasisPoints; // e.g., 500 = 5%

    function royaltyInfo(uint256 /*tokenId*/, uint256 salePrice)
        external
        view
        override
        returns (address receiver, uint256 royaltyAmount)
    {
        royaltyAmount = (salePrice * royaltyBasisPoints) / 10000;
        receiver = royaltyRecipient;
    }
}

This contract imports the official interface, declares storage for the recipient and fee (in basis points), and calculates the royalty as a percentage of the salePrice.

For more advanced use cases, such as token-specific royalties, the implementation must override the function to check a per-token mapping. This allows certain NFTs within a collection to have unique royalty settings, which is common for 1/1 artworks or special editions. The logic typically involves checking a _tokenRoyalties mapping first, and falling back to a default if no specific override exists. It is critical that the function correctly handles the salePrice parameter passed by the marketplace, which should be the final sale price in the native token (e.g., ETH). The returned royaltyAmount must be in the same denomination.

Integrating ERC-2981 with existing NFT contracts like ERC-721 or ERC-1155 requires multiple inheritance. A common pattern is to use OpenZeppelin's base contracts and mixins, such as ERC721 and ERC2981. Developers must also consider gas optimization—storing royalties per token ID is flexible but expensive, while a single global royalty is cheap but inflexible. Furthermore, the standard includes a supportsInterface function; compliant contracts must return true for both the NFT interface ID (0x80ac58cd for ERC-721) and the royalty interface ID (0x2a55205a for ERC-2981) to signal full compatibility to marketplaces and other protocols.

ERC-2981 is an Ethereum Request for Comments (ERC) standard that defines a universal, on-chain method for non-fungible tokens (NFTs) to declare royalty payment information. It provides a smart contract interface—a royaltyInfo function—that returns the recipient address and the royalty amount due for a given sale price, enabling marketplaces and other platforms to programmatically discover and pay creator fees. This standard was created to address the fragmented and often broken royalty enforcement landscape that emerged in the early NFT ecosystem, where reliance on off-chain metadata or platform-specific policies led to inconsistent payments and creator revenue loss.

The standard's development was a direct response to the limitations of its predecessor, ERC-721, which lacked any native royalty specification. Prior to ERC-2981, royalties were typically enforced through a combination of mutable metadata, centralized marketplace policies, and bespoke contract logic, creating a system vulnerable to circumvention on secondary markets that chose not to honor them. By embedding royalty logic directly into the token's smart contract, ERC-2981 aims to make royalty payments a permissionless and verifiable feature of the asset itself, moving away from trust-based, off-chain agreements.

Technically, the royaltyInfo(uint256 _tokenId, uint256 _salePrice) function returns two values: the receiver (the address to pay) and the royaltyAmount (the fee to pay, calculated from the _salePrice). This amount is typically expressed as a fraction of the sale price using a basis points system (e.g., 500 basis points = 5%). A key design principle is backwards compatibility; it can be implemented as an extension to existing ERC-721 and ERC-1155 contracts, allowing older collections to upgrade and new collections to build it in from inception.

While ERC-2981 establishes a critical on-chain signal, its effectiveness depends on marketplace adoption. A marketplace must integrate support for querying the royaltyInfo function and routing the calculated payment to the designated recipient. It does not, however, enforce payment at the protocol level; a marketplace can technically ignore the signal. This has led to the development of more complex, enforcement-focused mechanisms like operator filter registries, which are often used in conjunction with ERC-2981 to restrict sales to compliant marketplaces.

The standard's impact extends beyond simple fee collection. It provides a foundational layer for complex royalty structures, enabling splits between multiple recipients (e.g., creator, platform, charity) and dynamic royalties that can change based on the token ID or sale conditions. As the dominant on-chain royalty standard, ERC-2981 has been widely adopted across major EVM chains including Polygon, Arbitrum, and Optimism, becoming a cornerstone for sustainable creator economies in web3.