Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.
What Matters
A blockchain royalty payment can show that money moved without showing which training data was used, whether the payer owed that amount, or whether a creator received it. Story’s documentation explicitly allows both tips and contractual payments through the same payment function. DN’s reconciliation instrument separates licence terms, billable use, calculated obligations and recipient receipts before anyone calls the result training-data revenue.
DN Evidence Block
- Last verified
- 11 November 2026.
- Primary evidence
- Story protocol and payment documentation; the US Copyright Office’s pre-publication report on generative-AI training.
- What is established
- A documented on-chain payment mechanism can route payments to IP assets. Its transaction label does not independently establish training use or a legally enforceable obligation.
- DN original instrument
- DN Training-Data Royalty Reconciliation v1.0, a local calculation and evidence record.
- Evidence boundary
- This edition does not measure a creator cohort, verify individual contracts, or report observed royalty returns.
The missing link is between use and cash
“Creators get paid when AI uses their work” contains several separate promises. Someone must identify the work, establish permission to offer it, identify a covered use, calculate a payment under applicable terms, route the money and make it available to the intended recipient. A transaction explorer usually answers only part of that chain.
That distinction changes the practical question. A creator does not merely need a protocol with a royalty module. The creator needs a reproducible account of which agreement produced which receipt. A buyer needs the corresponding evidence that the payment settles the relevant obligation. An analyst needs to avoid counting the same money at every hop through a royalty graph.
Story provides a concrete example of why labels are insufficient. Its “Pay an IPA” documentation describes voluntary tips and payments required by an ancestor IP asset’s licence terms using payRoyaltyOnBehalf. The module routes the resulting shares according to configured royalty arrangements. A payment event, therefore, needs additional context before it becomes evidence of training-related revenue. [1]
DN thesis: the defensible proprietary dataset is a joined record of rights, use, obligation and receipt. Counting payment events alone produces a transaction dataset with an economic interpretation attached to it.
Claim versus the available evidence
| Claim | Evidence needed | What the evidence does not establish |
|---|---|---|
| This dataset is licensed for training. | Identified dataset version, relevant rights chain and executed terms covering the proposed use. | Registration alone does not determine whether the registrant owns every necessary right. |
| A model used the licensed dataset. | A linked training-run or billable-event record with a defined scope. | A payment, download or access permission alone does not show that a particular training run consumed the data. |
| The creator earned a royalty. | The covered event, contractual base, rate, period and recipient allocation. | A headline model revenue figure does not establish the creator’s contractual revenue base. |
| The creator was paid. | A recipient receipt reconciled to the relevant obligation and unit. | A funded pool or claimable balance is not automatically a completed recipient receipt. |
This table is DN’s evidence design, not a legal test for all countries. The Copyright Office’s training report discusses direct and collective voluntary licensing while noting practical questions about the breadth and feasibility of licensing. It does not establish that every training use requires the same permission or payment arrangement. [3]
Registration, permission and observation need different records
Start with a stable dataset identity. An alias such as “images-v4” is useful inside a team, but the underlying evidence should identify the exact manifest, version and permitted collection. A continuously changing collection needs a rule for which version each billing period covers. Otherwise, yesterday’s licence may quietly be applied to tomorrow’s material.
Then identify the agreement. Record the counterparties, applicable version, permitted activity, territory where relevant, term and payment schedule in the source documents. The public-facing instrument only needs an alias that points the authorized reviewer to those records. It should not become a repository for confidential contracts or personal information.
Story describes a Programmable IP License that connects on-chain parameters with an off-chain legal agreement. That is an architecture for expressing and administering terms. Whether a specific party had sufficient rights, whether a particular use falls within a term, and how a dispute would be resolved still require examination of the underlying facts and agreement. [2]
Finally, create the use record. “Dataset was available,” “dataset was downloaded,” “dataset entered a training manifest” and “dataset contributed to a deployed model” are different assertions. Choose the one the evidence supports. A licence may charge for access regardless of subsequent use; another may charge a fixed training fee. The billable event must come from that agreement, not from an analyst’s preferred narrative.
Follow money through three separate states
For this article, DN uses three accounting states: allocated, claimable and received. Allocated means a documented rule assigns an amount to a recipient. Claimable means the system reports an amount that a recipient can request under its current conditions. Received means the relevant payment reached the recipient boundary chosen for the reconciliation.
These are editorial definitions for the worksheet. A particular protocol may use different terms. Do not infer one state from another merely because the amounts happen to match. A failed claim, a wrong recipient, a disputed entitlement or an uncompleted off-chain payout can interrupt the chain.
The recipient boundary also needs a definition. Receipt in a creator-controlled wallet differs from receipt by an intermediary that still owes the creator money. A creator can legitimately choose an intermediary, but the dataset should preserve that choice. Otherwise, platform revenue and creator income become indistinguishable.
Transfers between protocol modules should not all become new revenue. If a buyer pays 100 units and the same 100 units pass through a pool and then a recipient wallet, a gross event sum could report 300 units. The reconciliation should track one economic payment with multiple settlement events, retaining each event identifier without adding them together as fresh customer demand.
Use the DN Training-Data Royalty Reconciliation
The instrument below handles one dataset, one agreement period and one accounting unit at a time. Enter the contractual revenue base, a revenue-share rate in basis points, any fixed fee and the recipient receipt. Add non-sensitive reference aliases for the terms, covered use or billable event, and receipt.
DN Training-Data Royalty Reconciliation v1.0
Use non-sensitive aliases and your own evidence. Inputs remain in this page; this instrument makes no external requests and saves nothing to browser storage. Downloaded files contain your entries. Example numbers are scenarios.
No record prepared. Example inputs are illustrative.
The tool always identifies its numbers as user-entered. References are not opened or authenticated. Missing references remain visible in the JSON record. A complete set of aliases changes the documentation status; it does not prove that a licence is valid, a model used the data or a debt is payable.
A worked reconciliation, with no implied market result
Suppose an agreement specifies a revenue base of 1,000,000 accounting units, a rate of 500 basis points and a fixed fee of 10,000 units. If the unit is a US cent, those inputs represent a $10,000 base, a 5% share and a $100 fixed fee. The variable component is 50,000 units and the calculated total is 60,000 units.
If the entered recipient receipt is 45,000 units, the arithmetic difference is 15,000 units, or $150 in this example. That difference is a question to reconcile. It could reflect a partial payment, a different billing period, a deduction, a mistaken base, a receipt not yet entered, or an actual payment shortfall. The calculator does not choose among those explanations.
Changing the accounting unit changes the interpretation of every amount. Do not combine token units with dollar values or silently apply a token price. If payment occurs in another asset, first document the contractual conversion rule and the relevant execution evidence outside this simple single-unit model. Then reconcile an explicitly normalized amount.
Rounding is part of the agreement. The instrument offers down, up and nearest, with halves rounded up for the nearest option. It performs the rate multiplication using integer arithmetic, avoiding binary floating-point errors in the royalty component. Choosing a convention is an input assumption; it is not evidence that a contract permits that convention.
The decision table for editors and operators
| Record state | Responsible description | Next useful action |
|---|---|---|
| Payment event only | Payment to an IP-related address or module. | Identify whether it was a tip, fee, settlement or another transfer. |
| Terms and event, no recipient receipt | Calculated allocation with settlement unresolved. | Reconcile the payment path and chosen recipient boundary. |
| Receipt, no linked billable event | Received payment with an unestablished training-use connection. | Resolve the period and event linkage before labeling it training revenue. |
| All references recorded | Reconciliation ready for substantive review. | Check documents, calculations and receipts independently. |
How an automatic update should work
An update pipeline should append new evidence without rewriting old evidence labels. A newly recorded receipt can resolve a previously open difference. It cannot retroactively turn a voluntary tip into proof of a training run. Preserve the original record, the new record and the reason for the change.
Use a stable schema identifier, dn.training-royalty-reconciliation.v1, alongside the calculation version and record-creation timestamp. The article’s source-review date is separate from the time a reader creates an export. A fresh timestamp on a worksheet must not make an old contract or receipt look newly verified.
For a published cohort, define inclusion rules before collecting the numbers. Specify which agreements qualify, which period is covered, how duplicated transfers are removed and how missing evidence is counted. Publish a coverage denominator: for example, how many selected records have linked terms, billable-event evidence and recipient receipts. This edition supplies the instrument, not an observed cohort statistic.
Methodology and limits
The calculation is rounded(base × basis points ÷ 10,000) + fixed fee. The difference subtracts the entered recipient receipt. Inputs must be nonnegative whole accounting units; the rate is limited to 0–10,000 basis points. The current instrument models a single uncapped share plus a fixed fee. Tiered rates, advances, recoupment, caps, sublicensing waterfalls, taxes and foreign exchange require an expanded model.
Our source review establishes documented mechanisms and the limits of what payment labels can demonstrate. It does not determine copyright ownership, applicable exceptions, contractual enforceability or whether a particular training activity requires a licence. Those questions can change the obligation before any arithmetic starts.
Frequently asked questions
Does an on-chain royalty prove a model trained on my work?
No. It can support a payment claim. The training-use connection needs its own evidence and a link to the relevant work and model run.
Is claimable revenue the same as money received?
Keep them separate. The reconciliation needs a defined recipient boundary and evidence that the payment reached it.
Can the calculator tell me what I am legally owed?
No. It calculates an entered arrangement and records evidence gaps. Its arithmetic difference is not a legal finding.
Can an agent consume the result?
Yes. The JSON export carries inputs, units, assumptions, evidence aliases, results and limitations. Software should preserve those qualifications when summarizing the record.
Related DN research
DN’s AI content-platform comparison covers production workflows. This article addresses the separate question of reconciling a data-related payment to terms and use.
Primary sources
- Story: Pay an IPA — payment purposes and royalty routing.
- Story documentation introduction — modules and the Programmable IP License architecture.
- US Copyright Office: Generative AI Training, pre-publication report — licensing discussion; identified as a report rather than legislation.
Corrections and change log
11 November 2026 — v1.0: introduced the rights/use/payment distinction, a single-unit royalty reconciliation and versioned JSON record. Send primary evidence or calculation corrections to press@decentralised.news, identifying the affected statement and source. No protocol paid for inclusion; this edition contains no sponsored ranking.
