ERC-2981

ERC-2981 is a standardized smart contract interface that allows an NFT's smart contract to declare how royalties should be paid to its creators or rights holders upon secondary sales. It provides a royaltyInfo function that marketplaces and other applications can call to receive two critical pieces of data: the recipient address for the royalty payment and the royalty amount, calculated as a percentage of the sale price. This creates a universal, on-chain signal that is far more reliable than the off-chain metadata used by earlier systems.

The standard was created to solve the fragmentation and unreliability of royalty enforcement across different NFT marketplaces. Prior to ERC-2981, platforms used various ad-hoc methods, such as off-chain metadata fields or proprietary marketplace policies, which were easily ignored or manipulated. By embedding the royalty logic directly into the token's contract code, ERC-2981 provides a permissionless and verifiable standard that any compliant marketplace can query, making royalty payments more transparent and enforceable across the entire ecosystem.

A key technical feature of ERC-2981 is its flexibility. The royaltyInfo function accepts both a tokenId and a salePrice as parameters, allowing for sophisticated royalty schemes. This enables per-token customization (e.g., different royalties for different pieces in a collection) and ensures the royalty amount is always calculated dynamically based on the actual sale price. The function returns the royalty amount in the same denomination as the sale price, simplifying payment processing for marketplaces.

For developers and creators, implementing ERC-2981 involves adding the interface and the royaltyInfo function logic to an NFT's smart contract, often inheriting from a base contract like OpenZeppelin's implementation. Marketplaces and other intermediaries that integrate the standard query this function during a sale to determine the required payment. It is important to note that ERC-2981 is a signaling standard; it does not automatically enforce payments—that responsibility lies with the marketplace or exchange executing the sale.

ERC-2981 has become a foundational standard for the NFT ecosystem, widely adopted by major marketplaces including OpenSea, Rarible, and LooksRare. It is frequently implemented alongside core NFT standards like ERC-721 and ERC-1155. While it significantly improves on-chain signaling, the broader challenge of royalty enforcement—ensuring all platforms respect these on-chain signals—remains an active area of development and discussion within the community.

ERC-2981 is an Ethereum Request for Comments (ERC) standard that defines a standardized, on-chain method for signaling royalty payment information for Non-Fungible Tokens (NFTs). Its etymology is straightforward: 'ERC' denotes its status as an Ethereum improvement proposal, while '2981' is its unique sequential identifier within the EIP repository. The standard was formally proposed in September 2020 by developers William Entriken, Diemon, and Radicle, with the explicit goal of creating a universal interface that smart contracts could implement to declare royalty recipients and amounts.

The origin of ERC-2981 lies in the fragmented, off-chain royalty systems that preceded it. Prior to its introduction, NFT marketplaces and platforms relied on proprietary, centralized databases or mutable metadata to determine royalty payouts. This created a fragile ecosystem where royalties could easily be circumvented on secondary sales if a marketplace chose not to honor them. ERC-2981 emerged as a technical solution to embed this financial logic directly into the NFT's smart contract, making royalty claims permissionless and verifiable by any compliant platform.

The standard's design is an elegant example of backward compatibility. It does not replace the ubiquitous ERC-721 or ERC-1155 token standards but instead acts as an extension that existing NFT contracts can adopt. A contract implementing ERC-2981 must expose a royaltyInfo function that, when called with a sale price, returns the recipient address and the royalty amount. This mechanism allows the royalty logic to be as simple as a fixed percentage or as complex as a custom on-chain calculation, providing flexibility for creators.

The proposal and adoption of ERC-2981 marked a significant shift in the NFT ecosystem's infrastructure, moving a critical piece of creator economics from trust-based off-chain agreements to transparent, on-chain execution. Its development was influenced by the practical needs of artists, developers, and marketplace operators, culminating in a standard that has become a foundational component for responsible secondary market trading.

ERC-2981 is an Ethereum Request for Comment (ERC) standard that defines a universal, on-chain method for non-fungible tokens (NFTs) to communicate royalty payment information to marketplaces and other applications. It works by implementing a single, mandatory function, royaltyInfo(uint256 tokenId, uint256 salePrice), which any smart contract can call. This function returns two critical pieces of data: the recipient address where royalties should be sent and the royalty amount to be paid, calculated as a function of the salePrice. This standardized query allows for seamless, permissionless integration across the ecosystem.

