Optional NFT Royalties Explained

2026-09-03

A collection advertises a 5% creator royalty. A token from it sells for 10 ETH, so 0.5 ETH is what the creator is owed. Whether that 0.5 ETH ever arrives is not decided by the token contract at all. It is decided by whoever settles the trade, and the standard that defines the royalty says so in its own words.

Optional NFT Royalties Explained: key points at a glance

What an on-chain royalty actually is

ERC-2981 is the token standard that lets a collection of NFTs publish a royalty. Its abstract describes the mechanism as a way for contracts to signal a royalty amount to be paid to the NFT creator or rights holder every time the NFT is sold or re-sold. Signal is the operative word, and the rest follows from it.

The interface is one read-only function. A caller passes a token id and a sale price; the contract returns two values, the address that should receive the royalty and the amount owed. It answers a question. It moves nothing.

Put the example through it. A caller passes a sale price of 10 ETH, the collection is configured at 5%, and the function returns 0.5 ETH alongside a receiver address. At that instant the buyer still holds the funds, the seller still holds the token, and no one has been paid.

Why the standard makes payment voluntary

The specification does not leave this to interpretation. It states that the royalty payment must be voluntary, as transfer mechanisms such as transferFrom() include NFT transfers between wallets, and executing them does not always imply a sale occurred.

That reasoning rests on what the chain can see. In ERC-721, the Transfer event emits when ownership of any NFT changes by any mechanism, and the same event covers creation and destruction. It records that an owner changed. It carries no price, and it carries no reason.

So a contract that deducted a royalty on every transfer would deduct one when you move a token to a hardware wallet, when you send it to a friend, and when you consolidate two wallets into one. Voluntary payment is the consequence of that ambiguity rather than a gap someone forgot to close.

Who is in a position to pay

The party that knows a sale occurred is the party settling it. A marketplace smart contract takes payment from the buyer, delivers the token to the buyer, and sends the proceeds to the seller. It is the only place in the sequence where a price and a transfer exist together.

ERC-2981 addresses that party directly, and it addresses it as a recommendation: marketplaces that support the standard should implement some method of transferring royalties to the royalty recipient. A recommendation is not a requirement, and there is no enforcement path available anyway, because the token contract is never in the payment path.

One instruction in the standard is written more strongly, and it is worth reading for what it reveals. Marketplaces must pay the royalty in the same unit of exchange as the sale price passed to the royalty function. Even the strongest sentence in the document is aimed at a party the token contract cannot compel.

Where a royalty gets dropped

Four settlement routes produce four outcomes for the same sale. To the creator watching a wallet balance, three of them look identical, because nothing arrives in any of them.

Settlement route	Who decides the royalty	What reaches the creator
Direct wallet-to-wallet transfer, price agreed elsewhere	No one; there is no settlement contract	Nothing
Venue that never reads the royalty function	The venue, by omission	Nothing
Venue that reads it and leaves payment to the trader	The buyer or seller, per trade	Whatever they choose
Venue that reads it and routes the full amount	The venue, by policy	0.5 ETH

Only the last row involves an obligation, and that obligation belongs to the venue rather than to the token. Change venue and the same token under the same contract yields a different answer, which is what optional means here in practice.

Enforcing at the contract level

Since payment cannot be forced, some collections try to force the route instead. Trading through a marketplace means granting that marketplace a token approval, which authorises its contract to move the token on your behalf. A collection can refuse approvals for operators outside a list it maintains, which makes venues that skip the royalty unusable for that collection.

The cost of that design is paid by the holder. The token contract now decides where its holders may trade, somebody has to maintain the list and keep it current, and a token that cannot be moved by an unapproved operator can still be moved by its owner. Any route that needs no operator at all is untouched.

There is a deeper reason this approach stays awkward. Enforcement relocates the problem from payment to transfer, and transfer is the ambiguous act the specification pointed at in the first place. A rule that cannot tell a sale from a gift will either miss sales or charge gifts.

What the standard does settle

The list of what ERC-2981 fixes is short, and reading it as a column makes the shape of the standard visible.

Question	What the standard settles
How much is owed	The royalty function returns an amount for a given sale price
In which asset	The same unit of exchange as the sale price passed in
How the rate scales	The percentage is independent of the sale price
Who receives it	One address, returned by the function
How several creators split it	Not covered; the receiving contract handles that
Whether payment happens	Not covered; payment is voluntary
Who verifies payment	No one; the token contract sees none of it

The first four rows describe a number. The last three concern collection, and the standard declines all three. It is a specification for describing a royalty, not for collecting one.

Splitting is the clearest example of the boundary. Because the function returns a single address, a collection with several rights holders points that address at a contract that divides the incoming payment. The division happens after the money arrives, in code the standard never mentions.

Reading the number on a collection page

Treat a displayed royalty as a request rather than as revenue. The useful comparison is between the rate a collection advertises and the amount that actually reached the receiver over some period, and those two figures are separate readings that can differ by a lot.

The same gap explains a pattern that looks like evasion and is not. An owner moving a token between two wallets they control produces a transfer with no royalty, exactly as the specification intends, and it also produces a public record that resembles activity. That is the mechanism behind wash trading in collectibles: the chain shows an ownership change and leaves everyone to guess what it meant.

Two questions cover the practical cases. If you are a creator, ask which venues your collection actually trades on and what each of them does with the royalty function. If you are a buyer, ask whether the price shown to you already includes the royalty or whether it will be added at checkout, because the venue decides that too.

The bottom line

An on-chain royalty is a published number, not a claim on money. ERC-2981 gives a collection a way to state what it wants and gives a marketplace a way to read it, and it stops there on purpose, because a transfer on chain does not carry enough information to prove that a sale happened.

That makes the marketplace, not the contract, the thing to look at. A royalty is paid when the venue settling the trade chooses to pay it, and the enforcement designs above work by restricting where the token can trade rather than by making payment automatic. To keep learning the fundamentals, follow more from Bitbase Academy.