Receipts Everywhere: Trust Without Central Trust
When someone says they did the thing, you need more than their word.
Someone says they did the thing. You cannot verify.
This is the fundamental coordination problem. Not latency. Not throughput. Not consensus algorithms. The problem is: how do you know what actually happened when you weren’t watching?
In No Control Plane: The Playbook, I argued that autonomous systems need to operate without central coordination. But autonomy without evidence is just hope. If your nodes can act independently, you need proof of what they did, when they did it, and whether it worked.
That proof is a receipt.
What a Receipt Actually Is
A receipt is not a log. Logs are internal memory. Receipts are external commitments.
The difference matters. A log says “I did X.” A receipt says “I did X, and here is evidence you can independently verify.” The first is a note to yourself. The second is a promise you can be held to.
In accounting terms: a log is your personal ledger. A receipt is the bank statement that proves the money moved.
Property Log Receipt Audience Self External verifier Trustworthiness “Trust me” “Verify this” Tampering Editable Detectable Purpose Debugging Accountability
A good receipt has three properties:
Timestamped: When did this happen?
Signed: Who claims responsibility?
Hashable: Can I detect if it changed?
That's it. Timestamp, signature, hash.
What about blockchain? Blockchain solves a different problem: getting parties who actively distrust each other to agree on a shared history. No arbiter, no central authority, just cryptographic consensus. If you need five competing organizations to verify the same chain without any of them controlling it, blockchain earns its complexity. Most internal systems have a simpler trust model. You control the nodes. You control the verifier. A hash chain is enough.
The Simplest Viable Scheme
Here is the minimum viable receipt for a distributed action:
{
"action": "patched_vulnerability_CVE-2024-1234",
"node_id": "node-0742",
"timestamp": "2026-02-19T14:32:07Z",
"outcome": "success",
"signature": "sha256:9f86d08...",
"prior_hash": "sha256:7c211..."
}
The prior_hash is the critical piece. It links this receipt to the previous one, creating a chain. If anyone modifies an earlier receipt, all subsequent hashes break. This is tamper-evidence without a central authority.
You can verify the chain yourself. You don’t need to trust the node. You don’t need to trust a coordinator. You just need the receipts.
Implementation notes:
Store receipts locally on each node (they’re small)
Replicate to at least one other location (durability)
Signature can be HMAC if you control both ends; asymmetric if you don’t
Timestamp source matters: use NTP or a trusted time service, not local clock
The scheme is intentionally boring. Boring is good. Boring means you can explain it to an auditor in five minutes.
What Receipts Don’t Solve
Receipts prove that something was claimed. They don’t prove it actually happened.
A node can lie. It can generate a receipt saying “I patched the vulnerability” without patching anything. The receipt is authentic: properly signed, properly hashed, properly chained. But the underlying claim is false.
This is important to understand: receipts are about accountability, not truth.
If a node lies, the receipt becomes evidence of the lie. During an incident review, you can show: “Node 0742 claimed it patched at 14:32. Here’s proof the vulnerability was exploited at 14:45 from that exact node.” The receipt doesn’t prevent the lie. It makes the lie discoverable.
Other things receipts don’t solve:
Clock drift: Timestamps are only as good as your time source
Key compromise: If someone steals the signing key, they can forge receipts
Selective omission: A node can simply not generate a receipt for an action
Semantic ambiguity: “Success” might mean different things to different systems
Each of these has mitigations, but the mitigations add complexity. For most internal automation, start with the simple scheme. Add complexity when a specific failure mode bites you.
The exception: high-stakes domains where the cost of a single failure is catastrophic, or where compliance mandates specific controls. There, build the mitigations in from the start.
When Receipts Change the Game
Receipts matter most when:
Actions are autonomous: No human in the loop to verify
Consequences are significant: Security patches, financial transactions, access changes
Accountability spans organizations: You need to prove something to someone who doesn’t trust your logs
Incident review is inevitable: You will need to reconstruct what happened
If you’re building automation that touches security, compliance, or money, you need receipts. Not because the auditors require it (though they might). Because when something goes wrong, you need to know what actually happened.
The alternative is the incident review where everyone points at everyone else and nobody can prove anything. I’ve been in those rooms. They’re exhausting. Someone says the patch was applied. Someone else says it wasn’t. The logs are ambiguous or missing. Three hours later, you still don’t know what happened, and you’ve burned trust that takes months to rebuild.
Receipts don’t prevent failures. They make failures legible.
Adoption Steps
If you’re convinced receipts matter, here’s how to start:
Week 1: Identify one high-stakes action Pick the single most important automated action in your system. The one where, if it fails silently, you’re in trouble. That’s your first receipt candidate.
Week 2: Define the receipt schema What fields do you need? At minimum: action, actor, timestamp, outcome, signature. Add domain-specific fields as needed. Keep it flat. Nested structures complicate verification.
Week 3: Implement local storage Store receipts on the node that generates them. Append-only file is fine. SQLite is fine. Don’t overthink storage until you have volume problems.
Week 4: Add the hash chain Each receipt includes the hash of the previous receipt. This is the tamper-evidence layer. Test it: modify an old receipt and verify the chain breaks.
Week 5: Add replication Receipts stored in one place can be lost or tampered with by someone with node access. Replicate to a second location. Cloud object storage works. A different node works. A syslog server works.
Week 6: Build the verifier Write a script that walks the chain and validates every signature and hash. Run it in CI. Run it before incident reviews. Make it easy.
After six weeks, you have a working receipt system. It won’t be perfect. It will be better than “trust me.”
The Smallest Bet
When I design systems, I ask: what’s the smallest proof artifact I would bet my job on?
Not “what would impress the security team.” Not “what would look good in a compliance audit.” What’s the smallest thing I can point to and say: “This happened. I can prove it. You can verify it yourself.”
That’s a receipt.
Pick the smallest receipt you can generate that you would bet your job on.
Further Reading
Merkle Trees (Wikipedia) The data structure behind hash chains. Worth understanding the fundamentals before implementing.
RFC 3161: Time-Stamp Protocol (IETF) The standard for trusted timestamping. Overkill for most use cases, but good to know it exists.
Certificate Transparency (Google) A real-world implementation of tamper-evident logs at scale. How the internet verifies TLS certificates.
Designing Data-Intensive Applications by Martin Kleppmann Chapter 11 on stream processing covers event sourcing and append-only logs. The best technical treatment of these ideas.
Previously: No Control Plane: The Playbook: how autonomous systems operate without central coordination.
Next: Recovery-First Automation: because receipts help you audit, but undo helps you survive.