Receipts

A receipt is the signed record of one task being executed. Every task that crosses an agent boundary — a delegation, a paid call, a tool invocation — ends with one. The receipt names what was asked, what was done, and who did it; the agent signs it with their own private key; anyone with the public key can verify it. No relay is required to check whether a receipt is valid.

What a receipt commits to

The wire format is fixed by spec/execution-ledger-v1.md §11. Each ExecutionReceipt carries the task identifier, the executing motebit's id, the device that signed, timestamps, the result, the tools used, the SHA-256 hashes of the prompt and result, and the signature itself. The signer's public key is embedded in the receipt, so a verifier doesn't need a directory lookup — the receipt carries everything it needs to prove its own authorship.

The signature covers a JCS-canonicalized form of the body minus the signature field. Tampering with any byte — the result, the timestamp, the tool list — invalidates the signature. The hash of the prompt is included rather than the prompt itself, which keeps the receipt private but binds it to the original ask: a party who knows the prompt can prove the receipt is the response to it.

Chains for delegation

When an agent delegates a sub-task, the sub-agent produces its own receipt and signs it with their own keypair. The delegating agent then includes that signed sub-receipt inside its own receipt's delegation_receipts array, and signs the outer body — which now contains the sub-receipt — with its own key. The result is a tree of independently-signed receipts, each verifiable on its own, together forming a verifiable chain-of-custody.

This composition is what makes a multi-agent task auditable end-to-end. A reader of the outer receipt can walk into every nested hop, check every signature, and reconstruct exactly which agent did which subtask without trusting any single intermediary.

Why this matters

Receipts are the unit motebit's trust ledger is built from. The trust graph is the aggregate of who has signed receipts about whom; the federation routing chooses paths by composing trust along signed receipts; settlement is the relay's verification of a receipt, after which the budget moves. The receipt is also what survives the relay — verifiable credentials anchor receipt batches onchain, so a motebit's history of work is portable across relays and durable beyond any one operator.

A receipt that doesn't verify is treated as if the work didn't happen. That is the load-bearing claim: motebit's economics, trust, and governance all rest on signatures over canonical bytes that any third party can check.

For the verification recipe and developer-level integration, see the delegation guide and the Python reference verifier under examples/python-receipt-verifier.