The standard's core innovation is its backward compatibility and flexibility. It can be implemented directly in an NFT's core contract (like an ERC-721 or ERC-1155) or deployed as a separate, standalone contract that multiple NFT collections can reference. The royaltyInfo function is intentionally simple, taking only the tokenId and salePrice as inputs. This allows for complex royalty logic—such as fixed amounts, sliding scales, or different recipients per token—to be encapsulated within the function's implementation while presenting a uniform interface to the outside world.

When a secondary sale occurs on a compliant marketplace, the process is automated: 1) The marketplace calls the NFT contract's royaltyInfo function with the sale price. 2) The contract returns the recipient and amount. 3) The marketplace executes the transfer, splitting the payment between the seller and the royalty recipient. This mechanism is enforceable on-chain when integrated by marketplaces, but it is not inherently coercive; it provides the data needed for voluntary compliance. The standard does not dictate royalty rates or governance, leaving those decisions to the contract deployer.

A key technical detail is the handling of the royalty amount. ERC-2981 expresses this amount in the same base units as the sale price (e.g., wei for ETH). For a 5% royalty on a 1 ETH sale, the function would return 50000000000000000 (5e16 wei). This precision avoids rounding errors. Furthermore, the standard supports ERC-165 interface detection, allowing applications to easily check if a contract supports ERC-2981 before attempting to call it, ensuring robust integration and preventing errors.

While ERC-2981 has become the dominant standard for on-chain royalties, its effectiveness depends on marketplace adoption. Major platforms like OpenSea, LooksRare, and others query this function to facilitate automatic royalty payments. However, it is a fee-specification standard, not a fee-enforcement standard; it tells a marketplace what to pay, but does not technically force it to do so. This has led to ongoing discussions and proposals for more coercive mechanisms, but ERC-2981 remains the foundational layer for universal royalty communication in the EVM ecosystem.

The following is a minimal, non-production-ready example of an ERC-2981 compliant contract. It implements the required royaltyInfo function, which returns the royalty recipient address and the amount for a given token sale. This example uses a simple, fixed royalty percentage applied to all tokens minted by the contract, a common pattern for collections with a single beneficiary.

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

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

contract ExampleNFT is ERC721, IERC2981 {
    address private royaltyRecipient;
    uint96 private royaltyBasisPoints; // e.g., 500 for 5%

    constructor(
        string memory name_,
        string memory symbol_,
        address recipient_,
        uint96 basisPoints_
    ) ERC721(name_, symbol_) {
        royaltyRecipient = recipient_;
        royaltyBasisPoints = basisPoints_;
    }

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

    // Required override to signal interface support
    function supportsInterface(bytes4 interfaceId)
        public
        view
        virtual
        override(ERC721, IERC165)
        returns (bool)
    {
        return
            interfaceId == type(IERC2981).interfaceId ||
            super.supportsInterface(interfaceId);
    }
}

This code illustrates several key concepts. First, it imports the official IERC2981 interface from OpenZeppelin Contracts, a widely-used library for secure smart contract development. The contract inherits from both ERC721 and IERC2981, making it a Non-Fungible Token (NFT) with built-in royalty functionality. The royaltyInfo function is the heart of the standard; it takes a salePrice as input and calculates the royalty by multiplying it with the royaltyBasisPoints (where 10,000 basis points equal 100%). The function returns the pre-configured royaltyRecipient address and the calculated royaltyAmount. Notably, the tokenId parameter is ignored in this simple implementation, as the royalty scheme is uniform across all tokens.

The supportsInterface function override is critical for interoperability. Marketplaces and other smart contracts use the ERC-165 standard to query which interfaces a contract supports. By returning true for the IERC2981 interface ID, this contract explicitly announces its compliance, allowing platforms to automatically detect and honor its royalties. Without this correct override, even a perfectly coded royaltyInfo function may be ignored by downstream systems. This example uses a global royalty scheme, but more advanced implementations could store royalty information per-token or per-token-series using a mapping, enabling complex scenarios like collaborative works where royalties are split between multiple creators.