How do you enforce NFT royalties across primary/secondary sales?
NFT Marketplace Developer
answer
I enforce NFT royalties through layered strategies. At the smart contract level, I integrate on-chain royalty registries (ERC-2981, custom logic) and operator filters to block zero-fee marketplaces. For interoperability, I use off-chain enforcement at fill time—matching orders only if royalties are included—and enforce signatures. To prevent circumvention, I design fee splitting at protocol level, require whitelisted operators, and use monitoring bots. Composability is preserved by exposing royalty data via APIs and registries.
Long Answer
Enforcing creator royalties in NFT marketplaces is one of the hardest design trade-offs, because creators want guaranteed compensation, buyers want liquidity, and aggregators push for composability. My strategy is multi-layered: enforce what can be enforced on-chain, design protocol incentives to discourage circumvention, and provide off-chain checks that preserve flexibility.
1) On-chain royalty standards and registries
The foundation is ERC-2981, which provides a standard way to query royalty info. I implement it so marketplaces can fetch fee receivers and percentages directly from the contract. For stricter control, I use custom logic that requires a royalty payment on every transfer (e.g., forcing a split at settlement). While this guarantees payment, it can reduce composability with aggregators who want control over transfers.
I sometimes leverage royalty registries (e.g., Manifold, Rarible’s Royalty Registry) to store canonical royalty info. This prevents marketplaces from claiming different fee splits.
2) Operator filter enforcement
Because some marketplaces intentionally bypass royalties, I integrate operator filter registries (like OpenSea’s OperatorFilter) at the contract level. This blocks transfers from operators that do not honor royalties. While controversial, it forces liquidity providers to either comply or lose inventory access. To avoid hurting composability, I provide allow-lists and versioning, letting creators opt in or out.
3) Off-chain enforcement at fill time
Not all enforcement is practical on-chain. At the order fill time, I enforce royalties by validating order signatures and rejecting fills that omit royalties. For example, I structure orders so that maker/taker fees must be included in calldata and validated by the exchange backend. Even if tokens move freely, trades on my marketplace cannot clear without royalty compliance.
This approach allows aggregators (Gem, Genie, Blur) to integrate by respecting my fill contract. They can route liquidity but must carry the royalty payload.
4) Preventing circumvention
Circumvention strategies include transferring NFTs via private escrow or wrapping contracts. To mitigate this, I:
- Implement transfer hooks that check operator compliance.
- Run monitoring bots that flag unusual transfers, alerting creators of attempts to bypass.
- Use protocol-level incentives: trades that include royalties are eligible for reward programs, while non-compliant routes are excluded.
- For wrapped NFTs, I encourage creators to deploy wrapper contracts that enforce royalties natively.
5) Replication and resiliency
Replication ensures not just durability but also fairness:
- In primary sales, fees are enforced at mint contracts with fixed splits.
- In secondary markets, replication of royalty data across APIs and subgraphs ensures consistent interpretation.
- I use multi-region replication of marketplace nodes so enforcement checks (royalty registry lookups, operator filter checks) remain fast under heavy load.
6) Preserving composability
Rigid enforcement risks fragmenting liquidity. To balance this, I design APIs and metadata registries exposing royalty info so third-party aggregators can honor royalties without deep integration. I also allow partial enforcement modes (e.g., soft enforcement with incentives + hard enforcement for premium collections). This keeps the ecosystem open while defending creator income.
7) Observability and audits
Every royalty path is tested with settlement simulations, tracing both ERC-721 and ERC-1155 flows. I audit contracts to prevent bypass via low-level calls. Off-chain, I log enforcement checks, rejected fills, and circumvention attempts, feeding analytics dashboards to creators.
The result: a marketplace architecture that combines on-chain guarantees, operator filters, and off-chain enforcement, minimizing circumvention while keeping aggregation and composability alive.
Table
Common Mistakes
- Relying only on ERC-2981 without mechanisms to ensure payment at execution.
- Blocking all operators and hurting liquidity instead of using selective filters.
- Assuming off-chain checks are enough without signature validation.
- Ignoring circumvention through OTC trades, wrapped tokens, or escrow contracts.
- Over-indexing on hard enforcement and breaking composability with aggregators.
- Not exposing royalty metadata via APIs, leaving integrators blind.
- Failing to monitor circumvention attempts or provide analytics to creators.
Sample Answers
Junior:
“I implement ERC-2981 so royalties can be queried and respected by marketplaces. On-chain, I add split contracts so primary sales send fees to both creator and platform.”
Mid:
“I use royalty registries and validate orders off-chain so trades cannot clear without royalties. For sharding liquidity, I ensure aggregators can route orders as long as they include the royalty payload.”
Senior:
“My strategy is layered: enforce royalties on-chain with ERC-2981 and operator filters, validate compliance at order fill time, and use incentives and monitoring to discourage circumvention. I expose royalty metadata to aggregators to preserve composability, and I prove resilience through audits and analytics dashboards.”
Evaluation Criteria
Strong answers show awareness of multiple enforcement levels:
- On-chain: ERC-2981, split payments, registry lookups.
- Operator filters: block zero-fee markets, allow controlled whitelisting.
- Off-chain: signature and fill-time enforcement.
- Circumvention: awareness of OTC, wrappers, escrow bypasses.
- Composability: designing APIs and registries so aggregators stay compatible.
Red flags: Saying “ERC-2981 solves it all,” ignoring circumvention, or suggesting hard enforcement that fragments liquidity without trade-offs.
Preparation Tips
- Implement ERC-2981 on a test ERC-721 contract; simulate royalty splits in Remix.
- Integrate with a royalty registry; verify cross-market consistency.
- Build an order-matching flow that rejects orders without royalty fields.
- Configure operator filters to block known bypassers; test allowed marketplaces.
- Simulate OTC and wrapper transfers; analyze how royalties are skipped.
- Add monitoring to log rejected trades and analyze aggregator compliance.
- Explore incentive-based programs (e.g., fee rebates for royalty-compliant trades).
- Benchmark fill latency with and without off-chain royalty checks.
Real-world Context
OpenSea attempted on-chain operator filters to block zero-fee markets, while Blur used off-chain enforcement at fill time. Creators who relied only on ERC-2981 saw royalties skipped on marketplaces that ignored it. Manifold’s Royalty Registry helped unify fee data across platforms. Some projects wrapped NFTs to enforce fees at the token level, while others incentivized compliance through reward schemes. The industry has converged on hybrid strategies—part on-chain, part off-chain—balancing enforceability and composability.
Key Takeaways
- Use ERC-2981 and registries for royalty metadata.
- Enforce royalties via on-chain logic or operator filters where possible.
- Validate orders with off-chain fill-time enforcement.
- Mitigate circumvention with monitoring, wrapper contracts, and incentives.
- Preserve composability by exposing royalty info to aggregators and APIs.
Practice Exercise
Scenario:
You are designing an NFT marketplace that must guarantee creator royalties while still allowing liquidity aggregation from external marketplaces (Gem, Blur, OpenSea). Creators want enforceable royalties, buyers want low friction, and you must prevent circumvention.
Tasks:
- Implement ERC-2981 and a royalty registry on the NFT contract.
- Add split logic so primary sales route royalties at mint.
- Integrate an operator filter registry to block transfers from non-compliant operators.
- At order fill time, enforce royalty checks by rejecting unsigned or missing royalty fields.
- Simulate secondary sales routed via an aggregator; verify orders pass only if royalty payload is intact.
- Test circumvention: OTC transfer, wrapper contracts; propose mitigations (hooks, monitoring bots, wrapped-enforcement).
- Expose royalty metadata via an API endpoint so third-party marketplaces can integrate.
- Add an incentive scheme where compliant trades receive rebates or visibility boosts.
Deliverable:
A layered strategy document proving how on-chain enforcement, operator filters, off-chain fill-time validation, and incentive design combine to enforce creator royalties and fees while keeping external composability.