{"id":"ERC-4910","name":"Royalty Bearing NFT","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-4910 connects NFTs to royalty accounts and subaccounts, supporting hierarchical splits, direct payment processing, listings, and payouts. It does not define a separate royalty bearer token or a general transferable-rights interface; any such asset is an implementation extension.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-4910","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-4910","summary":"ERC-4910 connects NFTs to royalty accounts and subaccounts, supporting hierarchical splits, direct payment processing, listings, and payouts. It does not define a separate royalty bearer token or a general transferable-rights interface; any such asset is an implementation extension.","applicability":{"whenToUse":["Your product addresses: eRC-2981 royalties aren't enforced, marketplaces can ignore them.","Your product addresses: no way to split royalties between multiple creators.","The flow should deliver: royalty entitlements tracked on-chain, claimable by rights holders.","You are designing a creator royalty dashboard experience with visible states and recovery paths."],"whenToAvoid":["The target contract does not implement the royalty-account and payment interfaces.","Your payment path cannot apply the configured account hierarchy and payout permissions.","The product requires a transferable royalty bearer token that the implementation does not provide."]},"designerTakeaways":["Design the flow to support royalty entitlements tracked on-chain.","Design the flow to support royalty accounts, subaccounts, and hierarchical payout paths.","You can show a separate tradable-rights asset only when the implementation explicitly adds one."],"problemsSolved":[{"problem":"ERC-2981 royalties aren't enforced, marketplaces can ignore them","oldWay":"Marketplace queries royalty info, may or may not pay it","newWay":"Royalty entitlements tracked on-chain, claimable by rights holders","impact":"critical"},{"problem":"No way to split royalties between multiple creators","oldWay":"Single royalty recipient, manual off-chain splitting","newWay":"Royalty accounts can represent hierarchical splits and distribute payments through the contract's configured path","impact":"high"},{"problem":"Royalty account structure is hard to inspect","oldWay":"Rights and payouts are opaque to the recipient","newWay":"Royalty accounts and subaccounts expose the configured split and payout path","impact":"high"},{"problem":"No transparency on royalty accumulation","oldWay":"Creators don't know what they're owed until payment arrives","newWay":"Query configured royalty balances and invoke the authorized payout path when ready","impact":"medium"}],"uxPatterns":[{"name":"Creator Royalty Dashboard","description":"Track all royalties across collections","userFlow":["Creator opens royalty dashboard","See total claimable across all NFTs","View breakdown by collection","See share percentage for each","Claim individual or all at once","Funds transfer to wallet"]},{"name":"Royalty Split Configuration","description":"Set up multi-party royalty distribution","userFlow":["Creator sets total royalty percentage","Add recipients with addresses","Allocate share to each recipient","Visualize distribution","Save configuration on-chain","All parties can claim their share"]},{"name":"Buyer Royalty Transparency","description":"Show buyers where royalties go","userFlow":["Buyer views NFT listing","See complete price breakdown","Royalty recipients shown transparently","Understand where money goes","Sale-path payment and enforcement indicator","Complete purchase with confidence"]}],"uiComponents":[{"name":"RoyaltyPayoutWidget","description":"Shows royalty-account payout availability with the target contract's configured payout action","states":["loading","has-royalties","empty","claiming","claimed"],"props":["balance","collections","onClaim","onClaimAll"]},{"name":"SplitConfigurator","description":"UI for setting up multi-party splits","states":["editing","validating","saving","locked"],"props":["recipients","totalPercentage","onChange","onSave"]},{"name":"RoyaltyTreeView","description":"Visual hierarchy of royalty distribution","states":["collapsed","expanded","loading"],"props":["root","recipients","amounts","depth"]}],"antiPatterns":[{"pattern":"Not showing royalty split before purchase","why":"Buyers surprised by hidden fees, lose trust","instead":"Show complete breakdown: price + royalties + who receives what","severity":"critical"},{"pattern":"Making royalty claiming complicated","why":"Creators don't claim, lose money","instead":"Prominent \"Claim\" button, notifications when royalties available","severity":"high"},{"pattern":"Treating royalty accounts as transferable bearer assets","why":"The standard does not define a separate royalty-rights token","instead":"Show account and payout state; describe any transferable rights token only as an implementation extension","severity":"medium"},{"pattern":"No visualization of split percentages","why":"Hard to understand complex multi-party splits","instead":"Use visual bars, charts showing distribution clearly","severity":"medium"},{"pattern":"Not distinguishing enforced vs suggested royalties","why":"Creators think all royalties are enforced when they're not","instead":"Badge: \"On-chain enforced\" vs \"Marketplace dependent\"","severity":"high"}],"keyTakeaways":["ERC-4910 = on-chain tracked and distributed royalties","Supports multi-party splits with visual representation","Royalty accounts and subaccounts are not automatically transferable bearer tokens","Always show buyers the complete royalty breakdown"],"technicalNotes":"ERC-4910 extends ERC-721 with royalty accounts and subaccounts attached to NFTs, hierarchical splits, payment registration, listings, and payouts. Relevant functions include getRoyaltyAccount(), updateRoyaltyAccount(), deleteRoyaltyAccount(), royaltyPayOut(), executePayment(), listNFT(), and removeNFTListing(); use the exact target ABI and permissions. The standard does not define RBTs, getRoyalties(), claimRoyalties(), or royaltyBalanceOf() as a transferable bearer-rights interface.","lastUpdated":"2026-09-18","specConstraints":[{"id":"payoutable-royalty-balance","constraint":"Only individual royalty accounts can carry a balance that can be paid out.","appliesTo":"application","normativity":"normative","specQuote":"* The royalty balance associated to each RA Sub Account. Note that only individual accounts can carry a balance that can be paid out. That means that if an RA Sub Account is an RA, its final Sub Account balance must be zero, since all RA balances must be allocated to individual accounts.","specSection":"Specification — Outline","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#outline","designImplication":"Separate aggregate royalty-account balances from individual payout balances. Show a claim action only for an individual sub-account with a payable balance."},{"id":"royalty-account-on-mint","constraint":"Minting a royalty-bearing NFT creates and links its royalty account and sub-accounts.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r18\">**[R18]**</a> *When a new NFT is minted a Royalty Account with one or more Royalty Sub Accounts MUST be created and associated with the NFT and the NFT owner, and, if there is an ancestor, with the ancestor's Royalty Account.*","specSection":"Specification — NFT Minting","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#nft-minting","designImplication":"After minting, show the NFT and its royalty-account relationship before offering payout or child-NFT actions."},{"id":"payment-approval","constraint":"An ERC-20 purchase starts by approving the NFT contract for the selected payment amount.","appliesTo":"application","normativity":"rationale","specQuote":"1. The Buyer must `approve` the NFT contract for the purchase price, `payment` for the selected payment token (ERC-20 contract address).","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#rationale","designImplication":"Make the payment token, amount, spender, and approval step explicit before checkout. Do not imply that approval itself completes the purchase."},{"id":"payment-execution","constraint":"An ERC-20 purchase then calls the NFT contract to execute payment.","appliesTo":"application","normativity":"rationale","specQuote":"2. For an ERC-20 payment token, the Buyer must then call the `executePayment` in the NFT contract -- the ERC-20 is not directly involved.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#rationale","designImplication":"Model approval and purchase execution as separate transaction states, with recovery copy if either step fails."},{"id":"native-payment-encoding","constraint":"A protocol-token purchase sends the token to the NFT contract with encoded purchase information.","appliesTo":"application","normativity":"rationale","specQuote":"* For a non-ERC-20 payment, the Buyer must send a protocol token (ETH) to the NFT contract, and is required to send encoded listing and payment information.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#rationale","designImplication":"Use a distinct native-payment review state that shows the asset list and payment context. A plain native transfer is not enough for this purchase flow."},{"id":"transfer-after-royalty-distribution","constraint":"NFT transfer occurs only after the payment and royalty-distribution checks succeed.","appliesTo":"application","normativity":"normative","specQuote":"The input parameters must satisfy several requirements for the NFT to be transferred AFTER the royalties have been properly distributed. Furthermore, the ability to transfer more than one token at a time is also considered.","specSection":"Specification — Outline — Modified NFT Transfer Function including required Trade data to allocate Royalties","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#modified-nft-transfer-function-including-required-trade-data-to-allocate-royalties","designImplication":"Present purchase, royalty allocation, and ownership transfer as one outcome. Do not expose a raw transfer path as equivalent to a completed sale."},{"id":"supported-payment-token","constraint":"The contract must identify supported payment token types for royalty-bearing sales.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r5\">**[R5]**</a> *There MUST be a listing of supported token types*","specSection":"Specification — Data Structures — NFT Payment Tokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#nft-payment-tokens","designImplication":"Show only supported payment currencies in the sale flow and validate the selected token before asking the buyer to approve funds."},{"id":"listing-records","constraint":"Direct-sale implementations keep a list of NFTs for sale and identify each listing.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r7\">**[R7]**</a> *There MUST be a list of NFTs for sale.*\n\n<a name=\"r8\">**[R8]**</a> *A sales listing MUST have a unique identifier.*","specSection":"Specification — Data Structures — NFT Listings and Payments","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#nft-listings-and-payments","designImplication":"Give each listing a stable status and identifier so buyers and sellers can distinguish active, removed, and completed sale records."},{"id":"registered-payment-records","constraint":"Exchange-mediated payments are registered and identified before a later transfer can complete.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r9\">**[R9]**</a> *There MUST be a listing for registered payments*","specSection":"Specification — Data Structures — NFT Listings and Payments","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#nft-listings-and-payments","designImplication":"Show a registered-payment state separately from an owned NFT or completed transfer. Keep the payment identifier visible for recovery."},{"id":"delete-expensive-and-irreversible","constraint":"Deleting a royalty account is costly and should happen only after its stated conditions are met.","appliesTo":"application","normativity":"normative","specQuote":"While sometimes deleting a Royalty Account is necessary, even convenient, it is a very costly function in terms of gas, and should not be used unless one is absolutely sure that the conditions enumerated below are met.","specSection":"Specification — Royalty Account Management — Deleting a Royalty Account","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#deleting-a-royalty-account","designImplication":"Treat deletion as a high-friction maintenance action. Explain gas cost and prerequisites before the user signs it."},{"id":"delete-descendants-burned","constraint":"Deleting an NFT royalty account requires related ancestor and descendant tokens to be burned.","appliesTo":"application","normativity":"normative","specQuote":"* *all `tokenId` numbers genealogically related to `_tokenId` either as ancestors or offspring MUST also be burnt.*","specSection":"Specification — Royalty Account Management — Deleting a Royalty Account","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#deleting-a-royalty-account","designImplication":"Show the affected NFT family and the irreversible burn prerequisites. Do not present deletion as a local metadata cleanup."},{"id":"delete-zero-royalty-balances","constraint":"Royalty sub-account balances must be zero before the associated account can be deleted.","appliesTo":"application","normativity":"normative","specQuote":"* *all balances in the Royalty Sub Accounts MUST be zero.*","specSection":"Specification — Royalty Account Management — Deleting a Royalty Account","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#deleting-a-royalty-account","designImplication":"Show outstanding balances and payout actions before enabling deletion. A delete button must not hide funds that still need to be claimed."},{"id":"direct-sale-through-contract","constraint":"Direct-sale listing and delisting transactions run through the NFT contract.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r24\">**[R24]**</a> *For direct sales, NFT listing, und de-listing, transactions MUST be executed through the NFT smart contract.*","specSection":"Specification — Listing and De-Listing of NFTs for Direct Sales","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#listing-and-de-listing-of-nfts-for-direct-sales","designImplication":"Keep listing and delisting status tied to the contract-mediated sale flow. Do not promise an off-contract listing state as final."},{"id":"listing-validation","constraint":"A direct purchase must match an active listing, meet its price, and identify the listed NFTs and seller.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r34\">**[R34]**</a> *For `trxnType = 0`, the payment data MUST to be validated against the listing, based on the following rules:*\n\n* *NFT(s) MUST be listed*\n* *`payment` MUST be larger or equal to the listing price.*\n* *The listed NFT(s) MUST match the NFT(s) in the payment data.*\n* *The listed NFT(s) MUST be controlled by `seller`.*","specSection":"Specification — Payments for NFT Sales","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#payments-for-nft-sales","designImplication":"Before confirmation, show the exact listing, token set, seller, and minimum price. Re-check them before the purchase transaction is submitted."},{"id":"payment-reversal","constraint":"A failed or abandoned registered payment can be reversed by the buyer under the specified conditions.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r44\">**[R44]**</a> *In case of a transaction failure (for direct sales, `trxnType = 0`), or the buyer of the NFT listing changing their mind (for exchange-mediated sales, `trxnType = 1`), the submitted payment MUST be able to revert using the `reversePayment` function where the function interface is defined below:*","specSection":"Specification — Payments for NFT Sales","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#payments-for-nft-sales","designImplication":"Provide a recovery state for a registered payment that cannot complete. Explain when the buyer can reverse it and when the payment record is removed."},{"id":"sale-transfer-data","constraint":"The transfer path carrying royalty and payment data is required; transfer functions without that data are disabled.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r46\">**[R46]**</a> *Therefore, `transferFrom` and `safeTransferFrom` without `data` MUST be disabled.*","specSection":"Specification — Modified NFT Transfer function","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#modified-nft-transfer-function","designImplication":"Do not label a plain ERC-721 transfer as a valid sale for this standard. Keep the payment context attached to the ownership transition."},{"id":"payout-before-owner-change","constraint":"The former royalty sub-account is paid out before ownership is updated.","appliesTo":"application","normativity":"normative","specQuote":"* *the internal version of the`royaltyPayOut` function MUST pay out the entire royalty balance of the Royalty Sub Account owned by the `from` address to the `from` address.*","specSection":"Specification — Update Royalty Sub Account Ownership with Payout to approved Address (from)","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#update-royalty-sub-account-ownership-with-payout-to-approved-address-from","designImplication":"Show payout settlement before the ownership-change confirmation. Keep a pending payout visible if the transfer cannot finish yet."},{"id":"payout-authorized-subaccount","constraint":"Royalty payout requires a valid token, royalty account, and sub-account recipient under the specified checks.","appliesTo":"application","normativity":"normative","specQuote":"<a name=\"r59\">**[R59]**</a> *The following steps MUST be taken to send out a royalty payment to its recipient:*","specSection":"Specification — Paying out Royalties to the from Address in safeTransferFrom Function","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#paying-out-royalties-to-the-from-address-in-safetransferfrom-function","designImplication":"Show which royalty sub-account is receiving funds and make invalid or unavailable claim targets explicit."},{"id":"hierarchical-royalty-tree","constraint":"Royalty-bearing NFTs can form a multi-level inheritance tree whose royalties must be distributed across the hierarchy.","appliesTo":"application","normativity":"rationale","specQuote":"Royalties for NFTs is at its core a distribution licensing problem. A buyer obtains the right to an asset/content which might or might not be reproducible, alterable etc. by the buyer or agents of the buyer. Therefore, a comprehensive specification must address a hierarchy of royalties, where one or more assets are derived from an original asset as described in the Motivation section in detail. Consequently, a design must solve for a multi-level inheritance, and thus, recursion problem.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#rationale","designImplication":"Show parent, child, and inherited royalty relationships where they affect a sale or payout. Avoid flattening the hierarchy into one unexplained recipient."},{"id":"sale-payment-to-contract","constraint":"The buyer pays the NFT contract directly and the contract distributes payment to the seller and royalty recipients.","appliesTo":"application","normativity":"rationale","specQuote":"The design needed to avoid royalty circumvention during the purchase process, therefore, the NFT must be kept in the \"know\", a buyer will always have to pay the NFT contract directly and not the seller for both purchasing modes. The seller is subsequently paid through the royalty distribution function in the NFT contract. As a consequence, and a key design choice, and to stay compliant with ERC-721, the NFT contract must be the owner of the NFT, and the actual owner is an `approved` address.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#rationale","designImplication":"The checkout should identify the contract as the payment destination and show how the seller and royalty recipients are paid."},{"id":"erc721-compatibility","constraint":"The extension retains the core ERC-721 interfaces and functionality while adding royalty behavior.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThis EIP is backwards compatible to the ERC-721 standard introducing new interfaces and functionality but retaining the core interfaces and functionality of the ERC-721 standard.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#backwards-compatibility","designImplication":"Keep existing ERC-721 discovery and ownership views available, while explaining the additional sale and royalty states."},{"id":"creator-safety-limits","constraint":"Creators must set limits for generations, sub-accounts, prints, listing size, and royalty percentages.","appliesTo":"application","normativity":"security-considerations","specQuote":"* General Considerations: The creator of an NFT family must carefully consider the business model for the NFT family and then set the parameters such as maximum number of generations, royalty sub-accounts, number of prints per print, number of NFTs in a listing, and the maximum and minimum royalty split percentage allowed.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#security-considerations","designImplication":"Expose the configured limits before a creator publishes a royalty family. Use them to explain why a mint, listing, or payout may be rejected."},{"id":"subaccount-addition-option","constraint":"A non-parent Royalty Sub Account owner MAY add an additional sub-account when the update satisfies the royalty-split and balance conditions.","appliesTo":"application","normativity":"normative","specQuote":"If `msg.sender` is equal to the account identifier of one of the Sub Account owners which is not the parent NFT, an additional Royalty Sub Accounts MAY be added","specSection":"Specification — Royalty Account Management — Update a Royalty Account","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#update-a-royalty-account","designImplication":"Show add-sub-account as an available option only for an eligible non-parent owner, with the split and zero-balance conditions visible before signing."},{"id":"batch-mint-capability","constraint":"The mint function SHOULD be able to mint more than one NFT at a time.","appliesTo":"account-implementation","normativity":"normative","specQuote":"Note, that the `mint` function SHOULD have the ability to mint more than one NFT at a time.","specSection":"Specification — NFT Minting","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#nft-minting","designImplication":"Offer batch minting when the deployed mint function supports it, while keeping single-mint fallback and per-token royalty relationships clear."},{"id":"nullable-payment-receiver","constraint":"A payment receiver MAY be NULL, but it MUST NOT be the zero address.","appliesTo":"application","normativity":"normative","specQuote":"`receiver` MAY be NULL but MUST NOT be the Zero Address.","specSection":"Specification — Payments for NFT Sales","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#payments-for-nft-sales","designImplication":"Represent the receiver value explicitly in purchase review and reject a zero-address recipient; do not silently substitute a wallet address for a nullable field."},{"id":"implementation-security-audit","constraint":"Each implementation is RECOMMENDED to undergo a professional security audit.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"Besides the usage of professional security analysis tools, it is also recommended that each implementation performs a security audit of its implementation.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4910#security-considerations","designImplication":"Expose audit provenance and its scope in integration review, while leaving an unaudited or unknown status visibly distinct from a security guarantee."}],"sources":[{"label":"ERC-4910 official specification","url":"https://ercs.ethereum.org/ERCS/erc-4910","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-4910","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-4910","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-4910","markdown":"https://www.eipsfordesigners.com/standards/ERC-4910/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-4910/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-4910","official":"https://ercs.ethereum.org/ERCS/erc-4910","discussion":"https://ethereum-magicians.org/search?q=ERC-4910"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}