Receipt Protocol

Minimal self-attested activity receipts for AI agents.

We don't do identity. We do receipts.

Block Buzz, Sigil, MCP-I, TRAIL, OpenA2A, AgentStamp, 1f916, Treeship, Raucle — they answer "who are you?" or "what did you actually do?".
We answer "what did you say you did?".

Why this exists

AI agents are starting to do real things — buy API credits, call tools, move money, submit work. But when an agent says "I completed the task" or "I made the payment", how do you know it's not hallucinating?

You don't. Not from the agent itself.

Receipt Protocol gives agents a way to sign and record their claims, so those claims can be carried to another platform and verified — without trusting the agent, without trusting a central authority, and without blockchain.

What it proves: "This agent claimed it did X, at this time, and this record hasn't been tampered with."

What it doesn't prove: That X actually happened. (For that, you need peer attestation or external verification.)

The Landscape

This space is getting crowded. Here's where we fit:

Project	What they do	Complexity	Our take
1f916	Full agent society — event logs, Merkle trees, witness countersigning	Heavy	Great architecture, but you need 600+ agents to make it work
Treeship (SRI)	DSSE-signed receipts, Merkle root, publishable	Medium	Solid, but it's a library you integrate into
Raucle	Gate with 8 checks, capability receipts, policy proofs	Heavy	Built for governance/regulatory, overkill for simple use
AgentStamp	ERC-8004 reputation, hash-chained event log	Medium	Web3-focused, on-chain identity
Traceseal	Sandbox-sealed receipts, operator signatures	Heavy	You need to run their sandbox
APS (IETF)	Agent passports, delegation chains, 3-signature policy	Very heavy	Formal standard, years from production
AIVS (IETF)	Agentic integrity verification, proof bundles	Medium	Audit-focused, .tar.gz archives
Sanna	Governance receipts for ISO 42001 / SOC 2	Heavy	Compliance-first, not developer-first
Agent Receipts (Otto Jongerius)	Open spec, Ed25519 + W3C VC	Medium	"C2PA for agent actions" — promising spec
Receipt Protocol (this)	Minimal Ed25519 receipts, self-attested, just HTTP	Lightest	No accounts, no SDK, no blockchain. Just POST and verify.

We are the minimal viable layer. Everyone else is building the full stack. We're building just the signing and verification.

Quick Start

No accounts, no API keys, no blockchain. Just HTTP.

# Issue a receipt
curl -X POST https://receipt.lifari777.workers.dev/issue \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "[email protected]",
    "action": "called payment-api",
    "platform": "stripe.com",
    "proof": "txn_abc123"
  }'

# Verify it
curl https://receipt.lifari777.workers.dev/verify/<receipt-id>

# Beautiful shareable card
open https://receipt.lifari777.workers.dev/card/<receipt-id>

Endpoints

Endpoint	Method	What it does
`/issue`	POST	Record a self-attested claim, sign it with Ed25519
`/verify/:id`	GET	Verify the claim was signed and not tampered
`/card/:id`	GET	Beautiful shareable proof card
`/agent/:id`	GET	List all receipts for an agent
`/pubkey`	GET	Get the server's public key

Verdict Schema (v2.4)

The /verify/:id response returns a multi-axis verdict, not a single string:

Axis	What it means	Can it change?
`signature_valid_at_signing_time`	Was the signature valid when issued?	No — immutable
`bytes_present_now`	Are the bytes on this route right now?	Yes — can be deleted
`key_currently_standing`	Does the issuer still control this identity?	Yes — keys can rotate/revoke
`verifier_observation_at`	What did the verifier see at checked_at?	Per-verifier, per-call

Verdict values:

VERIFIED — bytes present, signature valid
NOT_FOUND — never existed
WAS_VERIFIED_NOW_ABSENT — was verified, bytes later deleted
TAMPERED — signature mismatch

Attestation Topology

Level	Who attests	What it proves	Status
Self	The agent itself	"I claim I did X"	Live
Peer	Another agent	"We both agree X happened"	Roadmap
Third-party	An external verifier	"I saw X happen"	Roadmap

We start at self-attested because it's the lowest friction. Every other layer builds on top of this.

Design Principles

No auth — friction is the enemy of adoption. Start open.
No blockchain — blockchain solves consensus, not receipts. Ed25519 is enough.
No accounts — bring your own identity (any string works).
Self-attested first — start with the simplest thing that works, add attestation later.
Portable — receipts travel with the agent, not the platform.

Why not just use logs?

Logs are self-reported. Nothing stops the agent — or a compromised proxy — from rewriting history after the fact.

A receipt is different: it's cryptographically signed, tamper-evident, and portable. Any third party can verify it without trusting the issuer.

Use Cases

Agent marketplaces — prove an agent completed a task
Escrow platforms — audit trail for payment releases
Reputation systems — collect verifiable activity history
Cross-platform identity — carry your track record with you
Compliance/audit — timestamped, verifiable record of what was claimed

Tech Stack

Ed25519 signatures — self-contained, offline-verifiable
Cloudflare Workers — globally distributed, low latency
Cloudflare KV — fast, eventually consistent storage
Canonical JSON — deterministic serialization for signing

Roadmap

v0.1 — basic receipts (no signature)
v0.2 — Ed25519 signing
v1.0 — multi-axis verdict
v2.0 — beautiful shareable cards
v3.0 — multi-sig receipts (peer attestation)
v4.0 — receipt chaining (action A proves you can do action B)
v5.0 — receipt graphs (full agent history)

Contributing

This is a living document. Open an issue if you have questions or ideas.

License

MIT

receipt-protocol