What Are NFT Royalties?

Introduction

NFT royalties are rules or conventions that direct part of an NFT resale price to a creator or other designated recipient. They matter because NFTs made a familiar promise from older creative industries seem newly programmable: if a work is resold, perhaps the creator should keep participating economically instead of being paid only once at mint.

That sounds straightforward until you ask a technical question: **where, exactly, does a blockchain learn that a transfer was a sale, what the sale price was, and who should receive a share? ** Most NFT standards were built to track ownership and enable transfers, not to understand market context. That gap is the reason royalties became one of the most contested parts of the NFT ecosystem. The basic idea is simple; the mechanism is not.

The central fact to keep in mind is this: an NFT contract usually knows how to move a token from one owner to another, but a resale is an economic event that often happens outside the NFT contract itself. Once that clicks, most of the confusion around royalties disappears. Royalties are less like an intrinsic property of an NFT and more like an agreement between token contracts, marketplaces, trading protocols, and users about how sale proceeds should be split.

What problem do NFT royalties try to solve?

A normal digital file can be copied at near-zero cost, and even when blockchains create scarcity around a token, that does not automatically create an ongoing income stream for the creator. In traditional art, music, and licensing systems, people have long tried to answer a recurring question: if a creator’s work becomes more valuable later, should the creator benefit from that later appreciation? NFT royalties are one blockchain-native answer.

Here is the economic intuition. A creator mints an NFT and sells it for an initial price. If that NFT later trades at a much higher price, the seller on the second trade captures most of that appreciation. A royalty inserts a rule saying that some fraction of that resale value should be routed elsewhere, usually back to the original creator, a studio, a community treasury, or a rights-management contract. The mechanism is meant to make creator incentives more durable, especially in markets where the first sale may happen before demand is fully known.

But this only works if the party processing the sale can answer three questions reliably. Who should get paid? How much should they get? And when should payment happen? If any of those answers are missing or contestable, royalties become partial, inconsistent, or bypassable.

Why don’t ERC-721 and ERC-1155 enforce NFT royalties by default?

To see the difficulty, it helps to start with the base NFT standards rather than with royalties themselves. ERC-721, the canonical non-fungible token standard on Ethereum, standardizes how to identify an NFT, track ownership, approve operators, and transfer the token. ERC-1155 generalizes this idea so one contract can manage many token types, including fungible and non-fungible ones. Both standards are about asset representation and movement.

What they do not standardize is a native concept of a sale. An ERC-721 transferFrom call can represent a gift, a migration between wallets, collateral movement into a lending protocol, an OTC trade settled elsewhere, or a marketplace sale. The token contract sees a transfer. It does not inherently see the economic story around that transfer.

That design choice is not an omission so much as a boundary. The token standard defines ownership mechanics; marketplaces define trade mechanics. Once you keep those layers separate, the royalty problem becomes clearer. A royalty cannot simply say “on every transfer, take 5%,” because many transfers are not sales at all. Charging a royalty on a gift or on a vault deposit would be economically wrong. On the other hand, if the NFT contract waits for someone else to tell it the sale price, then it must trust that external party.

This is the basic tension: the NFT contract knows which token moved, but the marketplace or protocol usually knows whether money changed hands and how much.

How does ERC-2981 make royalties discoverable but not enforceable?

The most widely recognized royalty standard on Ethereum is ERC-2981. Its purpose is narrower than many people assume. It does not force royalties to be paid. It standardizes how a contract can publish royalty instructions so other systems can discover them.

Mechanically, ERC-2981 exposes a function named royaltyInfo(tokenId, salePrice) that returns two values: a recipient address and a royalty amount. The caller supplies tokenId, identifying the asset, and salePrice, the amount the asset sold for. The contract responds with who should receive the royalty and how much they should receive for that sale price. The interface is discoverable through ERC-165 interface detection, using interface id 0x2a55205a, so marketplaces can check whether a contract supports it before calling it.

