{"id":"ERC-2981","name":"NFT Royalty Standard","status":"Final","chain":"both","category":{"id":"nft","name":"NFT Capabilities","description":"What NFTs can do beyond basic ownership"},"journeyStages":[{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-2981 standardizes an NFT royalty query. An implementing contract can return a percentage-based amount and royalty recipient through royaltyInfo(); a sale venue may query and honor that information, but marketplace adoption and payment enforcement vary.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-2981","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-2981","summary":"ERC-2981 standardizes an NFT royalty query. An implementing contract can return a percentage-based amount and royalty recipient through royaltyInfo(); a sale venue may query and honor that information, but marketplace adoption and payment enforcement vary.","applicability":{"whenToUse":["Your product addresses: no standard way to specify royalties.","Your product addresses: royalties differ across platforms.","The flow should deliver: one royaltyInfo() function that the selected sale integration can query.","You are designing a royalty display on listing experience with visible states and recovery paths."],"whenToAvoid":["The target contract does not expose royaltyInfo for the asset.","The product requires guaranteed royalty payment on a sale path that does not enforce it.","You need proof of authorship or legal rights from the royalty recipient field alone."]},"designerTakeaways":["Design the flow to support one royaltyInfo() function for integrations that support the standard.","Design the flow to support contract specifies rate.","Design the flow to support on-chain, verifiable, queryable royalty info."],"problemsSolved":[{"problem":"No standard way to specify royalties","oldWay":"Set royalties separately on OpenSea, Rarible, each marketplace","newWay":"One royaltyInfo() function gives supported integrations a common royalty query","impact":"critical"},{"problem":"Royalties differ across platforms","oldWay":"Royalty settings and payment policies vary by collection and marketplace","newWay":"Contract specifies a rate that a selected marketplace may honor","impact":"high"},{"problem":"Creators can't verify royalty settings","oldWay":"Check each marketplace dashboard separately","newWay":"On-chain, verifiable, queryable royalty info","impact":"medium"}],"uxPatterns":[{"name":"Royalty Display on Listing","description":"Show the configured royalty recipient and amount when listing an NFT","userFlow":["User lists NFT","Marketplace queries royaltyInfo()","Shows royalty % and recipient","Calculates user proceeds","User sees clear breakdown"]},{"name":"Purchase with Royalty","description":"Show buyer where funds go","userFlow":["User clicks buy","Shows payment distribution","Selected sale path shows whether the configured recipient receives a royalty","User understands where ETH goes","Completes purchase"]}],"uiComponents":[{"name":"RoyaltyBadge","description":"Show the computed royalty amount for the selected sale price; show a percentage only when separately derived from verified contract terms.","states":["has-royalty","no-royalty","loading"],"props":["salePrice","royaltyAmount","recipient"]},{"name":"FeeBreakdown","description":"Detailed breakdown of sale/purchase fees","states":["collapsed","expanded"],"props":["salePrice","royalty","platformFee","proceeds"]},{"name":"RoyaltyRecipientInfo","description":"Show the royalty receiver address and separately sourced attribution; do not imply that ERC-2981 verifies identity or rights ownership.","states":["available","unavailable","loading"],"props":["recipient","royaltyAmount","source"]}],"antiPatterns":[{"pattern":"Hiding royalty in fine print","why":"Sellers surprised by lower proceeds","instead":"Show royalty prominently in fee breakdown","severity":"high"},{"pattern":"Not querying on-chain royalty","why":"May show outdated or wrong royalty info","instead":"Query royaltyInfo() from the selected contract before displaying current settings","severity":"medium"},{"pattern":"Offering 0% royalty override","why":"Undermines creator compensation model","instead":"Show the configured royalty or disclose when the selected sale path does not honor it","severity":"medium"}],"keyTakeaways":["ERC-2981 = on-chain NFT royalty standard","Query royaltyInfo(tokenId, salePrice) for royalty data","Show royalty in fee breakdown, not hidden","Display the returned royalty receiver address, and label any rights-holder attribution separately.","Enforcement varies by marketplace"],"technicalNotes":"ERC-2981 adds royaltyInfo(uint256 tokenId, uint256 salePrice) returns (address receiver, uint256 royaltyAmount). Returns royalty recipient and absolute amount based on sale price. Interface ID: 0x2a55205a. Note: ERC-2981 is informational — marketplaces choose whether to enforce. Some bypass via aggregators or direct transfers.","lastUpdated":"2026-09-18","specConstraints":[{"id":"royalties-voluntary","constraint":"Royalty payment is voluntary because NFT transfers do not always represent a sale.","appliesTo":"application","normativity":"normative","specQuote":"This standard allows contracts, such as NFTs that support [ERC-721](./eip-721.md) and [ERC-1155](./eip-1155.md) interfaces, to signal a royalty amount to be paid to the NFT creator or rights holder every time the NFT is sold or re-sold. This is intended for NFT marketplaces that want to support the ongoing funding of artists and other NFT creators. The royalty payment must be voluntary, as transfer mechanisms such as `transferFrom()` include NFT transfers between wallets, and executing them does not always imply a sale occurred. Marketplaces and individuals implement this standard by retrieving the royalty payment information with `royaltyInfo()`, which specifies how much to pay to which address for a given sale price. The exact mechanism for paying and notifying the recipient will be defined in future EIPs. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments.","specSection":"Abstract","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#abstract","designImplication":"Label royalties as a marketplace or participant commitment. Do not promise that every wallet transfer will produce a royalty payment."},{"id":"royalty-unit-match","constraint":"The royalty must be paid in the same unit of exchange as the sale price.","appliesTo":"application","normativity":"normative","specQuote":"Marketplaces **MUST** pay the royalty in the same unit of exchange as that of the `_salePrice` passed to `royaltyInfo()`. This is equivalent to saying that the `_salePrice` parameter and the `royaltyAmount` return value **MUST** be denominated in the same monetary unit. For example, if the sale price is in ETH, then the royalty payment must also be paid in ETH, and if the sale price is in USDC, then the royalty payment must also be paid in USDC.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Keep sale currency and royalty currency aligned in the price breakdown. Do not convert the royalty into an unrelated token without an explicit product rule."},{"id":"royalty-percentage-of-sale","constraint":"The royalty amount is calculated as a percentage of the sale price, with the percentage independent of the sale price.","appliesTo":"application","normativity":"normative","specQuote":"Implementers of this standard **MUST** calculate a percentage of the `_salePrice` when calculating the royalty amount. Subsequent invocations of `royaltyInfo()` **MAY** return a different `royaltyAmount`. Though there are some important considerations for implementers if they choose to perform different percentage calculations between `royaltyInfo()` invocations.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Show the royalty as a sale-price-based amount and label any rounding. Do not present a fixed token amount as the standard royalty."},{"id":"royalty-no-fixed-amount","constraint":"`royaltyInfo` must not return a fixed amount or infer a currency from constant sale-price thresholds.","appliesTo":"application","normativity":"normative","specQuote":"The `royaltyInfo()` function is not aware of the unit of exchange for the sale and royalty payment. With that in mind, implementers **MUST NOT** return a fixed/constant `royaltyAmount`, wherein they're ignoring the `_salePrice`. For the same reason, implementers **MUST NOT** determine the `royaltyAmount` based on comparing the `_salePrice` with constant numbers. In both cases, the `royaltyInfo()` function makes assumptions on the unit of exchange, which **MUST** be avoided.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Treat the returned amount as relative to the submitted sale price and selected currency."},{"id":"royalty-zero-no-transfer","constraint":"A marketplace should not send a zero-value royalty transaction when `royaltyAmount` is zero.","appliesTo":"application","normativity":"normative","specQuote":"Marketplaces that support this standard **SHOULD NOT** send a zero-value transaction if the `royaltyAmount` returned is `0`. This would waste gas and serves no useful purpose in this EIP.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Hide or disable a royalty payment action when the amount is zero rather than showing a meaningless transaction."},{"id":"royalties-across-sale-contexts","constraint":"Marketplaces supporting the standard pay royalties across on-chain, OTC, and off-chain sales, in the sale currency.","appliesTo":"application","normativity":"normative","specQuote":"Marketplaces that support this standard **MUST** pay royalties no matter where the sale occurred or in what currency, including on-chain sales, over-the-counter (OTC) sales and off-chain sales such as at auction houses. As royalty payments are voluntary, entities that respect this EIP must pay no matter where the sale occurred - a sale conducted outside of the blockchain is still a sale. The exact mechanism for paying and notifying the recipient will be defined in future EIPs.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Keep royalty reporting consistent across sale channels and currencies, while making the voluntary nature clear."},{"id":"royalty-info-amount","constraint":"The royalty payer pays the `royaltyAmount` returned by `royaltyInfo` for the given sale price.","appliesTo":"application","normativity":"rationale","specQuote":"Rather than returning a percentage and letting the marketplace calculate the royalty amount based on the sale price, a `royaltyAmount` value is returned so there is no dispute with a marketplace over how much is owed for a given sale price. The royalty fee payer must pay the `royaltyAmount` that `royaltyInfo()` stipulates.","specSection":"Rationale — Royalty payment percentage calculation","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#royalty-payment-percentage-calculation","designImplication":"Show the quoted royalty amount alongside the sale price and preserve the quote’s input currency."},{"id":"erc721-erc1155-compatibility","constraint":"The standard is compatible with current ERC-721 and ERC-1155 standards.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThis standard is compatible with current ERC-721 and ERC-1155 standards.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#backwards-compatibility","designImplication":"Keep the underlying NFT ownership and transfer views intact while adding royalty information."},{"id":"marketplace-royalty-settlement","constraint":"A marketplace supporting ERC-2981 SHOULD execute the actual royalty funds transfer after retrieving the royalty information.","appliesTo":"application","normativity":"rationale","specSection":"Motivation","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#motivation","designImplication":"Separate royalty calculation from payment status and show settlement as pending until the marketplace's actual transfer is confirmed.","specQuote":"Many of the largest NFT marketplaces have implemented bespoke royalty payment solutions that are incompatible with other marketplaces. This standard implements standardized royalty information retrieval that can be accepted across any type of NFT marketplace. This minimalist proposal only provides a mechanism to fetch the royalty amount and recipient. The actual funds transfer is something which the marketplace should execute."},{"id":"royalty-rounding","constraint":"Implementers MAY round a royalty-fee remainder up or down to the nearest integer.","appliesTo":"application","normativity":"normative","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Show the integer royalty amount and identify the rounding convention when a fractional calculation is possible.","specQuote":"The percentage value used must be independent of the sale price for reasons previously mentioned (i.e. if the percentage value 10%, then 10% **MUST** apply whether `_salePrice` is 10, 10000 or 1234567890). If the royalty fee calculation results in a remainder, implementers **MAY** round up or round down to the nearest integer. For example, if the royalty fee is 10% and `_salePrice` is 999, the implementer can return either 99 or 100 for `royaltyAmount`, both are valid."},{"id":"royalty-rate-variation","constraint":"Implementers MAY vary the royalty percentage using predictable variables, but it SHOULD NOT depend on unpredictable variables such as block.timestamp.","appliesTo":"application","normativity":"normative","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Show the variables and quote time behind a royalty amount, and warn when a rate cannot be explained or refreshed reliably.","specQuote":"The implementer **MAY** choose to change the percentage value based on other predictable variables that do not make assumptions about the unit of exchange. For example, the percentage value may drop linearly over time. An approach like this **SHOULD NOT** be based on variables that are unpredictable like `block.timestamp`, but instead on other more predictable state changes. One more reasonable approach **MAY** use the number of transfers of an NFT to decide which percentage value is used to calculate the `royaltyAmount`. The idea being that the percentage value could decrease after each transfer of the NFT. Another example could be using a different percentage value for each unique `_tokenId`."},{"id":"royalty-recipient-display","constraint":"The royalty recipient is the address to which the royalty payment should be sent.","appliesTo":"application","normativity":"normative","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#specification","designImplication":"Display the recipient address alongside the royalty amount and make it clear when payment has not yet occurred.","specQuote":"/// @return receiver - address of who should be sent the royalty payment"},{"id":"royalty-payment-scope","constraint":"ERC-2981 does not specify payment mechanics; the receiver handles additional fee-splitting, multiple-recipient, tax, and accounting complexity.","appliesTo":"application","normativity":"rationale","specSection":"Rationale > Simple royalty payments to a single address","specUrl":"https://ercs.ethereum.org/ERCS/erc-2981#simple-royalty-payments-to-a-single-address","designImplication":"Do not imply that royaltyInfo settles funds; show deployment-specific payment, splitting, and accounting behavior separately.","specQuote":"This EIP does not specify the manner of payment to the royalty recipient. Furthermore, it is impossible to fully know and efficiently implement all possible types of royalty payments logic. With that said, it is on the royalty payment receiver to implement all additional complexity and logic for fee splitting, multiple receivers, taxes, accounting, etc. in their own receiving contract or off-chain processes. Attempting to do this as part of this standard, it would dramatically increase the implementation complexity, increase gas costs, and could not possibly cover every potential use-case. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments. Future EIPs can specify more details regarding payment transfer and notification."}],"sources":[{"label":"ERC-2981 official specification","url":"https://ercs.ethereum.org/ERCS/erc-2981","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-2981","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-2981","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-2981","markdown":"https://www.eipsfordesigners.com/standards/ERC-2981/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-2981/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-2981","official":"https://ercs.ethereum.org/ERCS/erc-2981","discussion":"https://ethereum-magicians.org/search?q=ERC-2981"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}