A tamper-proof audit log does not exist; a tamper-evident one does, and it needs no blockchain. Five primitives: forward-secure MAC keys on the writing host, a Merkle tree per epoch, an RFC 3161 timestamp token over each root, write-once storage with a retention lock, and roots cosigned by a witness you do not control. Consensus solves a different problem.
Ross Jones — Founder, The Hopium Lab. Last modified 21 July 2026.
Twenty-four shipped products, several carrying evidence somebody else has to check without trusting me. Architecture supports a conformity case and never confers one. Not legal advice.
What does a blockchain actually solve?
A blockchain solves Byzantine agreement on ordering among mutually distrustful parties who will not accept any single operator. Consensus is a real problem, solved well. Consensus is not the problem in front of an audit log.
An audit log has one owner and many concurrent writers, so ordering at ingest is a real distributed-systems problem — hence one Merkle tree per epoch rather than a strict global chain. What an audit log never has is a counterparty with an economic incentive to dispute the sequence: nobody profits by arguing entry 4,812 landed before 4,811. The requirement is integrity and non-equivocation.
A blockchain settles who goes next when nobody will accept an operator. An audit log has an operator. The argument was never about order.
Which three questions decide the design?
Three: who are you proving it to, what happens if you are the adversary, and must a third party verify one record without seeing the rest. Answer all three first.
Who is the verifier. Internal operations need detection; a Postgres hash chain delivers it. An auditor needs a proof checkable offline. Opposing counsel needs a presumption. eIDAS Article 41(2) gives a qualified electronic time stamp a presumption of accuracy for the date and time it indicates and for the integrity of the data bound to it; Article 41(1) only stops a non-qualified token being denied admissibility for being electronic, and gives it nothing more. Admissibility is not presumption, and the gap decides which timestamp authority you buy.
Whether you are inside the threat model. Crosby and Wallach modelled an untrusted logger at USENIX Security in 2009 for a reason: whoever appends can also recompute. Rewrite record 5, recompute forward, every check passes.
Whether one record must stand alone. A hash chain makes every proof replay the interval up to the anchor; a Merkle tree cuts it to O(log n). Across 80 million records an inclusion proof is 27 nodes of 32 bytes — 864 bytes — against a chain walk that discloses every entry between target and anchor, and, across enough proofs, the whole journal.
A hash chain held by its own author proves nothing. Whoever can append can recompute. Anchoring outside the perimeter is the only part of the design that survives its own operator.
What are the five primitives, and what does each one prove?
Forward-secure MAC keys, a Merkle tree per epoch, an RFC 3161 timestamp token over each root, write-once storage with a retention lock, and witness cosigning — each covering a failure the others cannot see. Tamper-evident means modification is detectable afterwards, never prevented. An epoch is one batch window; a checkpoint is the signed root, tree size and time for one epoch. A witness is a party that cosigns your checkpoint only after verifying it extends the checkpoint it signed previously.
| Primitive | Proves | Does not prove |
|---|---|---|
| Forward-secure MAC keys (Schneier & Kelsey, USENIX 1998) | Entries written before a host compromise cannot be forged or altered | Anything written after the attacker arrives |
| Merkle tree per epoch (RFC 9162 §2.1.3, §2.1.4) | One record's membership, and that a later tree extends an earlier one | That the operator served the same tree to everybody |
| RFC 3161 token over the root | The root existed before genTime | When the event occurred, or that the record is unchanged — integrity comes from the hash binding, not the token |
| Write-once storage with a retention lock (S3 Object Lock, compliance mode) | That object version survives deletion until expiry, even by the account root | That the name still resolves: new versions and delete markers stay permitted |
| Witness cosigning (C2SP tlog-witness) | Equivocation becomes detectable — two signed checkpoints at the same tree size with different root hashes are proof of misbehaviour | That the journal is complete |
| Public-chain anchor of the root (the fair comparison) | What a timestamp authority proves: a root existed where you cannot reach it | Permanence cuts both ways — no erasure path, no eIDAS presumption |
The sixth row is the comparison, not a sixth primitive.
Sigstore's Rekor v2 integrates witnessing directly; C2SP tlog-witness is the specification. Citation trap: RFC 9162 and the RFC 6962 it obsoletes are both Experimental, and 6962 is still what most deployed logs run.
Forward-secure MAC keys are the primitive most designs omit. Between a write and the next anchor sits an unprotected window; Schneier and Kelsey closed it in 1998 by evolving the MAC key through a one-way function on every entry and erasing the previous key, so entries written before the host falls cannot be altered undetectably. RFC 3161 also obliges the authority not to examine the hash it receives — useful when records are confidential.
Does any regulator still require immutable storage?
Yes, but fewer than storage vendors imply, and the most-cited rule now accepts an audit trail instead. Since 3 January 2023, 17 CFR 240.17a-4(f)(2)(i) gives US broker-dealers two paths: (A) preserve a record "in a manner that maintains a complete time-stamped audit trail", or (B) preserve it "exclusively in a non-rewriteable, non-erasable format". The audit trail is a sufficient answer on its own; WORM remains available as the alternative path, not the mandatory one. Almost nothing written about immutable logging since mentions the addition.
FDA 21 CFR 11.10(e) asks for "secure, computer-generated, time-stamped audit trails" that do not obscure previously recorded information, and names no cryptography. The SEC rule pairs its control with an undertaking at (f)(3)(v), signed by a designated executive officer or third party, to furnish records and their audit trail — a named human on the hook beside the mechanism, the half engineers skip. Write-once retention earns its place regardless of which path the rule allows: retention nobody can shorten is the only control that stops your own operations team at 3am.
Does the EU AI Act require tamper-evident logs?
No. Article 12(1) requires only that high-risk systems "technically allow for the automatic recording of events (logs) over the lifetime of the system"; Articles 19(1) and 26(6) set a floor of at least six months on providers and deployers. Integrity, immutability and tamper-evidence appear nowhere — the mechanism argument is set out separately.
Tamper-evidence is not an obligation. Tamper-evidence is what makes a record survive contact with a market-surveillance authority, an insurer, or opposing counsel.
Where does the design fail in production?
In seven recognisable places, and cryptography is rarely the culprit — the list comes from building and reviewing evidence layers.
- Ingest suppression. An administrator who drops events before they reach the journal defeats every primitive above. Reconcile counts against a different write path.
- The self-witnessed root. Roots published to a bucket in the same account are self-attestation with extra steps.
- Split view. A compromised operator serves auditor A one tree and auditor B another; only cosigners comparing checkpoints catch it.
- The anchor gap. Records sit on the host between write and anchor, protected by a key still in memory. Evolve the key per entry.
- Delete-marker theatre. Compliance mode needs versioning enabled, protects only a version, and permits a delete marker on top. Readers treating a marker as "gone" hide the record.
- Timestamp monoculture. One authority, one certificate, one vendor with a renewal date. Use two, in two jurisdictions.
- Low-entropy commitment. Hashing a record with few possible values is brute-forced in seconds. Salt or key the commitment first.
Tamper-evidence makes an edit detectable. Tamper-evidence never shows that a record was written at all. Suppression at ingest is invisible to hash chains, timestamp tokens, write-once storage and blockchains alike.
What does the decision procedure look like?
Three questions in order, then seven build steps, then four checks that keep the result honest. Copy the procedure, fork it, argue with it.
AUDIT LOG WITHOUT A LEDGER — DECISION PROCEDURE v1.0 (21 July 2026)
The Hopium Lab. Supports a conformity case. Confers none. Not legal advice.
1. WHO IS THE VERIFIER?
Only you ......... hash chain, root copied to a second system
Named auditor .... Merkle tree, inclusion proofs, RFC 3161 token
Court/regulator .. add a QUALIFIED timestamp (eIDAS Art. 41(2))
2. ARE YOU INSIDE THE THREAT MODEL?
No ............... internal anchoring is sufficient
Yes .............. roots leave the perimeter, to >= 2 parties who compare
3. MUST ONE RECORD BE PROVABLE ALONE?
No ............... a chain is fine; verifiers replay everything
Yes .............. Merkle tree, mandatory
BUILD
[ ] Forward-secure MAC key evolved per ENTRY (one-way function), previous
key erased before the next write
[ ] Canonical serialisation; salt or key low-entropy records
[ ] Merkle tree per epoch, domain-separated leaf and node prefixes
[ ] RFC 3161 token over each root, from an authority you do not operate
[ ] Object Lock in COMPLIANCE mode; readers handle delete markers
[ ] Checkpoints cosigned by >= 2 witnesses outside your control
[ ] Consistency proof on a schedule; failure pages a human
DO NOT SHIP WITHOUT
[ ] Record counts reconciled against a different write path
[ ] A verifier a third party runs against an export, offline
[ ] Dated renewal plan (RFC 4998): re-timestamp on schedule, hash-tree
renewal before SHA-256 weakens
[ ] No secrets, no free-text personal data in the record body
Every primitive in the list except witness cosigning predates the Bitcoin white paper — Merkle trees from 1979, forward-secure logging from 1998, RFC 3161 from August 2001. SCITT, published as RFC 9943 in June 2026, issues receipts modelled on Certificate Transparency, not on any chain. The standards community picked its answer years ago. The procurement conversation still has not caught up.