ERC-2981 is a simple standard that lets an NFT contract answer one question: “If this token sells for X, who should receive a royalty and how much?” It exposes a single function, royaltyInfo(tokenId, salePrice), that marketplaces can call to calculate and pay royalties to creators or rights holders. It is widely supported, but it does not force payment — marketplaces decide whether to honour it.
Key takeaways
- One function:
royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount). - Works with both ERC-721 and ERC-1155, detected through ERC-165.
- Royalties are signalled, not enforced — payment depends on marketplace policy.
- For enforceable revenue sharing on real-world assets, put the economics in the asset’s legal structure and smart-contract distributions, not only in ERC-2981.
How it works
function royaltyInfo(uint256 tokenId, uint256 salePrice)
external view returns (address receiver, uint256 royaltyAmount);
The contract typically stores a default royalty (e.g. 5% to the creator) and optional per-token overrides. Royalties are usually expressed in basis points; the amount returned is in the same unit as salePrice, so it works for any payment currency.
Why enforcement is hard
ERC-2981 cannot see sales — NFT transfers do not carry price information. A marketplace (or OTC buyer) that ignores royalties can simply transfer the token. Approaches to improve enforcement include:
- Operator filtering — blocking transfers via marketplaces that do not pay royalties (controversial, can harm liquidity).
- Sales via your own marketplace contract that pays royalties atomically.
- Transfer fees in the token itself (changes token behaviour and may break integrations).
- Legal agreements for licensed or institutional assets.
Use cases
- Digital art and collectibles — the original purpose.
- Music and media rights — royalties flowing to artists, labels and rights holders on resale.
- Licensed brand assets — brand owners earn on secondary trading of licensed digital goods.
- Gaming items — studios earn when players trade items. See our Web3 development services.
ERC-2981 and real-world assets
For tokenized RWAs, “royalties” are usually something else: management fees, performance fees, platform fees or income distributions. These belong in the issuance terms and are better handled by distribution contracts — like the fee and income distribution logic on our real estate platform — or by transfer-fee compliance modules in permissioned tokens. ERC-2981 can still signal a platform fee to marketplaces, but should not be the only mechanism.
Implementation tips
- Use a well-audited base implementation and set a sensible cap on royalty percentage.
- Make the receiver a splitter contract if several parties share royalties.
- Keep royalty configuration changes behind multisig and emit events.
- Advertise support through
supportsInterface.
Example implementation
// Illustrative: ERC-721 with ERC-2981 royalties — not audited.
contract LicensedAsset is ERC721, ERC2981, AccessControl {
constructor(address royaltyReceiver) ERC721("Licensed Asset", "LIC") {
_setDefaultRoyalty(royaltyReceiver, 500); // 5.00% in basis points
}
function setTokenRoyalty(uint256 id, address r, uint96 bps) external onlyRole(DEFAULT_ADMIN_ROLE) {
require(bps <= 1000, "max 10%");
_setTokenRoyalty(id, r, bps);
}
function supportsInterface(bytes4 i) public view override(ERC721, ERC2981, AccessControl) returns (bool) {
return super.supportsInterface(i);
}
}
Royalty splits
When several parties share revenue — an artist, a label and a platform — set the receiver to a payment-splitter contract. The splitter holds incoming royalties and lets each party withdraw its share. This keeps the token simple and makes changes (e.g. a rights transfer) a governance action on the splitter rather than the NFT.
Designing a royalty policy
- Rate: keep it reasonable; high royalties suppress secondary trading.
- Scope: decide whether royalties apply to all sales or only above a threshold.
- Changes: document whether and how rates can change, and by whom.
- Marketplace strategy: prioritise marketplaces that honour royalties, or run your own sale contract that pays them atomically.
Royalties versus revenue rights
A royalty on secondary NFT sales is different from a right to the asset’s ongoing revenue (e.g. streaming income). The latter is usually a financial right — potentially a security — and belongs in a properly structured token with distribution contracts. See what is RWA tokenization.
Frequently asked questions
No. The standard provides information; marketplaces choose whether to pay.
Yes. It is token-standard agnostic and works with ERC-721 and ERC-1155.
Yes — set the receiver to a payment-splitter contract that divides incoming royalties.
Only as a signal. Enforce fees through issuance terms, distribution contracts or compliance modules.
The same unit as the salePrice passed in — marketplaces pass the price in their payment currency.
Yes, if the contract allows it. Changes should be restricted and transparent.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
