# ERC-4910: Royalty Bearing NFT

Source: https://www.eipsfordesigners.com/standards/ERC-4910
Agent brief: https://www.eipsfordesigners.com/standards/ERC-4910/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-4910
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | NFT Capabilities |
| Journey stages | Asset Management |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-4910 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-4910 |

## UX Impact

Hierarchical on-chain royalty distribution — derivative NFTs pay royalties up the ancestry chain automatically. Design implications: show royalty tree visualization (who gets paid from this sale), display ancestor relationships, indicate derivative status, show accumulated royalty earnings. Design decisions: complexity of showing multi-level royalty splits, whether to expose full royalty hierarchy or summarize, handling deep ancestry chains in UI.

## Summary

ERC-4910 creates a comprehensive on-chain royalty system for NFTs. Unlike ERC-2981 which only provides royalty information, ERC-4910 actually tracks and distributes royalties. It maintains a royalty tree showing who gets paid what, handles multi-level splits (original creator, collaborators, resellers), and enables royalties to be queried, claimed, and even traded as their own assets.

## For Designers

- You can design UI that delivers royalty entitlements tracked on-chain.
- You can design UI that delivers on-chain royalty tree with automatic distribution.
- You can design UI that delivers royalty bearer tokens can be transferred like any asset.

## Applicability

### When to Use

- 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.

### When to Avoid

- Show complete breakdown: price + royalties + who receives what.
- Prominent "Claim" button, notifications when royalties available.
- Badge: "On-chain enforced" vs "Marketplace dependent".
- Assets are fungible tokens only with no unique-item semantics.

## Problems It Solves

### ERC-2981 royalties aren't enforced, marketplaces can ignore them

Impact: critical

Old way: Marketplace queries royalty info, may or may not pay it

New way: Royalty entitlements tracked on-chain, claimable by rights holders

### No way to split royalties between multiple creators

Impact: high

Old way: Single royalty recipient, manual off-chain splitting

New way: On-chain royalty tree with automatic distribution

### Royalty rights can't be transferred or traded

Impact: high

Old way: Royalties locked to original address forever

New way: Royalty bearer tokens can be transferred like any asset

### No transparency on royalty accumulation

Impact: medium

Old way: Creators don't know what they're owed until payment arrives

New way: Query pending royalties anytime, claim when ready

## Anti-Patterns

### Not showing royalty split before purchase

Severity: critical

Buyers surprised by hidden fees, lose trust

Instead: Show complete breakdown: price + royalties + who receives what

### Making royalty claiming complicated

Severity: high

Creators don't claim, lose money

Instead: Prominent "Claim" button, notifications when royalties available

### Not distinguishing enforced vs suggested royalties

Severity: high

Creators think all royalties are enforced when they're not

Instead: Badge: "On-chain enforced" vs "Marketplace dependent"

### Hiding that royalty rights can be transferred

Severity: medium

Creators don't know they can monetize rights now vs waiting

Instead: Clearly show "Transfer" and "Sell" options for royalty tokens

### No visualization of split percentages

Severity: medium

Hard to understand complex multi-party splits

Instead: Use visual bars, charts showing distribution clearly

## UI Components

### RoyaltyClaimWidget

Shows claimable royalties with claim action
States: loading, has-royalties, empty, claiming, claimed
Props: balance, collections, onClaim, onClaimAll

### SplitConfigurator

UI for setting up multi-party splits
States: editing, validating, saving, locked
Props: recipients, totalPercentage, onChange, onSave

### RoyaltyTreeView

Visual hierarchy of royalty distribution
States: collapsed, expanded, loading
Props: root, recipients, amounts, depth

### RoyaltyBearerCard

Displays royalty token as tradeable asset
States: owned, for-sale, pending-claim
Props: token, allocation, earnings, onAction

## On Monad

### Royalty Distribution Speed

Ethereum: Royalties may take multiple transactions to distribute

Monad: Instant distribution to all parties in split

Design implication: Real-time royalty updates, no distribution delays

### Claim Costs

Ethereum: Gas costs may exceed small royalty amounts

Monad: Even tiny royalties worth claiming

Design implication: Can show "Claim" for any amount, not just minimum thresholds

### Complex Splits

Ethereum: Deep royalty trees expensive to process

Monad: Complex distributions remain cheap

Design implication: Support more sophisticated revenue sharing models

### Real-time Tracking

Ethereum: Querying royalty state is slow

Monad: Sub-second queries for balances

Design implication: Live updating royalty dashboards feasible

## Key Takeaways

- ERC-4910 = on-chain tracked and distributed royalties
- Supports multi-party splits with visual representation
- Royalty rights are tradeable as bearer tokens
- Always show buyers the complete royalty breakdown
- On Monad: instant distribution, micro-royalties viable

## UX Patterns

### Creator Royalty Dashboard

Track all royalties across collections

User flow:

- 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

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

### Royalty Split Configuration

Set up multi-party royalty distribution

User flow:

- 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

Mockup registry key: `generic/vault-deposit` (React UI on the live standard page).

### Royalty Bearer Token

View and transfer royalty rights

User flow:

- User holds royalty bearer token
- View allocation percentage
- See pending and historical earnings
- Claim accumulated royalties
- Or transfer/sell the rights to someone else
- New holder receives future royalties

Mockup registry key: `concept/tx-status` (React UI on the live standard page).

### Buyer Royalty Transparency

Show buyers where royalties go

User flow:

- Buyer views NFT listing
- See complete price breakdown
- Royalty recipients shown transparently
- Understand where money goes
- On-chain enforcement indicator
- Complete purchase with confidence

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

## Technical Notes

ERC-4910 extends ERC-721 with royalty tracking infrastructure. It maintains a royalty tree where each node represents a recipient and their percentage. Royalty bearer tokens (RBTs) represent ownership of future royalty payments and can be transferred. The standard defines getRoyalties(), claimRoyalties(), and royaltyBalanceOf() for comprehensive royalty management.