ReceiptOS — verifiable execution receipts for agent tool calls
Summary
As autonomous agents and tool-calling systems become more common, we are missing a fundamental primitive: verifiable execution receipts.
Today, when an agent calls a tool (API, plugin, contract, off-chain service), there is no standardized way to prove:
-
what was executed
-
with which inputs
-
what output was returned
-
whether the result was tampered with
ReceiptOS is a minimal framework for producing and verifying execution receipts — cryptographically signed records of tool calls that can be validated off-chain or on-chain.
Problem
Agent systems (LLMs, copilots, autonomous workflows) rely heavily on tool execution:
-
API calls
-
contract interactions
-
external services
-
local scripts
However, the current model is trust-based, not verifiable.
This creates multiple issues:
-
No auditability
You cannot reliably reconstruct what an agent actually did. -
No integrity guarantees
Outputs can be modified without detection. -
No composability
Tool results cannot be safely reused or verified by other systems. -
No standard interface
Each system logs execution differently (or not at all).
Core idea
ReceiptOS introduces a simple primitive:
Every tool call produces a signed receipt.
A receipt includes:
-
tool identifier
-
input payload (hashed or structured)
-
output payload (hashed or structured)
-
timestamp
-
execution context (optional)
-
signature
Example (simplified):
{
"tool": "price_oracle.getETHUSD",
"input_hash": "0xabc...",
"output_hash": "0xdef...",
"timestamp": 1710000000,
"signature": "0x..."
}
The receipt can then be:
-
verified locally
-
passed between agents
-
anchored on-chain (optional)
-
used as proof in higher-level workflows
Why this matters
This is not just logging — it is a trust layer for agent execution.
It enables:
-
deterministic replay (with matching inputs/outputs)
-
tamper detection
-
cross-agent verification
-
audit trails for autonomous systems
-
composable tool outputs
In other words, it turns tool calls into verifiable artifacts.
Relation to Ethereum / EVM
There are several natural integration points:
-
ERC-style verifier interfaces
Contracts can verify receipts (e.g.isValidReceipt(...)). -
Account abstraction / smart wallets
Receipts can be used as execution proofs for agent-driven wallets. -
Off-chain → on-chain bridging
Receipts provide a minimal proof layer for external computation. -
Standardization potential (ERC/EIP)
A unified receipt schema + verification interface could become a shared primitive.
Design principles
-
Minimal — small schema, no heavy dependencies
-
Deterministic — reproducible hashing/signing
-
Composable — receipts can be chained
-
Transport-agnostic — works with any agent/tool system
-
Verification-first — verification is a core primitive, not an afterthought
Current status
-
MVP implemented (CLI + minimal API)
-
Basic flows:
sign,verify,verify-chain -
Demonstrations:
-
tampering detection
-
replay detection
-
receipt chaining
-
Next step:
→ define a stable schema and explore standardization path
Open questions
-
Should receipt verification be standardized as an ERC interface?
-
What is the minimal schema that still allows composability?
-
How should receipts be anchored (if at all) on-chain?
-
Do we need domain separation for different tool classes?
-
How does this interact with existing signature standards (EIP-1271, ERC-7913)?
Discussion
Looking for feedback on:
-
whether this primitive is useful at the protocol / ecosystem level
-
how it should integrate with EVM standards
-
whether it makes sense to move toward an ERC/EIP
If relevant, I can share the MVP repo and examples.
