ReceiptOS: a portable proof substrate for verifiable agent execution
Why this thread
Following the threads on ERC-8312 (bounded agent actions), ERC-8313 (protocol interaction manifests), ERC-8294 (validation networks for ERC-8004), and the WYRIWE input-commitment work — there’s a piece missing upstream of all of them: what does the receipt for a single agent action actually look like, and how do you verify it without trusting the system that produced it?
That’s what ReceiptOS is trying to answer. Posting this to connect it explicitly to the composition stack that’s forming in this category (8001 records authority · 8312 meters it · 8275 settles · 8294 validates · 8313 describes the interaction · WYRIWE binds the input).
The problem
Every agent framework today logs its own actions in its own format, trusted only as far as you trust that framework’s backend. There’s no portable, recomputable unit of “this agent did this action, here’s proof, verify it yourself” that survives moving between tools, agents, or chains. If you swap coding agents, wallets, or execution substrates, your provenance trail doesn’t come with you.
The approach: the Evidence Capsule Model
ReceiptOS treats every agent action as passing through a defined pipeline that produces a recomputable receipt:
- Capture — the action and its inputs/outputs are captured at the point of execution (agent-agnostic; currently adapters exist for Claude Code, with Codex CLI / Cursor adapters honestly labeled as schema sketches, not production-ready).
- Canonicalize — the capsule is reduced to a canonical form so the same action always hashes the same way regardless of serialization quirks.
- Anchor — the canonical hash is anchored externally (anchor-mechanism agnostic — the anchor is a pluggable target, not a fixed chain or service).
- Verify — anyone can recompute the hash from the raw capsule and check it against the anchor, without trusting the backend that generated the receipt in the first place.
Three architectural axes drive this:
- Action-type agnosticism — a receipt doesn’t assume what kind of action it’s describing (a trade, a code edit, a contract call).
- Pluggable policy boundary — what counts as a valid/complete capsule is policy, not protocol; swappable per deployment.
- Anchor-mechanism agnosticism — same property TMerlini raised on the cap-cursor thread: the anchor is an implementation choice, not the thing itself.
Where it’s running today
crystal-receipt— the core substrate (canonicalization, capsule schema, anchoring).Stealth(a confidential coding-agent desktop app, fork of opencode) — integrates the receipt layer to anchor evidence from real coding-agent sessions.Chronicle— a history-accumulation layer above ReceiptOS, materializing anchored receipts into a queryable historical record.
We’ve verified an end-to-end path: Stealth session → evidence capture → anchor → Chronicle materialization, independently recomputable at each step.
How this maps onto the stack forming in this category
- 8001 records that an agent has authority to act. ReceiptOS doesn’t touch this layer — it assumes some authority record exists upstream.
- 8312 meters how much authority has been consumed, enforced on-chain and independently re-derivable from state (the cap-conservation pattern from the 8312 thread).
- 8313 (PIM) describes how to correctly interact with a protocol — the execution recipe. If an agent used a PIM to build its transaction, that’s exactly the kind of thing a ReceiptOS capsule should capture and hash, so a verifier can check not just that a cap was respected but that the correct interaction pattern was followed.
- WYRIWE binds a committed input hash to what the agent actually reasoned over, before execution. This is close in spirit to ReceiptOS’s canonicalization step — both are trying to make “what did the agent actually see/do” independently recomputable rather than self-reported. The difference is scope: WYRIWE is focused on the input-commitment boundary specifically; ReceiptOS is trying to be a general-purpose capsule format for the whole action, of which a WYRIWE-style input hash could be one field.
- 8294 validates outputs via a validator network with economic or reputational consequence. A ReceiptOS receipt is a natural artifact for a validator to check against — it’s the recomputable claim being validated.
- 8275 (referenced in the 8312 thread as the settlement layer) is where a verified receipt could ultimately clear.
None of this requires ReceiptOS to be “the” standard — the point of the capsule model is to be swappable in the same way the cap cursor and the anchor substrate are meant to be swappable. What we’re looking for is whether the capsule shape (capture → canonicalize → anchor → verify) is missing from the current composition, or whether it already exists implicitly somewhere in 8001/8312/8275/8294/8313 and we’ve just been duplicating it under a different name.
Where we’d like input
- Does the capsule/canonicalization step overlap with anything already specified in 8313’s execution layer, or is it genuinely upstream of it?
- Is there appetite for a formal
requires:/extends:link between ReceiptOS-style capsules and WYRIWE’ssanitization_pipeline_hash, the way TMerlini proposed linking PIM and WYRIWE? - Anchor-mechanism agnosticism — has anyone else in this category run into the same tension between “cheap to anchor often” and “expensive but canonical” that 8312’s Base Sepolia cursor discussion touched on?
Happy to share the schema, the canonicalization spec, or a worked example (Stealth session → Chronicle) if useful.