After resale, a royalty setting controls the payout a compliant marketplace calculates, not ownership, price, or guaranteed enforcement.
That is the boundary to keep in mind when a cross-chain Universal Bridge integration carries the asset into another venue. The setting describes what should happen at settlement; it does not follow the token around as an independent claim.
In practice, the royalty usually lives in the NFT contract through ERC-2981. A marketplace calls royaltyInfo(tokenId, salePrice) and receives two things: the recipient address and the amount owed for that sale price. A 5% setting therefore means 0.05 of the sale price, paid in the same unit as the sale. It does not mean that the creator owns 5% of the NFT, controls its resale price, or receives money whenever the token moves between wallets.
What happens at the first resale
The marketplace, not the NFT transfer function, normally creates the payment event. Its order or auction contract takes the buyer's funds, queries the royalty rule, sends the royalty to the designated recipient, and forwards the remainder to the seller. If the venue does not make that call, ERC-2981 alone cannot make it pay.
That distinction matters because ERC-721 and ERC-1155 transfers do not contain sale-price information. A transfer might be a gift, a wallet migration, collateral movement, or a sale settled somewhere else. The token contract cannot reliably infer which one occurred. Royalty standards therefore expose payment information; they do not turn every transfer into a compulsory fee-bearing sale.
After the resale, the setting usually remains attached to the collection contract or to a token-specific override. The new owner does not become the royalty recipient merely because they bought the NFT. Unless the contract deliberately supports mutable recipients, the original creator, rights-holder wallet, split contract, or treasury remains the destination. A collection-wide default may also be overridden for an individual token, which is why reading the live contract state matters more than trusting a marketplace badge.
Where cross-chain transfers change the result
A bridge adds another contract and another representation between the original NFT and its next sale. The source token may be locked or burned, while a destination contract mints a wrapped or canonical-looking representation. The destination token can preserve the original collection address, token ID, metadata, and royalty parameters—or it can preserve only the appearance of the asset. Those are different outcomes.
This is the edge case most explanations skip: preserving metadata is not the same as preserving settlement logic. If the destination contract implements royaltyInfo and points to the intended recipient, a destination marketplace can calculate the same royalty. If it does not, the resale takes place under the destination contract's rules, even when the image, name, and token ID look unchanged.
The transport layer does not decide this. Stargate Finance is useful for moving supported fungible assets, but a token transfer does not carry an NFT royalty policy by itself. Chainlink CCIP can deliver token transfers and authenticated messages, while deBridge Protocol can pass arbitrary data and execute destination-side calls. In each case, the application integrating the transport must encode, validate, and enforce the royalty behavior.
The practical sequence to check
- Read the source contract. Check whether it implements ERC-2981, whether the rate is collection-wide or token-specific, and whether the recipient or percentage can be changed.
- Inspect the bridge representation. Confirm whether the destination asset is the original token, a locked representation, or a newly minted wrapper. Then verify that its royalty function returns the intended recipient and amount.
- Inspect the marketplace settlement. A venue may support ERC-2981, impose its own royalty cap, use a custom creator-fee registry, or ignore royalties entirely.
- Check the payment path. A royalty paid in ETH, USDC, or another asset must be delivered in the sale's payment asset. A message that records “5% owed” is not payment until a destination contract actually transfers the funds.
The meaningful 2026 shift is composability: cross-chain systems can now carry instructions and execute destination-side actions closely enough to make portable royalty flows practical to build. That makes a royalty-aware bridge possible, not automatic. The decisive question after resale is still the same: which contract settles the sale, and what rule does that contract execute?