Royalty Engine

The Royalty Engine turns money paid in for a dataset into claimable earnings for whoever holds that dataset's ownership fractions. It does this with a running accumulator rather than a periodic calculation: there is no billing cycle, no invoice, and no batch job that decides who gets what.

Current limitations

This page describes the current repository implementation. It retains fractional earnings across claims and transfers, bounds accumulator growth, and rejects duplicate token IDs in batch share transfers. These source changes do not establish which implementation a particular deployment runs. Distribution arithmetic still rounds down: a sufficiently small payment relative to the assembled share total can produce no accumulator increment and therefore no additional claimable earnings.

How it works

Three inputs: money in, the dataset's assembled share total, and who holds how much. The middle one is easy to miss and decides the most interesting behaviour on this page — see Intended treatment of late claims below.

Paying revenue in

The caller need not be a licensee or a nominated account. The current implementation requires an owner-managed token allowlist for every deposit, including native currency; new or upgraded proxies initially admit no tokens. Earlier deployments accepted a token address without this gate. Verify the deployed implementation and its admission configuration before paying: fee-on-transfer and rebasing tokens are unsupported. A dataset can account for several admitted currencies separately, subject to its active-token limit.

A platform fee is taken off the top at an administrator-configured rate before anything is distributed; the remainder is what holders share. The engine records the fee separately; withdrawPlatformFees sends it to the configured collector.

Claiming

Earnings accrue against a contributor's DID-Bound Account. Claiming is not gated on who calls it — anyone may submit a claim, and msg.sender plays no part in it. What the DID decides is the payee: the caller names a DID, and the engine pays the wallet that currently owns it.

The funds never sit in the DID-Bound Account. It is the identity the accrual is recorded against, not a balance you withdraw from.

Intended treatment of late claims

A distribution is divided by the share total the dataset version was assembled with — not by the shares minted so far. Shares nobody has claimed yet still have a slice of every distribution, and that slice is held for them rather than shared out among whoever happened to claim early.

The intended result is that late minting preserves entitlement to earlier distributions. Actual claimable amounts are subject to integer rounding and the current accounting limitations above; this is not a guarantee of full recovery.

Intended treatment of transfers

Share movements notify the engine after balances change. The callback accounts for both parties using their pre-transfer balances.

The intended split is: revenue distributed while you held a share is yours whether or not you still hold it, and revenue distributed afterwards is the new holder's. Receiving a fraction is intended to confer no claim on revenue that arrived before the transfer. Claimable amounts remain subject to the integer rounding described above.

Note the contrast with the paragraph above, because the two look alike and are not: claiming shares you were allocated at assembly is backdated, receiving shares from another holder is not.

What this page does not describe

Earlier versions of this page described a metering pipeline: usage events carrying rows, bytes and durations, priced through a versioned valuation configuration against an attribution snapshot, drawn from a revenue account held by the data consumer, with dispute hold-backs and Train-Now-Pay-Later terms.

None of that exists. There are no usage events in the protocol, no valuation configuration, no revenue accounts, and no dispute reserves. The engine's entrypoint takes a dataset, a token and an amount — it has no way to receive a usage measurement and no pricing to apply to one. Anything that meters consumption and decides what to charge for it sits outside the protocol and pays the result in.

Interfaces

• In: revenue, paid per dataset and currency; and a settlement callback from Tokenized Ownership Proofs on every share movement.
• Out: claims, paid to the wallet behind the claiming DID, and platform fees to their collector.
• Identity: claiming resolves through the DID registry — see Identity.

Accounting rules and limits

• A distribution is split against the assembled total. Unclaimed shares are reserved, not redistributed, so the arithmetic does not change as contributors claim.
• Transfers preserve prior accrual in the current implementation. The callback settles pre-transfer balances and retains fractional earnings when recording the new balances.
• A claim pays the DID's current owner. Rotating the wallet behind a DID redirects future claims with no migration and no reassignment of what has accrued.
• The fee is taken before distribution, so what holders divide is always the post-fee amount.