That may sound almost trivial, but it solves a real interoperability problem. Before a shared interface existed, each marketplace or creator platform could define royalty metadata differently. One contract might store royalty data in a custom mapping, another might expose a bespoke function name, and another might rely on off-chain metadata. A marketplace wanting broad support had to write collection-specific code. ERC-2981 creates a common query path: ask the contract for royalty instructions in a uniform way.

The key constraint in the standard is that the returned royalty amount must be a percentage of salePrice. It cannot be a fixed amount that ignores the price. That rule matters because the function is intentionally agnostic about payment currency. The same NFT might be sold for ETH, WETH, USDC, or another token. If the royalty is defined as a percentage, then it scales with the sale amount regardless of unit. The marketplace is then expected to pay the royalty in the same unit as the sale price.

So ERC-2981 solves the discovery problem: it tells the market where to look and what shape the answer should take. It does not solve the execution problem of actually moving money, and it certainly does not solve the enforcement problem of compelling unwilling marketplaces or alternative trading paths to honor the answer.

Example: How does calling royaltyInfo(tokenId, salePrice) return royalty instructions?

Imagine an artist deploys an ERC-721 contract and sets a 7.5% royalty for all tokens in the collection. A marketplace later lists token #42 for 2 ETH. When a buyer accepts the listing, the marketplace can call royaltyInfo(42, 2 ETH). The contract might return a recipient address controlled by the artist and a royalty amount of 0.15 ETH.

At this point, nothing in ERC-2981 has yet transferred funds. The marketplace now has royalty instructions. If it chooses to honor them, it structures settlement so the total payment is split: some amount goes to the seller, some to the royalty recipient, and perhaps some to the marketplace itself as a platform fee. The important point is that the NFT contract did not detect the sale on its own. The marketplace supplied the sale price, asked for royalty data, and then used that answer while settling the trade.

Now change the scenario slightly. Suppose the owner of token #42 transfers it directly to a friend using transferFrom, and the friend separately wires money off-chain. The NFT contract sees only a transfer. Unless some external system voluntarily treats that transfer-plus-off-chain-payment as a sale and still pays the royalty, nothing in ERC-2981 can stop the trade from bypassing royalty payment. The standard itself anticipated this limitation: marketplaces that respect it are expected to pay royalties even if the sale occurred on-chain, OTC, or off-chain, but that is a norm for participants, not an on-chain compulsion.

That example captures both the strength and weakness of the standard. It makes royalty intent legible. It does not make royalty payment unavoidable.

Why do marketplaces often treat NFT royalties as voluntary?

If royalty instructions are discoverable, why not just make every transfer enforce them? The answer is that sale detection is ambiguous and settlement paths are diverse.

Marketplaces often execute trades through escrow contracts, order books, aggregators, or generalized exchange protocols. Seaport, for example, models an order as an offer plus a consideration array with explicit receivers. That is a flexible way to pay multiple parties in one fulfillment path, including creators, sellers, and the marketplace itself. In such a system, royalties can be embedded directly into trade consideration. But the protocol’s flexibility also illustrates the broader point: what matters is how a marketplace constructs settlement, not merely what the NFT contract says in isolation.

This means royalties behave more like a social-technical convention than a universal law of token transfer. A marketplace may choose to honor ERC-2981 fully. Another may partially honor it. Another may ignore it and compete by offering lower-friction, lower-fee trades. Once traders can route orders through alternative venues, the venue enforcing royalties may lose order flow to venues that do not.

That competitive pressure is not incidental; it is the main reason royalties became unstable. If buyers and sellers are price-sensitive, then royalties increase effective transaction cost. Some market designs try to preserve creator income. Others optimize for maximum liquidity and minimum friction. Those objectives often conflict.

What technical limitations prevent universal royalty enforcement?

The deepest technical obstacle is not merely that marketplaces may refuse to pay. It is that the NFT standard itself does not carry sale-value information. Research proposing stronger mechanisms, such as the ERC-7526 direction, starts from exactly this limitation: ERC-721 is “ignorant of sale values.” Without trustworthy sale-value information inside the transfer primitive, any royalty rule must depend on some external settlement layer or some altered trading design.

