NFT royalties are payments intended for a creator or another recipient when a token is resold. The idea sounds automatic because blockchains can route value programmatically, but implementation varies. A token contract may publish royalty information, a marketplace may apply its own policy, or a transfer-restricted system may require trades through contracts that collect fees.
These mechanisms have different coverage and tradeoffs. ERC-2981 supplies a standard way to ask for a recipient and amount, yet the standard does not itself force every sale contract to pay. Marketplace policies can change, private transfers may not reveal a sale price, and restrictive enforcement can reduce compatibility. Revenue forecasts should therefore use evidence, not assumed perpetual collection.
What you will learn
- Explain the difference between royalty signaling, marketplace policy, and enforced transfer paths
- Identify sales that may bypass or miscalculate an intended creator payment
- Evaluate royalty expectations alongside licenses, fees, custody, and marketplace support
Royalty information is not universal collection
ERC-2981 defines royaltyInfo, a function that can return a payment recipient and calculated amount for a token and sale price. A compatible marketplace can query that information and include the payment during settlement. The interface improves consistency across ERC-721 and ERC-1155 collections, especially when individual tokens use different recipients or rates.
The standard deliberately communicates information rather than compelling payment. A settlement contract can ignore the response, and a simple wallet-to-wallet transfer has no trustworthy sale price from which to calculate a fee. Even when a marketplace supports royalties, it may cap rates, make payment optional, exclude certain order types, or update its policy. Collection code and venue behavior both need review.
Enforcement changes transfer design
Creators seeking stronger collection can restrict which operators or transfer contracts may move tokens, allowing only venues that apply designated fees. Another design places sale logic inside a contract that routes proceeds. These approaches can make bypass harder within supported paths, but wrappers, private arrangements, or unsupported interfaces may create alternatives depending on the exact code.
Restrictions also affect holders. A wallet, lending protocol, game, or future marketplace may be unable to transfer the token if its operator is not allowed. Administrators may control an allowlist or upgrade path, introducing censorship and governance questions. Enforcement is therefore not a free guarantee; it exchanges some composability and holder freedom for stronger control over recognized transfers.
Revenue and rights must not be confused
A creator payment does not transfer copyright to the buyer or prove that the royalty recipient owns the media rights. It is a payment rule associated with a transaction. The collection's license separately determines permitted display, adaptation, or commercial use. A creator could assign copyright while retaining a contractual payment interest, or retain copyright while receiving no automated resale payment.
Likewise, buyers should not assume paying a royalty cures an unauthorized mint. If a minter copied another artist's work, routing proceeds to the minter does not create permission from the actual rights holder. Provenance and license checks remain necessary. Creators should clearly identify recipients, rate logic, supported venues, and whether changes can occur after minting.
Model royalties as uncertain operating income
Royalty receipts depend on resale volume, prices, marketplace coverage, enforcement, recipient configuration, and continued control of receiving keys. None is guaranteed. Historical payments can be verified from transactions, but they do not establish future activity. Forecasts should state scenarios and assumptions rather than capitalizing an indefinite percentage of imagined trading into a collection valuation.
Operational controls matter after a payment is generated. A creator treasury should use secure custody, documented signer changes, accounting procedures, and tax review appropriate to its jurisdiction. If a contract permits the royalty recipient or rate to change, governance should disclose who holds that power and how holders will be notified. Transparent mechanics do not remove financial or legal obligations.
Common misconceptions
“ERC-2981 guarantees that creators receive royalties on every resale.”
ERC-2981 lets contracts communicate royalty information. A marketplace or settlement mechanism must choose or be required to use that information and route payment.
“Paying a creator royalty gives the buyer copyright in the associated work.”
A royalty is a payment mechanism. Copyright ownership and licensed uses depend on separate rights-holder agreements and applicable law.
Risks and limitations
- Marketplaces can reduce, make optional, or stop support for royalty payments, changing expected creator revenue.
- Transfer restrictions can impair wallet, lending, gaming, or marketplace compatibility and give administrators substantial control.
- Incorrect recipient configuration or compromised treasury keys can divert payments even when settlement follows the intended formula.
- Private or bundled trades may obscure the true sale price and make percentage calculations unreliable or avoidable.
Key takeaways
- Separate royalty signaling from actual payment enforcement.
- Check marketplace policy and settlement code for each sale path.
- Treat transfer restrictions as a compatibility and governance tradeoff.
- Do not infer copyright from either royalty payment or recipient address.
- Model future royalty income as uncertain and assumption-dependent.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.