Royalty Receipts

Trust Model

Verifying a receipt requires the receipt, the platform's signing key id, and nothing else — no account, no database query, no network call to the issuing platform. Verification can be done entirely offline, in any language with HMAC-SHA256 and JSON. You do not need to trust the issuer's runtime; you only need the public specification.

Receipt Contents

A v1 receipt records the render and license identifiers, the asset role and catalog reference, the credit split (gross, creator share, platform take), the measured exposure seconds and their basis, the settlement timestamp, and the double-entry ledger idempotency keys the settlement booked. Amounts are integers — fractional credits do not exist in the ledger.

v2 receipts add one thing: the revocation feed pin. Every settlement records where the public revocation chain stood when the money moved (`feed_height` and `feed_head_hash`). Replay the feed later and a license revoked before settlement is provable from the receipt alone — the revocation entry sits inside the pinned chain. The pin is tamper-evident context, not a live-state claim: enforcement happens at the render gate.

How Verification Works

The signature is an HMAC-SHA256 over the canonical JSON of the receipt: lexicographically sorted keys, no whitespace, raw UTF-8, and schema-aware numbers — integer fields never carry a fractional part, and the exposure seconds field follows float repr semantics (`6.0`, never `6`). This number rule is the only hard part; a generic canonicalizer mangles it, and we broke it live before fixing it.

Before the signature is even checked, three cross-checks hold on their own and require no secret: amounts are non-negative, gross equals creator share plus platform take (the balance invariant), and the exposure basis is one of the allowed values — `measured` (worker telemetry of the delivered artifact) or `requested` (the honest fallback when telemetry was absent, meaning billed seconds were not measured). A mutated receipt fails on its own arithmetic before cryptography.

Key Rotation

Each receipt names the signing key that produced it (`key_id`). Retired secrets stay addressable by key id for the lifetime of receipts signed under them; an unresolvable key id verifies as`unknown_key`, never as valid. A platform with no signing secret configured ships receipts unsigned and says so — an unsigned receipt is an honest artifact, never a fabricated signature.

Worked Example

The specification carries a real receipt from a live settlement end to end — canonical bytes, signature, and reference implementations in Python and JavaScript that both reproduce it byte-for-byte. Read it before writing a verifier: Royalty Receipt Specification v1.

Content Provenance

Receipts cover the payment half of the audit chain. For the content half — signed proof of what a generated asset is and how it was made — see C2PA Content Credentials. Together they close the chain: content → exposure → settlement → payment, each link independently checkable.

Why This Model

Receipts are one of three proof artifacts a rightsholder holds — the whole model (measured exposure, provable revocation, what each artifact answers, and the honest limits) is laid out in Verified Royalties.