We wrote the spec for AI execution receipts. Here’s why the definition matters more than the product.

Description and use

The AER‑1 specification defines how to create and verify proof of AI tool calls, enabling independent verification and supporting economic interactions.

Problem

AI agents claim their work is "verifiable" but there is no shared definition of what a verifiable execution receipt is, leading to ambiguity and lack of trust for delegators.

Outcome

The spec provides a concrete, verifiable receipt format that eliminates ambiguity, allows independent verification, and supports economic interactions between agents and users.

Workflow

• 1. Define the receipt schema (fields, types, and semantics).
• 2. Implement canonical byte serialization of core fields.
• 3. Compute SHA‑256 hash of canonical bytes and publish as output_hash.
• 4. Mint the receipt at execution time, including receipt_id, timestamp, tool info, caller, side_effects, and anchor if level 3.
• 5. Publish the receipt on a public page and expose a verify endpoint.
• 6. Third‑party verifiers fetch the receipt by ID, decode canonical_bytes, recompute hash, and compare to output_hash. If they match, the receipt is verified. If an anchor exists, the verifier also checks the external commitment (e.g., Nostr relay).

Evidence

AER‑1 is a short, open specification that defines exactly what an execution receipt is: a structured record minted at execution time that binds what was called, what it returned, and when — under a SHA‑256 commitment, published alongside the bytes that were hashed, with the whole thing checkable by a stranger with no account and no trust in whoever minted it.

Source

Our implementation anchors every receipt's envelope to public Nostr relays, so the receipt's existence is witnessed outside our own servers.

Source