← All guides · Reviewed November 2026
Hash-Chained Ledgers for Agent Actions, Explained
The short answer
A hash-chained ledger seals each entry with a SHA-256 hash computed from the previous entry's hash plus this entry's contents — so editing any earlier entry breaks every later link. In Agentic Receipts the chain is per owner, starts from a literal GENESIS previous-hash at index 0, and carries receipts and lifecycle events in one unified sequence. Chain mechanics as implemented in Agentic Receipts' ledger, November 2026. Check any receipt on the public verify page.
How is an entry's hash computed?
Mechanically, in three steps. First, the receipt's fields are reduced to a canonical set — approver, agent name, version and operator, action description, amount in cents, currency, scope, expiry, identifier hash and mask, creation timestamp — with two optional fields (job type, parent receipt id) included only when set. Second, that set is serialized as JSON with sorted keys and compact separators, so the same content always produces the same string. Third, the entry's hash is SHA-256(previous_hash + "|" + canonical_json). The previous entry's hash is literally inside this entry's seal: that is the chain.
What does the chain look like?
A schematic of the real structure — hashes abbreviated, this is a diagram of the format, not a real customer's ledger:
| chain_index | Entry | prev_hash | hash |
|---|---|---|---|
| 0 | Receipt issued | GENESIS | 9f2c…a1 |
| 1 | Receipt issued | 9f2c…a1 | 41bd…7e |
| 2 | Co-sign event on entry 1's receipt | 41bd…7e | c807…d3 |
| 3 | Receipt issued | c807…d3 | 5e6a…90 |
Receipts and events — co-signatures, use confirmations, expiry notices, revocations — share the one chain, so the ledger is the whole history in order, not a pile of separate records. What a receipt itself carries is covered in What Is an Agent Receipt?
What does tampering look like?
Suppose someone edits the amount on entry 1 after the fact. Recomputing entry 1's hash from its edited fields produces a different value than the one entry 2 recorded as its previous-hash — the chain no longer reconciles, and the break localizes to exactly the edited entry. That is the whole claim, and it is deliberately narrow: the chain proves records were not altered after sealing. It does not prove the original claim was true — a receipt records that an approver approved, and the approval patterns are what make that attribution strong.
How do you verify without trusting the platform?
Two ways. The public verify page checks a single receipt by id. Stronger: export the ledger as JSON — Pro and Team include the full chain entries in the export — and run the free offline verifier kit, which recomputes the chain from the export on your own machine, no server involved. If the recomputation matches, the ledger you hold is the ledger that was sealed.
Frequently asked questions
What is a hash-chained ledger?
A ledger where every entry's seal is computed from the previous entry's seal plus the entry's own contents — in Agentic Receipts, SHA-256 over the previous hash, a separator, and the canonical JSON of the receipt's fields. Change any earlier entry and its hash changes, which breaks every later link that was built on it. Tampering becomes detectable instead of invisible.
What exactly goes into a receipt's hash?
The previous entry's hash and the canonical field set: approver, agent name, version and operator, action description, amount in cents, currency, scope, expiry, identifier hash and mask, and creation timestamp — serialized as JSON with sorted keys and compact separators. Two optional fields (job type and parent receipt id) enter the canonical set only when set, so receipts issued before those features existed keep their original hashes.
What is the GENESIS entry?
The start of a chain. Each owner's ledger is separate: the first entry's previous-hash is the literal string GENESIS and its chain index is 0. Every later entry — receipts and lifecycle events share one unified chain per owner — takes the current head's hash as its previous-hash and the next index.
How can I verify a chain without trusting the server?
Export the ledger (JSON) and run the free offline verifier kit: it recomputes every hash from the exported entries, without a server, and reports whether the chain is intact. A single receipt can also be checked on the public verify page by its receipt id (AGR- plus the issue date and a six-digit sequence number).
Does a hash chain prove an approval really happened?
It proves the record was not altered after it was sealed — not that the underlying claim was true when written. A receipt faithfully records that this approver approved this action at this time; the chain makes later edits evident. That is the honest scope: evidence supporting disputes, not legal protection or legal advice.