Royalties can follow secondary sales only when the sale route reads a royalty rule and sends the specified amount as part of settlement. The NFT does not chase its own resale.
Those figures describe the simplest ERC-2981 flow. A marketplace calls royaltyInfo(tokenId, salePrice) on the NFT contract. The function returns two values: the address that should receive the royalty and the amount owed. For a 100 USDC sale at 5%, the marketplace sends 5 USDC to the returned address and settles the remaining 95 USDC with the seller.
The feature most people miss is that a royalty is normally a settlement instruction, not a payment hidden inside the token. ERC-2981 standardizes how a marketplace asks for that instruction, but it does not hold funds, detect sales, or force an unwilling marketplace to pay.
Three separate pieces have to line up. The token contract identifies the asset through its contract address and token ID. Its royalty logic supplies the recipient and amount. The marketplace’s sale contract performs the payment while transferring ownership. A collection’s image, metadata, or creator name can cross chains without any of that payment logic crossing with it.
The currency matters too. ERC-2981 expects the royalty to be paid in the same unit as the sale price. A sale settled in USDC should produce a USDC royalty; a sale settled in ETH should produce an ETH royalty. The standard does not convert between assets or decide who absorbs gas and bridge fees.
Cross-chain sales add a second identity problem. In a lock-and-mint design, the original NFT is locked or burned on the source chain, while a destination contract creates a wrapped representation. A cross-chain message must carry enough information for that representation to remain tied to the original: the source collection, token ID, metadata reference, royalty recipient, and royalty rule.
The destination NFT contract then needs its own royalty response. When its marketplace receives a 100 USDC sale, it should return the same 5 USDC obligation, or whatever rule the collection actually defines. If the bridge copies only the artwork and token number, the wrapped asset may look authentic while returning no royalty at all.
Axelar Network, Wormhole Protocol, and deBridge Protocol provide different forms of cross-chain messaging, verification, and execution. Their messages can carry instructions as well as asset information, but the transport layer is not the payer. The application on the destination chain still has to verify the source contract, prevent replay, recognize the wrapped asset, and execute the payment.
There are two broad design choices. Lock-and-mint preserves one active representation at a time, but every destination marketplace must understand the wrapped collection. A message-only design can leave the NFT on its original chain while coordinating a sale and payment elsewhere, but settlement now depends on contracts and finality on both chains.
A Universal Bridge can carry the message and payment instruction, but it does not, by itself, make an optional royalty compulsory.
The deciding question is whether the route controls the moment when ownership and money change hands. If a marketplace supports ERC-2981, royalties are easy to calculate but remain voluntary. If the buyer and seller use a private transfer, an unsupported marketplace, or a contract that bypasses the royalty check, the creator may receive nothing.
Enforceable systems add another layer. Standards such as ERC-721-C and ERC-1155-C can require transfers to pass through approved validators or marketplace contracts. That improves collection-level enforcement, but it narrows composability: an asset that works everywhere is easier to trade than one that rejects unapproved routes.
For a cross-chain implementation, the practical checklist is short: