ERC-2981: How NFT royalties are defined and implemented

NFT royalties began as a social contract between creators and marketplaces. As trading matured and fee models evolved, the industry needed a consistent, on-chain way to describe royalty information that any marketplace could read. That is exactly what ERC-2981 provides: a minimal, interoperable interface for querying how much royalty is owed and to whom for any given NFT sale. This article explains what ERC-2981 is, how it works under the hood, considerations for implementation, and the current landscape of marketplace enforcement and creator monetization.

What ERC-2981 actually standardizes

ERC-2981 is an Ethereum standard that defines a single function for non-fungible tokens:

• royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

Marketplaces that honor royalties call royaltyInfo at sale time to compute the payout. The standard does not enforce payment—it only describes the interface. Enforcement is a marketplace policy question.

Key design choices:

• Percentage-based: Royalties are calculated as a function of the sale price, typically using a fraction like basis points (e.g., 500 = 5%).
• Receiver flexibility: The royalty receiver can be a creator’s address, a multisig, a split contract, or an upgradeable payout address.
• Works with ERC-721 and ERC-1155: ERC-2981 is compatible with common NFT standards and relies on ERC-165 for interface detection.

For a production-ready implementation, many teams build on OpenZeppelin’s ERC2981.

Why it matters now

Starting in 2023, several leading marketplaces shifted to optional enforcement of royalties. The most notable change was OpenSea’s decision to sunset its Operator Filter, which had previously allowed creators to restrict trading to royalty-enforcing venues; see OpenSea’s announcement. As a result, on-chain standards like ERC-2981 became the default way to surface royalty data across platforms, even as enforcement varies.

Since then, the ecosystem has responded with:

• Registry infrastructure so marketplaces can resolve royalty logic in a unified way, e.g., Royalty Registry and the associated spec.
• Programmable standards for on-chain enforcement or restrictions, notably ERC-721C (Creator Token Standards).
• Alternative earning models such as protocol-level rewards and creator incentives, for example Zora’s Creator Rewards.

In 2024–2025, adoption of ERC-2981 remains widespread across L1 and L2 networks, and marketplaces that choose to honor royalties will generally query this interface when settling trades.

How the interface works (without surprises)

At sale time, a compliant marketplace performs:

1. Check the token supports IERC2981 via ERC-165 (interface ID 0x2a55205a).
2. Call royaltyInfo(tokenId, salePrice) to get:
   • receiver: Address to receive payout.
   • royaltyAmount: Amount to pay, computed from salePrice.

Creators or collection owners typically set a “default royalty” and optionally “per-token royalty.” Many implementations use a denominator of 10,000 for basis points. Marketplace accounting then splits the sale revenue among seller, protocol fees, and royalty recipient.

Implementation tips:

• Avoid reverts in royaltyInfo—marketplaces may skip payouts if your call fails.
• Keep royalty receiver upgradable (e.g., via Ownable or admin controls) to rotate keys or migrate to a split contract.
• Cap royalties to a reasonable maximum (many projects stay ≤10%) to encourage secondary market liquidity.

Minimal Solidity example

Below is a simplified pattern using OpenZeppelin. It shows how to set a default royalty and override support for ERC-165. In production, you should add access control, initialization guards, and robust minting logic.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

contract MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor(address defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Set default royalty (e.g., 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // Optional: set per-token royalty for special items
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // Required: ERC-165 supportsInterface
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

For deeper documentation, see OpenZeppelin’s ERC2981 guide.

Handling splits, upgrades, and edge cases

Real-world royalty flows are rarely single-recipient. Consider:

• Split contracts: Route revenue to multiple parties in fixed proportions using well-tested infrastructure like 0xSplits.
• Registry lookups: Some marketplaces consult a registry for the latest royalty data (Royalty Registry).
• Upgradable receivers: Maintain the ability to update the receiving address in case of key rotation or organizational changes.
• Per-token overrides: Special editions can have unique royalty rates relative to the default.

Technical notes:

• Consistent denominator: Stick to basis points (10,000) for clarity in off-chain integrations.
• Token type awareness: ERC-1155 implementations should compute royalty on per-token sale price, not bundle price.
• Graceful fallback: If royalty receiver is unset, return zero to avoid failed marketplace calls.

Marketplace reality: signaling vs. enforcement

ERC-2981 signals creator intent; it does not force payment. Different venues:

• May fully honor ERC-2981.
• May cap or reduce royalties under certain conditions.
• May ignore royalties entirely.

Given this variability, many creators experiment with hybrid models:

• On-chain restrictions via ERC-721C to limit transfers to royalty-respecting operators.
• Protocol-level rewards like Zora’s Creator Rewards.
• Community norms and social pressure around honoring creator earnings.

OpenSea’s 2023 decision to end operator filtering reflects the broader trend toward market choice over protocol-level enforcement, detailed in their announcement. In 2024–2025, this balance continues: ERC-2981 remains the canonical interface for royalty metadata, while enforcement is fragmented.

Testing, verifying, and monitoring

To ensure reliable royalty behavior:

• Verify interface support: Confirm your contract reports supportsInterface(0x2a55205a) == true per ERC-165.
• Simulate calls: Test royaltyInfo across edge sale prices and tokens.
• Indexing compatibility: Register your contract in relevant registries like Royalty Registry if your marketplace partners rely on it.
• Document clearly: Publish your royalty policy, caps, and receiver logic to minimize surprises for buyers and marketplaces.
• Learn the standard: If you’re new to ERC-2981, this overview by Alchemy is a useful primer: What is ERC-2981?.

Security and key management for creators

Royalty configurations are admin-controlled. If an attacker gains access to your deployer or admin keys, they can redirect royalties or disable them. Best practices:

• Use a hardware wallet for high-privilege actions like setting default royalty, updating receivers, or deploying split contracts.
• Prefer multisig setups for team-managed collections.
• Keep signing flows transparent and auditable.

For creators and studios that want secure, portable signing without compromising UX, OneKey hardware wallets offer:

• Offline private key storage with open-source firmware and transparent security practices.
• Smooth integration with common Ethereum tooling for contract deployment and admin operations.
• Cross-chain support, helpful if your NFTs mint on L2s or multiple EVM networks.

Using a hardware wallet to manage royalty settings ensures your on-chain revenue signals cannot be tampered with by compromised devices or hot wallets.

Conclusion

ERC-2981 is the foundation layer for NFT royalties: a simple, universal interface that marketplaces can read to determine creator payouts. It doesn’t guarantee enforcement—market policies do—but it standardizes the signal. In a world where enforcement is optional and evolving, combining ERC-2981 with registries, split contracts, and programmable restrictions like ERC-721C gives creators practical tools to sustain their work.

If you manage NFT collections or creator infrastructure, implement ERC-2981 cleanly, test it thoroughly, and secure your admin keys with a hardware wallet. This combination maximizes interoperability across marketplaces while protecting the revenue flows your project depends on.