EIP-2981 and 0xSplits: Setting Up Guaranteed NFT Royalties

NFT royalties are lost on resale: where the logic breaks

The EIP-2981 standard describes only a way to report royalties: the collection contract returns the share and the recipient address on request. This signal has no force — the payment is executed by the party conducting the transaction.

Within the native marketplace everything holds, but as soon as the token leaves it, royalty loss begins.

A third-party marketplace may choose not to request such a signal at all: secondary sales go through its own contract, and token transfer remains an ordinary transfer between wallets.

In this transaction there is neither a share for the author nor a recipient address — the author learns that the royalty did not arrive by parsing the transfer history manually.

A separate class of bypass is a wrapped copy of the token. The wrapper contract holds the original on its balance and issues its own token, which is then sold onward; for royalty logic this is already a different asset, and the share is not accrued.

The same result comes from issuing the collection in a new contract: the image matches, but the link to the original logic is broken.

A separate leakage point for royalties is the split of payments between co-authors.

The recipient is set as a contract that distributes the flow across addresses, and if the shares are set incorrectly or one of the authors changes wallets, the accruals silently diverge, settling where no one withdraws them.

Below we break down how this is closed: what covers the signal on external marketplaces, how the wrapper is tracked, and how authors’ shares are fixed.

What configured NFT royalty mechanics deliver: the effect in numbers

The effect of configured mechanics is visible not in a presentation but in a sample of real transactions.

Before it, marketplaces that do not read the NFT royalty standard give the seller the entire amount, and the authors’ share either does not arrive at all or is collected manually.

After it, royalty collection rate is calculated as the share of transactions where the royalty was accrued from the calculated base, and remains close to the calculated level across all sales channels that the standard supports.

Automatic payments to authors are built on a splitter contract: on every sale it receives the royalty amount and distributes it across addresses according to the configured shares.

Manual top-ups disappear — there are no reconciliations, no internal debts between co-authors, and each payment is tied to a specific transaction. The rounding remainder accumulates in the contract and goes out with the next payment instead of being lost.

Author share accounting is configured once: percentages and recipients are fixed in the distribution rules, and adding a new participant is a share change, not a rebuild of the scheme.

A co-author who leaves the project stops receiving royalties by the same action, without manual removal from lists.

Transparency of accruals removes the most expensive class of disputes between co-authors.

Each participant sees the basis for accrual, the history, and the current balance, so the question “I was underpaid” turns into checking a single record instead of going through chats and statements. We break down how this is configured for a specific project and its sales channels.

Royalty accrual methods: comparison of approaches and limitations

NFT royalties are not a property of the network but an agreement between the contract and the marketplace: the token cannot withhold a percentage from a sale.

It either publishes a value that the marketplace voluntarily relies on, or distributes the payment itself at the moment of settlement.

Therefore royalty accrual comes down to three schemes, and the choice is determined by where the collection’s secondary turnover actually takes place.

What to consider when choosing

No option gives an absolute guarantee: marketplace limitations lie outside the contract. Not all marketplaces respect the signal in metadata, and a direct token transfer between wallets does not trigger any royalty function.

Payment split on the contract closes settlements within your logic, but external sales remain uncontrolled. A hybrid removes some risks, but a discrepancy in recipient shares between loops causes payments to start arriving in different amounts.

Implementing royalty mechanics: stages of engineering work

The work order goes from auditing the current contracts to handing over documentation. Each step leaves an artifact that can be checked before the next one starts: a share scheme calculated before the audit almost always diverges from how the contract actually distributes funds.

1. Contract audit. We examine how EIP-2981 is implemented: whether royaltyInfo exists, who is set as the recipient, and what happens on a marketplace that ignores the standard. We record discrepancies — for example, royalties tied to the minter’s address and not surviving resale.
2. Share distribution scheme. We consolidate recipients, shares, and conditions into a table with wallet addresses. Here we also decide the mutability question: edits after deployment are possible only in a contract with an admin account — this is a deliberate choice, not something “we’ll add later.”
3. Payment setup. We assemble the split via 0xSplits, set the threshold after which accumulated funds are distributed, and the initiation order. We specify who covers gas and what the recipient sees in their wallet.
4. Test loop. We run the full cycle on a network copy: issuance, sale with royalties, payment to several addresses, repeat run. We verify that the amounts match the calculated ones and the transfer does not fail when a recipient is unavailable.
5. Documentation handover. We provide the share scheme, contract addresses, payout instructions, and a manual scenario for automation failure. The client’s team repeats a payout according to the instructions without our involvement.
6. Training and monitoring. We walk the responsible people through where to view the accumulated balance and how to start distribution. We go through the first payout cycle alongside them and reconcile transactions.

Configurations, payout schemes, and regulations: what the team retains

Project handover is not a final call and not an archive of source code, but a working kit that your team then uses to manage NFT royalty accruals on its own.

