Problem Statement: Creator Royalties on Secondary Sales
Problem Statement: Creator Royalties on Secondary Sales — NFT royalty system interview depth
Problem Statement: Creator Royalties on Secondary Sales
An NFT royalty system lets a creator earn a percentage of every secondary sale of their work: the collection declares a royalty policy (via ERC-2981), marketplaces read it at settlement, and the creator is paid — typically split across collaborators — from each resale. This is the machinery behind OpenSea Creator Earnings, Foundation, and Manifold's royalty registry.
Why it is hard: royalties are not actually enforceable on-chain. This is the defining truth of the domain. EIP-2981 is only a *read* interface — royaltyInfo(tokenId, salePrice) → (receiver, amount) tells a marketplace what should be paid, but nothing forces it to honor that. A plain ERC-721 transferFrom moves the token with zero royalty. So enforcement is a marketplace/social-layer problem, not a protocol guarantee — and that fragility is the whole interview.
The failure story that defines the space: the 2022–2023 royalty collapse. OpenSea launched the Operator Filter Registry (Nov 2022) to blocklist marketplaces that skipped royalties; Blur countered by making royalties optional (a 0.5% floor) to win traders with rebates; the filter war escalated, and by August 2023 OpenSea made royalties optional too. Creator earnings cratered industry-wide. Any design that assumes royalties are guaranteed is naive — the system must enforce where it can, surface/incentivize where it can't, and reconcile honestly.
What the system actually does. Register royalty policies (bps per collection, via ERC-2981), read the policy at settlement (Seaport consideration items, marketplace APIs), accrue owed royalties from the *confirmed settlement price (never the list price — that is how you get gamed), split across recipients (artist / studio / DAO, 5+ collaborators), and pay out* via splitter contracts and batched treasury jobs.
The invariants. Accrual derives from the confirmed on-chain settlement price; the payout ledger is append-only (a VOID row preserves audit history, never a delete); and the on-chain royaltyInfo read at fill is reconciled against the off-chain ledger. The two cardinal bugs: double-paying (crediting both a contract royalty and an off-chain ledger entry for one sale) and assuming transfer hooks always fire (private/OTC settlement bypasses them).
Scale to anchor on: ~50k secondary sales/day across major marketplaces, splits to 5+ collaborators, a 24h payout SLA. The engineering is exactly-once accrual on a chain you don't fully control, honest reconciliation, and a payout pipeline that never double-pays through reorgs and retries.
Key Highlights
- •Creators set royalty bps per collection; marketplaces read policy at sale settlement
- •Secondary sale triggers royalty transfer from buyer proceeds or seller net—product choice
- •Indexer reconstructs sale graph: tokenId, price, marketplace, royalty recipient splits
- •OpenSea made royalties optional in 2023; Blur prioritized trader rebates—design must handle policy drift.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Creator Royalties on Secondary Sales, I'll separate platform fee from royalty slice before naming SKUs."
- "I'll walk settlement → accrual → batch payout when stuck on databases."