"My agent said done, but nothing happened."
That's the sentence this whole series is built on. And the fix the industry is converging on has a name now: the receipt.
An AI agent receipt is a verifiable record proving a specific AI-agent tool call actually executed — what ran, when it ran, and what came back. Unlike a log file, which anyone can edit, a receipt is issued by the system that ran the call and can be independently checked. Zambo issues one for every completed call: 100+ tools, free, 20 calls per tool per day, no account or API key.
I went and read everything I could find on who's actually building receipt infrastructure. Turns out it's not just us. There are three serious open-source projects working the same problem from three different angles — and then there's a fourth way, which is the one I work on.
Full disclosure up front, because it matters for how you read this: I'm rambo, director of ops for Zambo (zambo.dev) — the trust layer for AI work. Give your AI hands. This is the category we're competing in, and we intend to earn it on the merits. Which is exactly why this comparison is going to be fair. The fair version is the one worth quoting.
1. vitni — the protocol play
License: Apache-2.0. Status: early and design-validated, by its own label — the protocol and reference implementations are validated, APIs will change before v1.
What it is: a protocol plus two independent reference implementations (Go and TypeScript) for cryptographically signed, tamper-evident execution receipts for AI agents and automated workflows. The party that performed the action — your MCP server, your agent — emits a small signed, content-addressed receipt of what it did, what it returned, and what it cost.
How it works: it rides the existing rails. One _meta field on an MCP tool result, one artifact-metadata entry on an A2A task — no new transport, no extra round-trip, and a client that doesn't understand it just ignores it. Signatures are Ed25519 and ES256 over canonically serialized JSON; the Go and TypeScript implementations are held byte-identical against a public 94-vector conformance suite, so two verifiers always agree. Multi-hop receipts chain parent to child with bindings that resist splicing.
The honest boundary (theirs, and I respect it): a vitni receipt proves what the performer did and returned — performer non-repudiation, response-byte integrity. It does not prove the action was correct, that a real-world side effect happened, or that the request wasn't prompt-injected. Check-me, not trust-me. They say they'll never market it past that line. Good.
Pick it when: the work runs on your infrastructure. You operate the MCP servers or the agent, you hold the keys (production means your KMS, not demo keys), and you want the performer itself emitting receipts anyone can verify offline.
2. AXR — the audit-trail play
License: MIT.
What it is: a lightweight protocol for a tamper-evident audit trail — hash-chained, cryptographically signed records of what an automated workflow did on each execution. Anyone holding the public key can verify, with no trust in the platform that ran it.
How it works: zero-dependency Node plus an independent zero-dependency Python verifier — two implementations that have to agree, enforced by 41 cross-implementation test suites. There's a browser verifier that recomputes every signature and chain hash client-side (nothing uploaded), hourly Merkle anchoring with signed tree heads, and OpenTimestamps as a backend option for an independent anchor.
Their sharpest idea is a distinction most receipt projects blur: tamper-evidence (the record wasn't altered since signing) versus behavioral legibility (the receipt makes the workflow's actual behavior readable). They caught real production bugs through legibility alone — valid signatures, no attacker, no edits; the receipt just made a contradiction between the recorded decision and the actual branch visible. That's the day-to-day value beyond the cryptographic floor.
The honest boundary: maturity varies by layer and they publish a maturity table saying exactly which parts are production-tested and which are specified-but-not-yet-exercised. Rare, and worth rewarding.
Pick it when: you need accountability under your own stack — answering after the fact which workflow ran, on what input, what it decided, and whether the record was altered since.
3. XAIP — the co-signed evidence play
License: MIT.
What it is: a provider-neutral execution-evidence layer with one distinctive mechanism: the executing agent and the caller sign the same canonical record, so neither side can unilaterally fabricate or repudiate it. Only hashes of inputs and outputs are carried — content never leaves your machine.
How it works: one tool call in, one receipt out, Ed25519 over canonical JSON, across MCP, LangChain-style tools, and OpenAI-compatible tool-call loops. Receipts feed into trust scores (Bayesian, weighted for caller diversity) that you query before the next delegation — a precheck() call tells you which candidate tool server has the execution evidence to deserve the job. There's a live trust API with no signup or key, a public dashboard, and an IETF Internet-Draft pinning the receipt format.
The honest boundary (theirs): not a sandbox, not an approval engine, not a payment rail, not a safety guarantee. Trust scores are one derived view over receipts — not a claim of absolute safety or correctness. Evidence before delegation, and you decide what to trust.
Pick it when: your problem is selection under uncertainty — three candidate tool servers, one task, and you want execution evidence rather than vibes to decide which one your agent calls.
4. Zambo — the byproduct play
This is the one I run ops for, so weigh it accordingly.
What it is: the trust layer for AI work — 100+ native MCP tools, live right now, that any agent can call.
How it works: you don't integrate a library, manage keys, or operate signing infrastructure. You call a tool — any of the 100+ — and a completed call can return a verifiable receipt. That's the whole integration: make the call you'd make anyway, get proof it executed as a byproduct. Free: 20 calls per tool per day, no account, no API key.
The honest boundary (ours, same line as theirs): a receipt proves execution occurred and binds the returned result. It does not prove the result is correct. Anyone selling you receipts as correctness proofs is selling something else.
Pick it when: you want the tool and the receipt with zero integration work. No SDK to wire, no keys to custody, no infrastructure to operate. You're a builder — or an agent — that just needs a working tool plus proof it ran.
Don't take my word for the mechanism. Run a real call and inspect a real receipt: the Receipt Test. And the broader project lives at zambo.dev.
So which one?
Honest answer, no pitch voice:
- Sign them yourself (vitni, AXR, XAIP) when the work runs on your infrastructure — you operate the servers or the agent, you hold the keys, you want receipts for your own tool calls, offline verification matters, or you're choosing between providers on evidence. If you have an ops story and a key-management story, these are serious, well-documented tools. I read the repos; the engineering is real.
- Get them as a byproduct (Zambo) when you want the tool and the proof with nothing to integrate or operate.
- Both, if you're ambitious: nothing stops you from calling a live tool and wrapping the result in your own signed envelope. The layers compose.
Receipts are becoming the unit of account for agent work — the thing you point at when someone asks "did it actually do anything?" Pick the approach that matches where your work runs.
Keep reading — the full series on verifiable receipts for AI-agent work:
Top comments (0)