The Royalty Economy
How revenue paid in for a dataset becomes claimable earnings for the people who contributed to it, in plain terms.
The royalty economy is the part of the protocol that answers one question: money arrives for a dataset — who gets it, and how much?
The answer has three moving parts, and no billing cycle anywhere in it.
The three parts
Shares. When a dataset version is assembled, it commits to a share allocation over the contributors whose work is in it, and to the total number of shares that version may ever issue. A contributor turns their allocation into shares by proving membership in that commitment. Shares are ERC-1155 balances, one token id per dataset version, held against the contributor's identity.
Distribution. Anyone can pay revenue in for a dataset — the call is open, and not restricted to a licensee or a nominated account. Payment uses a token admitted by the protocol owner — including the native currency when admitted — and one dataset can accumulate in several currencies at once. A platform fee is taken off the top at a governed rate; the remainder is what shareholders divide.
Claiming. Earnings accrue against the account bound to a contributor's identity, and a claim pays out to the wallet that currently owns that identity. Nothing has to be distributed to individuals: the accrual is arithmetic against a running accumulator, and a claim collects whatever it has reached.
Access grants and revenue payments are independent. Nothing meters a read or turns a grant into a charge; pricing and billing happen outside the protocol.
Two things worth knowing
Claiming late costs you nothing. A distribution is divided by the share total the version was assembled with, not by the shares minted so far. Shares nobody has claimed yet still get a slice of every distribution, and that slice is held for them rather than shared out among whoever claimed early. Claim a year after assembly and you collect your full share of everything that arrived in that year. There is no race.
Selling a share does not sell the earnings. Every movement of shares settles both parties against their balances before the move. Revenue that arrived while you held a fraction is yours whether or not you still hold it; revenue that arrives afterwards is the new holder's. Buying a fraction confers no claim on what came before the purchase.
These two look alike and are not: claiming an allocation you were given at assembly is backdated, receiving a share from another holder is not.
Who earns
| Party | For | How |
|---|---|---|
| Contributors | Samples, labels, corrections | A share allocation in the dataset versions their fingerprints are assembled into |
| Validators | Verdicts and grades | A validation is itself a fingerprint with a contributor, so it can carry weight in an allocation |
| Assemblers | Curating a version and committing its allocation | Whatever share of it they allocate to themselves |
| The protocol | Infrastructure and governance | A fee taken off each distribution, withdrawn separately |
Note what decides all of it: the share allocation fixed at assembly. The protocol enforces that allocation faithfully and has no opinion about what it should be. Who appears in it, and in what proportion, is the assembler's decision — the contracts derive none of it from contribution counts, grades or parent references.
An assembler does need some rule, and the reference publisher's default is the simplest one: a flat weight per fingerprint, so a contributor's share is proportional to how many of their fingerprints are in the version. That is a choice made in the tooling, not a rule of the protocol, and an assembler is free to weigh differently.
What the protocol does not decide
It does not price anything. The distribution entrypoint takes a dataset, a currency and an amount; it cannot receive a usage measurement and has no pricing to apply to one. Whatever decides what a consumer owes — a licence negotiated off-chain, a subscription, a per-seat deal, a metered API in front of the data — sits outside the protocol and pays the result in.
That is a deliberate boundary rather than a gap to be filled later. The protocol's job is that once an amount arrives, its division is not up for negotiation.
What this page no longer claims
Earlier versions described a much larger machine: usage metering of training, fine-tuning and evaluation consumption; metered inference of downstream models derived from licensed data; Train-Now-Pay-Later licensing with escrow-like agreements; performance-linked multipliers unlocking on KPI or SLA thresholds; staking-as-confidence establishing ownership; backers earning in proportion to stake impact; time-scoped ownership fractions that evolve as staking and verification proceed; royalty rate, attribution scope, KPI clause, sunset and dispute-window contract terms; reallocation of royalties after a challenge; and repackaging fractions into portfolios.
Almost none of it exists. There are no usage events in the protocol, no metering, no valuation configuration, no revenue accounts, no escrow, no dispute reserves and no staking. Ownership fractions are not time-scoped and do not evolve — they are minted from a commitment fixed at assembly and thereafter move only by transfer.
Reputation is the one to state precisely, because a field for it does exist. A campaign's metadata carries a qualification block — it is required — and one of its four axes is crs_min, a minimum contributor reputation score. The others are skills, credentials and geo. A task does not repeat that block: it may carry qualification_override, whose four axes are the same and where an absent axis means inherit from the campaign rather than no requirement. Mind the name, because getting it wrong fails quietly — a task document's top level accepts unknown properties, so a qualification written there validates and is then ignored. What does not exist is anything on the other side: nothing computes a score, nothing checks any of the four, and the indexer keeps the whole block as opaque JSON without decoding it. So these are declared requirements with no mechanism, which is a different thing from either having reputation or not having it.
Where to go next
- Royalty Engine — the same mechanism in full, including why a transfer cannot take accrued earnings.
- Tokenized Ownership Proofs — how shares are claimed and held.
- Data Assembly — where the share allocation comes from.
- Future Directions — what is aspiration, kept separate on purpose.
Last updated