You can think of it this way. Ownership transfer and payment transfer are separate state changes. A royalty is a rule about the relationship between them: when ownership changes because of a sale, divert some percentage of payment to a designated party. But blockchains do not automatically label every paired movement of token and money as a sale, nor do they guarantee that both movements happen inside one canonical contract path.

That is why many royalty discussions become debates about architecture. If trades settle through a marketplace contract that controls payment routing, royalties can be included. If trades happen through direct transfers plus off-chain payment, or through protocols that separate escrow, matching, and final delivery in unexpected ways, royalties are much harder to ensure.

Which protocol designs can make royalties enforceable, and how do they work?

Because the base standard is not enough, ecosystems have built additional machinery around it. One approach is registry-based discovery. The Manifold-style royalty registry, and forks of its royalty engine used elsewhere, let protocols look for royalty information from multiple possible sources: ERC-2981, older marketplace-specific specifications, or manual overrides for legacy collections. This improves compatibility for older NFTs that never implemented a common interface.

Another approach is protocol-level settlement enforcement. sudoAMM v2, for instance, documents that royalties are enforced at the liquidity-pool contract level. Its pair contracts call a royalty engine during swaps, compute the royalty owed, and incorporate that into the swap path. If a collection implements ERC-2981, the engine can query the contract directly; otherwise it can consult other recognized metadata sources and registries. Here the important mechanism is not just metadata discovery but the fact that the trading venue’s own contracts are built to route payment.

This kind of design can make royalties robust inside that protocol. It does not make them universal across all protocols. A trader can still avoid that venue if another venue offers a cheaper path. So protocol-level enforcement creates islands of reliability, not ecosystem-wide inevitability.

A third approach has been transfer restrictions or operator filtering, where NFT contracts try to allow transfers only through approved operators that honor royalties. This was an attempt to turn a voluntary marketplace norm into something closer to contractual enforcement at the asset layer. But it introduced its own tradeoffs: reduced composability, more brittle integrations, and dependence on maintaining operator lists. The prominent operator-filter-registry implementation tied to this approach was later deprecated and archived, which is a useful signal that the strategy was not a clean long-term resolution.

How do NFT royalty implementations differ across blockchains?

The royalty idea is broader than Ethereum, but the mechanism varies by chain because the underlying token and metadata systems vary.

On Solana, the Metaplex token-metadata program stores NFT metadata in dedicated accounts and includes royalty-related fields such as seller fee basis points in its data structures. The documentation also exposes constraints around changing those values, including an explicit error for attempts to modify seller fee basis points when not allowed. That means royalty information can live as first-class on-chain metadata associated with the NFT. But the same distinction still matters: storing royalty terms on-chain is not the same as forcing every marketplace to honor them. Metadata makes royalties legible and standardized; enforcement still depends on the sale venue and protocol flow.

In the CosmWasm ecosystem, the cw721 family includes extension points and references to royalty-oriented extensions such as cw-2981. Here again, the pattern is familiar: the NFT standard is extended so royalty information can be represented in collection metadata or related types. Whether metadata is stored on-chain or off-chain is itself a design choice, with consequences for cost, mutability, and ease of querying. But whatever the storage choice, publication of royalty data and mandatory payment are separate questions.

That repetition across architectures is telling. The hard part is not inventing a field for “royalty percentage.” The hard part is binding that field to actual trade execution in markets where users can choose among venues.

Common misunderstandings about NFT royalties

A common misunderstanding is to think an NFT royalty is a property of the token in the same way a balance or owner is a property of the token. It usually is not. Ownership is part of the token’s canonical state transition system. Royalty payment is usually a rule layered on top of marketplace settlement.

Another misunderstanding is to treat ERC-2981 as an enforcement standard. It is not. It is better described as a royalty discovery interface. It tells interoperable systems how to ask, “If this asset sold for this amount, who should be paid and how much?” It does not instruct the EVM to seize funds, block transfers, or infer sales from arbitrary token movement.

