Why NFT royalties do not reach authors when changing platforms
A standard like EIP-2981 declares only the author's share and the recipient address — it itself withholds nothing. The platform, not the collection contract, pays or does not pay at the moment of the transaction.
While a collection trades on one storefront, the discrepancy is unnoticeable; when moved to another, the payout logic falls apart.
Royalty avoidance in secondary sales almost always follows one scenario.
In Solana collections, royalties are often described in token metadata but not hardcoded into the program itself: the new platform reads these fields according to its own rules or simply does not call the share transfer instruction.
The recipient address, the creator flag, and the wallet that withholds the percentage are three different entities, and there is no mandatory call between them.
For the author, this means NFT royalties are not paid outside the “friendly” storefront, and income rests only on the primary mint.
Holders feel the same through liquidity: a collection with disabled royalties holds value worse because the creator's interest in its development declines.
That is why configuring NFT royalties is not a single field in metadata but work with both sides: checking the collection contract (who is declared as the recipient, whether the program supports enforced withholding at the sale level) and separate configuration for each platform.
Below we examine exactly where payout logic is lost during migration and which roles in the contract are responsible for it.
What correct royalty configuration delivers in secondary sales
Configuring royalties makes sense not for a checkbox but for a predictable payout stream — and they need to be tested in the field, on the secondary market, where the author no longer controls the transaction.
The first measurable metric: the share of payouts reaching the author's wallet without manual intervention.
When royalties are declared at the token level via the EIP-2981 standard and confirmed by the enforced royalty mechanism on Solana platforms, this share stays at the upper bound and is not diluted by individual storefront policies.
The second metric is withdrawal speed. In an automated scenario, the payout goes to the author within hours after the transaction rather than waiting for manual reconciliation at the end of the period.
If there are several platforms, the balance is consolidated from one source: the author sees the accrual immediately, not an abstract “it's somewhere.”
The third is fewer disputed transactions. Disputes arise where the storefront did not read the metadata or applied its default policy.
A single correct configuration removes most such cases before support is contacted: the disputed one is not a transaction where the royalty exists, but one where it was counted twice or not found at all.
The fourth is automation of payouts to authors, with manual additional charges disappearing as a class. No forgotten periods or duplicate transfers remain: everything that did not pass through the automated route goes into a queue and is resolved via logs, not correspondence.
In total, this is the result of correct configuration — the share of payouts received, withdrawal speed, and number of disputed transactions stop being a matter of guesswork.
NFT royalty standard and enforced withholding: what to choose
Choosing a fixation scheme is a trade-off between compatibility and payout guarantee.
The royalty standard inside the contract describes to which address and in what share the royalty goes on a secondary sale: the platform reads this data and decides for itself whether to withhold it. The contract will neither prohibit the sale nor see the settlement between buyer and seller.
Enforced royalty withholding moves verification to the platform side: the transaction goes through its program, the seller is checked against an allowlist, and the share is deducted before funds are credited.
Hence the limitations of royalties — the allowlist rules are set by the platform itself, and transactions bypassing its interface remain without payouts.
| Option | When it fits | Limitations |
|---|---|---|
| Contract standard (EIP-2981) | Compatibility with different platforms and wallets is needed | Withholding is not guaranteed: the signal can be ignored |
| Enforced platform verification | Sales go through one channel and payout guarantee matters | Dependence on its rules; external settlements are not covered |
| Hybrid scheme | The collection sells in several places | More complex accounting: signal, checks, and manual accruals are combined |
On Solana, the token model does not contain a royalty field at all, so royalties on a sales platform work only through its verification.
Magic Eden maintains such an allowlist of collections and changes its terms — the scheme has to be revisited along with the platform's rules, not once at launch.
In practice, the setup ends up hybrid: a standard in the contract for compatibility, platform verification for a guarantee, and separate accounting for sales outside its perimeter.
Implementation stages: from contract audit to handover to the team
The workflow is the same for both a Solana collection and an EVM network, but the set of steps depends on whether the platform respects enforced royalties or reads only the signal from metadata.
That is why we start not with code but with an inventory: where royalties are currently calculated, who the recipient is, and whether the scheme can be changed without reissuing tokens.
- Smart contract audit. We review the current logic: calculation base, recipient list, presence of admin roles, and points where royalty can be bypassed via a transfer through a third-party contract.
- Design decision. We choose where the logic lives — in the contract itself, in a separate recipient registry, or in an adapter for a specific platform — and fix which markets will enforce royalties.
- Royalty configuration. We define shares, support for multiple recipients and splits, make the registry updatable, and lock the rights to change the scheme after launch.
- Test collection. We run the full cycle on a copy: mint, listing, sale, cancellation, resale, recipient change — and review actual accruals in the logs.
- Platform checks. We compare behavior where royalties are mandatory and where the buyer can remove them manually; we record discrepancies in a report.
- Work acceptance. We compare expected and actual shares for each transaction, check edge cases, and sign off on reconciliation, not promises.
- Handover to the team. We provide payout documentation, the fund flow diagram, instructions for changing recipients, and the procedure for disputed accruals.
As a result, you are left with a working scheme and a clear procedure: how to check an accrual, whom to notify when the registry changes, and what to do if a platform stops applying royalties.
Handover package: configurations, diagrams, and procedures
Royalty mechanics live longer than a single release: rights holders, shares, platform rules, and team members change.
That is why we hand over not “access to a developer” but a package by which changes can be made without us — with testing on a staging environment before rollout to production.
- Contract documentation: a map of functions and parameters — what the owner changes themselves, what is hardcoded immutably, and how the contract reacts to a platform changing its royalty rules.
- Payout flow diagram: the path from debiting the buyer to crediting the rights holder — author shares, platform fee, queue, and withdrawal conditions.
- Key access policies: who signs transactions and with what rights, where keys are stored, rotation, multisig threshold, and emergency revocation procedure.
- Royalty handling procedure: how to add a recipient, change shares, disable an author, and what to do in case of a stuck or disputed accrual.
- Collection configurations: royalty values in basis points, binding to tokens and addresses, and enforced collection mode for each platform.
- Set of checks: scenarios run before every change — share correctness, boundary amounts, and repeat payouts.
- Incident log: typical failures, their symptoms, and the on-call engineer's procedure.
The package is updated along with the mechanics: a discrepancy between the contract and documentation costs more than its absence.
Case study: how royalties were restored in secondary sales
Before: the payout share fell with each turnover
We examine a royalty configuration case: a collection of 7,200 tokens where royalties were specified only in metadata and executed at the platform's discretion. Monthly reconciliation showed a gap — out of 1,400 secondary transactions, payment arrived for fewer than half.
Sellers bypassed the fee with direct token transfers: by the third or fourth turnover, the authors' share fell from 5% to 1–2%, and disputed charges were resolved manually for each lot.
What was changed and what happened
We moved the payout logic into the contract: EIP-2981 for compatible networks and enforced withholding by the program on Solana, where the royalty is debited at the marketplace level, not at the seller's discretion.
For Magic Eden, mandatory enforcement was enabled — the platform does not allow a secondary transaction without payment.
Recipients were defined with weights: the collection fund, two artists, and the community treasury; bypasses via direct transfers were closed by making such tokens lose their status in the collection.
Two months later, the share of the collection's secondary sales completed with payment grew from 41% to 97%, disputed charges were zero, and manual lot resolution was no longer needed.
Royalties arrive in the same stream as the sale itself: the delay is one block, and reconciliation is by contract event, not by platform export.
How does a contract standard differ from enforced withholding?
A standard like EIP-2981 describes only the interface: the collection contract publishes to whom and what share to transfer on resale. This is data that the platform is free to read or ignore — there is no obligation in the marketplace code to pay it.
Enforced royalties are already verification on the side of the platform or settlement contract. The share is withheld at the moment of the transaction, and asset transfer goes only through an approved operator contract: an attempt to bypass it directly simply does not execute. Royalty stops being a request and becomes a condition of the transaction.
On the Solana network, the mechanics are different: the royalty share is stored in token metadata, and platforms — for example, Magic Eden — decide for themselves whether to apply it when listing a lot.
Hence policies of mandatory royalties at the marketplace level and restrictions on transfer through the token program: the market is gradually moving from a “recommendation” to an “execution condition.”
It is harder when the collection has already been launched and the contract is immutable: the rule inside such code cannot be rewritten.
Workable paths are to agree on royalty application with platforms and aggregators, wrap the asset in a new program with a strict payout rule, or move the value into gated access where the fee is built into the access itself.
The radical option is a balance snapshot and migration to a new contract with enforced withholding: it is fair but requires holder consent.
Technical questions we resolve before work starts
Before starting, we resolve five typical concerns — all of them about who can change royalty rules after launch and how. Below are brief answers so the boundaries of what is possible are clear in advance.
The collection has already been launched — can royalties still be added?
For new tokens, the royalty field is set in metadata at minting. For already launched ones, it cannot be changed retroactively: reissuing or a wrapper with new rules is required — this is a separate migration with its own plan and timeline.
What to do with platforms that do not check royalties?
Some marketplaces read the standard field and transfer the share automatically; some ignore it. We move verification to the program level: payment is calculated on sale, not at the platform's discretion — then the rule works even where there is no support.
Who owns the management keys?
The mint and metadata update keys remain with you — we work with them within the scope of the task and do not keep them. Handover is made to your wallet or multisig, along with a list of rights and instructions.
Can royalties be set to zero?
Technically yes: the field accepts zero, and sales proceed without withholding. But this weakens the collection's position — buyers who came for the author's royalties lose incentive, and the value can only be restored later by editing metadata.
How to control the rules after edits?
Every change to metadata and logic goes into a log: you can see who signed what and when. Revocation and update rights are transferred to you, and further edits are possible only with your signature — no hidden control points remain.
Let's discuss your task and come back with an estimate and plan
Royalties in the secondary market break not in code but at the junction of platforms: a contract with EIP-2981 provides the payout, and the marketplace ignores it.
To come back with an estimate and work plan rather than generalities, we need a minimum of input data — describe the task and attach:
- collection contract addresses and the standard by which the payout is declared: EIP-2981, a custom handler, or a wrapper over it;
- current distribution scheme: recipient list, their shares, and the mechanics of fund withdrawal;
- list of platforms where the collection trades, and separately those where royalties are not actually accrued;
- current rules: percentage, who can change it and under what conditions, and whether the value was fixed after launch;
- enforced royalty mode on the platform and how it affects listings and already listed lots;
- examples of transactions where the payout did not go through — they show whether the discrepancy is in the contract or in the platform settings;
- requirements for collection support: who administers recipients, how often shares change, and whether wallet rotation is needed.
In response, you will receive an analysis of the current scheme with identified bottlenecks, a map of platforms with a royalty support indicator, and a step-by-step work plan with stages and rollback points.
As a separate block — the procedure for supporting the collection after changes: who does what when shares change or a new marketplace is added. Let's discuss the task — we will come back with an estimate and plan.