# ERC-721C vs ERC-2981: Which NFT Royalty Standard Actually Enforces Payments

> ERC-2981 signals royalties; ERC-721C can enforce them. A technical comparison to help NFT engineers choose the right royalty approach for their collection.

- **Published:** 2026-05-19
- **Author:** Clixo
- **Reading time:** 5 min read
- **Tags:** nft-royalties, erc-721c, erc-2981, royalty-enforcement, smart-contracts
- **Canonical URL:** https://clixo.sh/blog/erc-721c-vs-erc-2981-royalty-enforcement

Creator royalties have been a contested space in NFT engineering. The market has cycled through optional royalties, enforced royalties, and hybrid approaches as platforms competed for volume. If you are building an NFT collection today and royalties matter to your economics, understanding the real difference between ERC-2981 and ERC-721C is essential — not because one is universally better, but because they solve different parts of the problem.

## The Core Distinction

**ERC-2981** is a read-only royalty signal. Your contract declares a royalty recipient and a rate. Marketplaces query this information. Whether they honor it is their policy choice. ERC-2981 cannot move funds. It cannot block transfers. It is an advisory standard.

**ERC-721C** (developed by Limit Break) is an enforceable transfer policy layer. It adds a configurable validator to the ERC-721 transfer flow that can block transfers to addresses that do not comply with royalty obligations. By restricting which operators can move tokens, ERC-721C can functionally block marketplaces that bypass royalties.

Same goal. Very different mechanisms.

```mermaid
flowchart LR
  A["NFT Transfer"] --> B["ERC-2981"]
  A --> C["ERC-721C"]
  B --> D{"Marketplace honors royalty?"}
  D -->|Yes| E["Creator paid"]
  D -->|No| F["Royalty skipped"]
  C --> G{"Operator allowlisted?"}
  G -->|Yes| H["Transfer allowed"]
  G -->|No| I["Transfer blocked"]
```

## How ERC-2981 Works in Practice

ERC-2981 defines a single function:

```
function royaltyInfo(uint256 tokenId, uint256 salePrice)
    external view returns (address receiver, uint256 royaltyAmount);
```

Compliant marketplaces (OpenSea, Blur in royalty-enforcement mode, others) call this before processing a sale. If the marketplace is compliant, your royalties are paid. If it is not, they are not.

The ecosystem reality: royalty bypass became a widespread issue when platforms discovered that removing royalties attracted volume from fee-sensitive traders. ERC-2981 alone was insufficient because compliance was voluntary.

**When ERC-2981 is the right choice:**
- Your collection prioritizes composability and maximum marketplace reach
- You accept that royalty enforcement depends on marketplace policy
- Your user base will trade on compliant platforms
- Simplicity and auditability matter more than enforcement

## How ERC-721C Works in Practice

ERC-721C extends ERC-721 with a transfer validator contract. Before any token transfer completes, the validator is called. The validator checks whether the operator (the contract or account initiating the transfer) is on an approved list.

Projects using ERC-721C set their validator policy to one of several security levels:

- **Level 0**: No restrictions. Works like standard ERC-721.
- **Level 1+**: Restrict operators to an allowlist. Marketplaces that want to support the collection must apply to be included.

If a marketplace is not on the allowlist, transfers through that marketplace are blocked at the contract level. This is genuine enforcement — not policy, not voluntary compliance, but a technical rejection.

```
// Conceptual — ERC-721C validator check in transfer
function _beforeTokenTransfer(
    address from,
    address to,
    uint256 tokenId
) internal override {
    transferValidator.validateTransfer(msg.sender, from, to);
}
```

**When ERC-721C is the right choice:**
- Royalties are a core part of your creator or protocol economics
- Your target marketplaces support ERC-721C (Blur, Magic Eden, others are integrating)
- You are willing to limit composability in exchange for enforcement
- Your community understands and accepts transfer restrictions

## The Composability Trade-Off

This is the most important practical consideration.

ERC-721C with restrictive settings breaks any contract interaction with your tokens that is not explicitly on the allowlist. This includes:

- Staking contracts
- Lending protocols (NFTfi, Arcade.xyz style)
- Composable game contracts
- Auction houses not on your allowlist

If you restrict operators and then build an ecosystem with partner protocols, every partner needs to be on your allowlist. This is manageable but requires ongoing governance. For collections with no composability ambitions, it is irrelevant. For collections embedded in a larger ecosystem, it is a real operational burden.

ERC-2981 has no such restriction. Any contract can interact with your tokens without permission.

## Hybrid Approaches

Some collections use both:

1. Implement ERC-2981 to signal royalty intent to all marketplaces and tools that read it.
2. Implement ERC-721C (at a moderate security level) to block known royalty-bypass operators specifically, without restricting the full ecosystem.

Limit Break's operator filter list can be set to block specific addresses rather than requiring an explicit allowlist. This is less restrictive than a pure allowlist model and may be the right middle ground.

## FAQ-Style Decision Points

**Will ERC-2981 ensure I get royalties?**

On compliant marketplaces, yes. On non-compliant platforms, no. Your effective royalty rate depends on where your token trades, not on whether you implemented ERC-2981.

**Does ERC-721C guarantee royalties?**

It blocks non-compliant transfers, but determined actors can use contract-level tricks (wrapping, private transactions) to route around validator checks. It raises the bar significantly but is not theoretically unbreakable.

**Which standard do major marketplaces support?**

ERC-2981 is universally read. ERC-721C support has grown but varies by platform and security level.

**Can I switch from ERC-2981 to ERC-721C after launch?**

Only if your contract was designed with upgrade or validator-addition capabilities. Most deployed collections are immutable. Plan your royalty enforcement approach before deployment.

**What is the simpler implementation to audit?**

ERC-2981 by a large margin. It is 20 lines of code and a single external view function. ERC-721C introduces a validator contract and transfer hook that adds audit surface.

---

For most collections, implementing ERC-2981 is the correct baseline — always, without exception. Whether to add ERC-721C enforcement on top depends on your royalty economics and composability needs.

If you are designing a royalty architecture for a new collection, [the Clixo team can help you model the trade-offs and implement the right approach](https://clixo.sh/#contact).

---

Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh)
[Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)