6 Checks Before Counting NFT Royalty Splits as Artist Income

The DN thesis

The useful evidence is a reconciled path from the stated royalty to the chosen recipient boundary. DN’s ledger exposes differences along that path without promising universal secondary-sale royalties or treating a split percentage as a legal ownership claim.

1. Separate the artwork’s rights from the token’s payment settings

A token can identify an asset or carry a transfer mechanism without establishing every right in the associated image, music or text. Before splitting income, identify the work, the relevant agreement and the recipients’ actual claims. “Prompt engineer,” “model provider” and “artist” are role labels, not automatic statutory royalty entitlements.

For a US-facing copyright claim, the Copyright Office’s report distinguishes protectable human expression from material generated without the required human authorship. [4] A service contract may grant permissions that answer a different question. Neither issue is settled by a royalty percentage in a token interface.

Keep the rights file separate from the payment ledger. The ledger can say which amount was allocated under stated terms without asserting that every term is enforceable or every underlying right has been cleared.

DN’s US copyright evidence test addresses that rights boundary. This article follows a narrower chain: a stated royalty, a collection pool, a distribution and recipient receipts.

2. Treat a royalty query as information, not collection

A marketplace can display an expected royalty while no corresponding payment has reached the recipient structure. Record the query or terms version, the sale to which it relates and the amount’s unit. Then look for a separate collection event.

ERC-2981 standardizes retrieval of royalty amount and recipient information. Its design makes royalty payment voluntary and leaves the actual payment mechanism outside the core interface. A marketplace that does not support the payment does not become obliged by the interface alone. [1]

That is why “perpetual royalties” is too strong a general promise. Transfers can occur through different venues and mechanisms; some transfers are not sales. The existence of a royalty function should not be used as a forecast of future creator income.

The DN ledger accepts an indicated royalty amount as an input and compares it with reported collection. It does not invent a sale price, choose a royalty rate or decide that the difference is an enforceable unpaid debt. The first question is whether the two amounts actually refer to the same event.

3. Define the pool before applying the percentages

A percentage needs a denominator. A creator agreement might refer to gross sale proceeds, an actual royalty payment, a net amount after specified deductions or a different contractual base. The same “50% share” can therefore describe very different amounts.

The tool begins with the royalty actually collected into one pool, then subtracts deductions withheld from that collection. It does not include the full NFT sale price unless that is genuinely the collection being reconciled. Costs paid separately from another account belong in a separate expense record.

In the main fictional case, 100 units are collected and 10 are deducted, leaving 90 for the stated split. A 50% allocation is 45, not 50. Replacing the denominator without noticing would create an apparent shortfall that came from the spreadsheet rather than the payment system.

Keep currencies and periods consistent. A token receipt and a dollar invoice need a documented conversion basis outside this simple tool. Never add the same money at the marketplace, pool and recipient stages as though each internal transfer were new revenue.

4. Check the recipient version that governed the distribution

A split’s current settings may differ from the settings that applied to an earlier balance or distribution. Record the actual configuration version and when it became relevant. A screenshot taken today may not explain a payment allocated last month.

Splits documents contracts whose controller can change recipients and shares, and distinguishes those from fixed configurations. Its documentation also makes clear that a change before distribution can affect who receives an undistributed balance. [2] This is a specific implementation example, not a universal rule for every royalty protocol.

The local model uses three recipient positions. Each share is an explicitly entered number of basis points. A confirmed unused position should have a zero share and a zero receipt; blank means the information is missing. More complex graphs need a separate record for each pool and an explicit join between them.

The tool never repairs an overallocated set of shares by rescaling it. If the known shares already exceed 100%, that conflict remains visible even when another share is unknown. A neat-looking normalized chart would hide the very error the review is supposed to expose.

5. Distinguish allocated, claimable and received

An allocation tells you how a rule assigns a balance. A claimable balance tells you something about the system’s reported withdrawal state. A receipt tells you that value crossed the chosen recipient boundary. Keep those assertions separate.

Splits describes funds being held until distribution, allocation to recipients during distribution and a separate withdrawal step, which can sometimes be combined with distribution. [3] A displayed allocation therefore need not be the same event as money reaching the creator’s wallet.

Define that wallet boundary carefully. A receipt by an intermediary that still owes the artist money is not automatically a receipt by the artist. Equally, a creator may intentionally use an intermediary; the record should describe the chosen arrangement rather than assume ownership from an address label.

For each recipient, the tool subtracts the reported receipt from the declared allocation. A positive difference can reflect an uncompleted withdrawal, another period, a missing record, disputed terms or a real shortfall. The calculation identifies the question. It does not choose the explanation.

6. Preserve rounding, unknowns and the residual

Shares can add to 100% while rounded allocations leave a remainder. In a one-cent pool split roughly into thirds, rounding each allocation down to cents assigns zero to all three positions. The one cent still exists in the pool. It is not automatically the first recipient’s income.

This worksheet performs exact integer arithmetic in hundredths and rounds each allocation down. That is a visible teaching convention, not a claim about a token’s native precision or a particular contract’s rounding rules. If the actual system uses different units or distributes residuals differently, reconcile it under that documented rule.

Unknown receipts propagate only where needed. A missing receipt for C does not erase a known allocation and receipt for A. It does, however, prevent a complete aggregate comparison of the pool with all recipient receipts.

Store the resulting record with its input provenance and evidence aliases. DN’s training-data royalty reconciliation covers a different chain—licence, covered use and payment. Neither instrument transforms a token payment into proof of authorship, training use, legal entitlement or investment return.

Illustrative cases

These cases are invented to expose the method’s boundaries. They are not observed customers, deployments, trading outcomes or legal findings.

Methodology, assumptions and limits

Net pool equals collected royalties minus deductions withheld from that collection. Each recipient allocation is the net pool multiplied by the entered basis-point share, divided by 10,000 and rounded down to whole hundredths. The residual is the net pool minus all three allocations when all three can be calculated. The tool separately compares the indicated royalty with collection and each allocation with its receipt.

Inputs accept nonnegative plain decimals with up to 12 whole digits and 2 decimals. Shares are whole basis points from 0 to 10,000. Missing inputs remain unknown. An overallocated share set is reported as a conflict rather than silently normalized. Deductions greater than the collection are rejected because this field describes amounts withheld from that pool, not externally paid costs.

The record retains raw strings and explicit example provenance. Currency labels are normalized to uppercase for display, with no currency verification or exchange-rate conversion. A blank currency label leaves the reporting unit unresolved. References are not opened or authenticated. A later download timestamp does not refresh the source documents.

Frequently asked questions

Primary sources

Reviewed 2026-11-13. A later export timestamp does not update the sources.

1. ERC-2981: NFT Royalty Standard — Royalty information retrieval and voluntary-payment boundary; not universal collection enforcement.
2. Splits: Split contract — Provider-described controller, mutable recipient configuration and distribution mechanics; no independent contract audit.
3. Splits: Distributing balances — Distinguishes pool balances, allocations and withdrawals in the described implementation.
4. US Copyright Office: Copyrightability report release — US human-authorship boundary for generative outputs; not a global rights-clearance opinion.

Related DN research

• AI training royalties: licence, use and payment
• Who owns AI-generated work?
• Agent revenue and token-holder payout rights