OpenSea's recent move to make creator-fee enforcement opt-in for operators reframed the royalty question. What looked like a contract problem for most of the last cycle is now openly a marketplace-policy problem. ERC-2981 returns a royalty suggestion; the on-chain reality is the marketplace's settlement path. If the path doesn't honor it, the suggestion doesn't fire. That gap is the entire reason creators report losing creator-fee income in bursts tied not to contract upgrades but to platform policy rotations.
The marketplace table
A short summary of how each major marketplace currently treats creator fees — public, widely reported, and not exact quotes:
- OpenSea. Operator-fee enforcement is marketplaces-opt-in; creator fees are configurable by the collection.
- Blur. Defaulted to 0% creator fees for an extended period; the platform routes trades around the creator-fee surface entirely.
- LooksRare. Royalty policy has rotated several times; creators report highly variable enforcement across trading windows.
- Magic Eden. Behaves differently per chain — Solana, Ethereum, Bitcoin — with multi-chain creator-fee defaults that don't always align.
- X2Y2. Has historically exposed a user-toggle defaulting to 0%; marketplaces that surface a "minimum royalty" field inherit the user's choice.
Why "set in the contract" was a misread
ERC-2981 is a signal. The standard defines a royaltyInfo() function that returns a recipient address and a basis-points value. Nothing in the EIP forces a relayer — OpenSea, Blur, LooksRare, X2Y2, Magic Eden — to call it, honor it, or surface a floor. The hook sits in the marketplace's settlement path. Set the relayer's policy to skip creator fees, and the contract's signal goes unread. That gap was misunderstood for years by creators who believed deploying an ERC-2981 hook was the same as guaranteeing income.
The realized gap
Public reporting from creator communities has quantified the impact in ranges: collection-level creator-fee revenue dropped by 30–80% depending on which marketplace dominates the trading flow. Long-tail ERC-2981 holders saw the worst outcomes, because their cheapest routing destination was a marketplace with a permissive creator-fee policy. The exact dollar figures vary collection by collection, but the pattern is consistent — losing ~ $0.05– $0.30 per trade on a 1–3% expected royalty is meaningful for any team underwritten by secondary volume.
The durable alternative
Enforcement has to live where the money moves. Pushing splits into the payout contract itself — the on-chain rail a deal travels when funds settle — means the split executes atomically on every payment, regardless of which marketplace routed the trade. The marketplace is now interchangeable. The settlement rail is now the source of truth.
Where Pactsmith fits
Every deal recorded in Pactsmith carries an on-chain split built in basis points per recipient. The split contract is the document of record; the license record sits next to it. Settlement is autonomous; enforcement is independent of the relayer. Available today on Ethereum, Base, and Polygon — the EVM surface where tooling is mature and auditors can review every contract address.
This-week checklist
Five actions any NFT community can take in the next seven days, before the next marketplace rotates its creator-fee policy:
- Audit your ERC-2981
royaltyInfo()signature and recipient mapping. - Map your last 90 days of secondary sales to the marketplaces that routed them — identify which relayers currently pose the highest creator-fee risk.
- Set a floor royalty in your collection settings on every marketplace that supports the field, even if the platform's default is 0%.
- Establish an on-chain payout contract that handles splits at settlement rather than at fee forwarding.
- Document the royalty contribution from every secondary sale in a public ledger so contributors can see the realized gap and the trajectory of the fix.
The marketplace table will keep rotating. The contract surface is something a community owns and can control. See Pactsmith pricing →