A third misunderstanding is to assume royalties always go to a single creator wallet. ERC-2981 returns one receiver address and one amount, but that receiver can itself be a smart contract that handles additional complexity such as fee splitting, accounting, or distribution among multiple recipients. The standard explicitly leaves such complexity to the receiver contract or to external processes. So the one-recipient return value is an interface simplification, not necessarily an economic simplification.

Creator royalties vs. market liquidity: what’s the trade-off?

There is a durable tension between creator compensation and market liquidity. A royalty gives creators ongoing participation in secondary-market value, which many communities see as fair and incentive-aligned. But royalties also act like an extra transaction cost. Higher transaction costs can reduce trading frequency, encourage routing to lower-fee venues, and put pressure on prices.

That tension is why the topic is not merely technical. The standards question and the market-design question are inseparable. If enforcement is weak, creators may receive less than expected. If enforcement is strong and inflexible, traders may avoid the venue or the asset. Different ecosystems have made different choices about where to sit on that spectrum.

The strongest lesson from the past few years is that interoperability without enforcement produces portability of royalty data, not guaranteed royalty income. Creators may still prefer standardized metadata because some payment is better than none and because broad support reduces integration costs. But the existence of a standard should not be confused with the existence of an enforceable right.

What technical directions could make royalties harder to evade?

Proposals for stronger royalty mechanisms try to change the architecture rather than merely improve metadata. Some research-backed directions aim for incentive-compatible designs that remain compatible with existing NFT standards while making royalty avoidance less attractive or less rational. The ERC-7526-related work is notable because it starts from first principles: if the base NFT standard lacks sale-awareness, perhaps the right answer is not to pretend otherwise, but to redesign the market mechanism around that constraint.

Whether such approaches will see widespread adoption is still uncertain. Any stronger system must do three things at once: preserve enough composability to be usable, produce incentives strong enough to prevent easy evasion, and fit into markets that already have entrenched expectations and infrastructure. That is a difficult combination.

So the likely future is not a single universal royalty mechanism appearing overnight. It is more likely a patchwork: some chains and marketplaces treating royalties as metadata conventions, some protocols enforcing them locally, some collections using custom transfer restrictions, and some new standards trying to rebuild the problem around better incentives.

Conclusion

NFT royalties are best understood as a rule for splitting sale proceeds, not a native feature of token ownership. Standards like ERC-2981 made royalty terms interoperable by giving marketplaces a common way to ask who should be paid and how much. That was important, but it solved discovery, not enforcement.

The reason royalties remain contentious is structural: NFT transfers are standardized, but sales are not. As long as trade execution can happen through many venues and many settlement paths, royalty payment depends on whether those venues choose or are designed to honor it. If you remember one thing, remember this: NFT royalties are easy to describe, easy to publish, and hard to make unavoidable.

How do you evaluate an NFT before buying it?

Evaluate an NFT by verifying its on-chain royalty metadata, sale history, and who actually receives royalty payments; then run the trade workflow on Cube Exchange after those checks. On Cube you can fund your account and execute the purchase with the payment token used in the market while controlling execution parameters that affect how royalty amounts are calculated.

1. Check the collection’s royalty metadata on-chain: open the token contract (or token-metadata account on Solana) and confirm ERC-2981 support or seller-fee-basis-points, and call or view royaltyInfo(tokenId, salePrice) or the equivalent metadata field.
2. Inspect the royalty recipient: open the returned recipient address to see if it is an EOA or a smart contract, review any verified source code or multisig details, and note whether the recipient contract performs fee-splitting.
3. Confirm marketplace settlement behavior: read the marketplace’s docs or recent trade receipts to verify whether it includes royalties in the settlement consideration and which payment tokens it uses (ETH, WETH, USDC, etc.).
4. Fund your Cube account and place the order: deposit the market payment token, choose a limit order to control the sale price (so the royalty percentage yields a predictable amount), review the total outgoing including royalties and platform fees, and submit.