R+2 · Receipts

One action. One receipt.

A cryptographically signed record for every action and resource an AI agent touches. Frozen as a baseline, with test vectors published under licence, re-derivable byte for byte across implementations, and rolled up into Merkle roots for public anchoring.

StateStaging · release candidate 4
SignaturesEd25519 + ML-DSA-65
01 What a receipt is

Evidence, not a log line.

Logs record what a system chose to write down, in a format only it understands, in a place its operator controls. A receipt is different: a small, self-contained, signed statement about one action that anyone can verify without trusting the system that produced it.

Each receipt describes the action, names the agent and the intent behind it, points to the receipt before it, and carries a hash of the result instead of the result itself. Sensitive content stays where it is; the receipt carries its digest, so a copy can later be checked against it. Identifiers, resource names and times in the receipt stay readable.

Because the bytes are canonical and the signatures are hybrid, a receipt issued today can be checked by a different implementation, in a different language, decades from now.

The fourth release-candidate tag is signed by the founder. Under audit, ahead of independent certification.

02 Anatomy

Eleven fields, each answering an auditor's question.

Receipt fields01 / 11
FIELD 01

Which action?

A unique identifier for this action, so it can be referenced, disputed or revoked on its own.

FIELD 02

What came before?

A pointer to the receipt that came immediately before. This is what turns isolated records into a chain.

FIELD 03

What was done?

A tool call, a model inference, a file write, a payment, a plan step.

FIELD 04

To what?

A record, an account, a document, an endpoint.

FIELD 05

Which model?

Which model produced the result, so behaviour can be traced to a specific version.

FIELD 06

Which vendor?

Which vendor served the model or tool. Useful when the same model is available from several places.

FIELD 07

Who paid?

The customer's own key, a hybrid arrangement, or a managed account.

FIELD 08

How was it routed?

How the call was routed, which attributes every execution to a keyed identity.

FIELD 09

When?

When it happened, in a canonical form, so ordering is unambiguous.

FIELD 10

What came back?

A digest of the result. The content itself never needs to leave your systems.

FIELD 11

Who vouches for it?

A classical and a post-quantum signature over everything above. Both are required.

03 What it looks like

Plain JSON. Hard to fake.

Readable by a person, checkable by a machine. The exact schema and test vectors are shared in a private briefing.

Each receipt is a small JSON document: a body that describes the action, a digest of that body in one exact byte form, and two signatures over it. Change one character and the digest no longer matches; remove a signature and the receipt is refused.

04 Lineage

From one receipt to a root anyone can check.

Receipts point to their parents by content ID, forming chains per session. Chains roll up into Merkle trees following the RFC 6962 rules used by Certificate Transparency, and a log provides inclusion proofs across sessions.

Roots are written to a public chain. Anyone holding a receipt and its audit path can prove it was included, without asking DCS.

05 What it resists

Attacks the format is tested against.

TAMPER

Edited body

Any change to any field changes the digest and breaks both signatures.

DOWNGRADE

Stripped PQ leg

Removing the ML-DSA signature from a hybrid receipt is a rejection, not a fallback.

TRANSPLANT

Wrong chain

Domain separation and typed identifiers stop a receipt being moved into another session, tenant or version.

MERKLE

Fake inclusion

Second-preimage and forged consistency proofs from the RFC 6962 attack classes.

KEYS

Revoked signer

A revoked key cannot issue new receipts; old receipts still verify under their issuance-time profile.

REPLAY

Old receipt, new context

Purpose and context binding stop a valid receipt being replayed somewhere it never belonged.

11questions every receipt answers
2signatures on every hybrid receipt: one classical, one post-quantum
0bytes of your payload inside a receipt: it holds digests, plus identifiers and times that stay readable
1receipt format, checkable without asking DCS
06 Questions

About receipts.

Does a receipt contain my data?

No. It contains a hash of the result and identifiers for the action and resource. The content stays in your systems.

How big is a receipt?

A few kilobytes, most of it the ML-DSA-65 signature. It does not grow with the size of the content it describes.

Can I verify a receipt without DCS?

Yes, for the signature, the hash and inclusion: the canonical form and algorithms are published standards, and those checks run offline. Try the demo on the verifier page.

What happens if a signing key is compromised?

The key is revoked in the registry. New receipts from it are rejected, while receipts issued before the compromise are judged under their issuance-time profile.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.