• “Share scheme” — a table of recipients: wallet addresses, percentages, grouping (authors, fund, partners), change rules, and the threshold after which an edit requires multisig.
• “Royalty configurations” — which parameters are set in the collection contract and in the 0xSplits splitter, how secondary market marketplaces read them, and what happens where the standard is not supported.
• “Dispute regulations” — the procedure for an erroneous address, a stuck payout, a change in the recipient set, and a buyer claim: who decides, within what timeframe, and what evidence is recorded.
• “Access and key policy” — where admin keys are stored, what roles the contract has, how many signatures are needed for critical operations, and how their rotation works.
• “Team instructions” — step-by-step operations with commands and screens: issuing a batch, changing a share, withdrawing accumulated funds, reconciling the splitter balance.
• “Documentation package” — architecture description, contract addresses by network, change history, test scenarios, and a pre-release checklist.
• “Payout monitoring” — a set of alerts for sharp movements and a reconciliation report: accrued versus actual transfers, so a discrepancy is found the same day, not a month later.

We review each item during the defense: who uses it, what to do when the responsible person changes, and where the source of truth is when data diverges.

Case study: royalty collection rate before and after rebuilding the loop

The project is an ecosystem with gaming collections and in-game assets: several storefronts, tens of thousands of secondary transactions per month, 11 authors, and 4 recipient wallets.

Before the rebuild, royalties flowed to one address: some storefronts did not pass them on at all, some withheld them, and the distribution between authors was calculated manually from exports. This implementation case study is about metrics before and after, not generalities.

What it was before the rebuild

Royalty collection rate was about 22% of the calculated volume: transactions outside supporting storefronts simply fell out, and another portion was lost in transfer.

Each month, 40–50 manual transactions went out with a separate reconciliation for each, and disputed accruals were sorted out for weeks — until a single source of truth appeared.

What was changed and what the result was

Royalty rights were fixed in the collection contract via EIP-2981, and share distribution was moved to 0xSplits: proportions are set once, and payment happens automatically when funds arrive.

Royalty collection grew 4.1× compared with the same period, and manual transfers are gone: one reconciliation per month remains instead of forty operations.

The share of payouts reaching authors in the same settlement cycle rose from 63% to 99%, and dispute resolution for accruals dropped to one or two days.

How does the standard signal differ from payment splitting on the contract?

The standard signal is metadata, not a payment mechanism: the function returns the recipient address and share, which the marketplace reads itself and initiates a transfer according to its own logic.

The contract itself withholds nothing — EIP-2981 defines only the response format, so accrual depends entirely on whether a specific marketplace reads it.

Payment splitting works the opposite way: funds arrive at the contract specified as the recipient and are divided among participants inside it according to the configured shares.

The distribution logic is visible in the code, can be covered by tests, and does not depend on the marketplace’s good faith — 0xSplits assembles such splitting from ready-made modules.

The task dictates the choice. One recipient and a priority on compatibility — the signal is enough: it does not require deploying a contract and is updated by editing metadata.

Several authors, changing shares, or a requirement for guaranteed payment — a splitting contract is needed.

In practice, the approaches are combined: the signal points to the splitter contract address, the marketplace pays on its own initiative, and the code already performs the distribution between authors.

We run scenarios on target marketplaces before release — otherwise NFT royalties are configured formally and do not reach recipients.

Common technical questions and our answers on payout mechanics

Royalties in a token are not a marketplace rule but a signal inside the contract: a storefront may read and execute it, or it may ignore it.

That is why royalty protection is solved not by hoping for the marketplace’s good faith, but by where exactly the condition is recorded and who verifies it.

Below are four doubts that most often come up when discussing payout mechanics.

What happens to payouts after the collection is reissued?

A reissue resets the linkage: new tokens get new logic, while old ones continue to live under the previous one.

Before migration, we take a snapshot of holders, issue a contract with the same royalty condition, and transfer rights; we close transfers of old tokens so that no copies with the previous mechanics remain.

How are royalties divided between several authors?

Shares are set at issuance in the distributor contract: the author, studio, and fund receive their portions automatically on every incoming payment, without manual transfers.

Weights cannot be rewritten retroactively — that requires a new contract, so the ratio is fixed in a document before launch.

How can I verify that funds actually arrived?

We reconcile the contract event log with actual receipts to the recipient’s wallet and provide a report by period. Any discrepancy is visible per address — for a specific token and sale, not “on average across the collection.”

Let’s discuss the task and come back with an estimate and implementation plan

To make the estimate based on facts rather than assumptions, it is enough to send the collection inputs: deployment network, contract addresses, current recipient shares, and how payouts are organized now.

If royalties are not yet configured, a description of the model is enough — how revenue is divided between authors, the platform, and partners on secondary sales, and what should happen when a recipient changes.

• What you send: collection contract addresses or their draft, network, token standard, and current payout proportions.
• How revenue works today: the marketplaces where trading takes place, and which of them read royalties from the contract (via EIP-2981 or their own logic) and which ignore them.
• Share agreements: who receives payment, in what proportions, and whether they change over time.
• Loop constraints: reporting requirements, who can see the amounts, and who has the right to change distribution parameters.
• What we come back with: an estimate of work, a staged implementation plan, and implementation timelines tied to your releases.
• Loop handover: deployment scheme, accesses, keys, roles, and the regulation under which the loop passes to your team or remains under support.
• After launch: a set of metrics that show payouts are proceeding correctly, and the procedure for changing shares.

Describe the task — we will come back with an estimate, a work plan, and a clear handover procedure. The more specific the inputs, the more accurate the timeline range.