Newsroom
Analysis6 min read

Your audit log doesn't need a blockchain. It needs one hash and some discipline.

By Dylan Wolpe

The short version

  • A hash chain — where each entry commits to the hash of the one before it — gives full tamper-evidence for a log with a single writer, and pinpoints the exact entry that was altered.
  • A blockchain solves a strictly harder problem: agreement among parties who do not trust each other. If you control the log, you are paying for consensus you do not need.
  • Neither structure can prove an event was never written down. Detecting omission requires periodically publishing the chain's head hash somewhere you do not control.
  • The question that decides the architecture is not 'how tamper-proof' but 'who is the adversary, and do they control the writer?'

“We need an immutable audit trail” almost always arrives attached to a suggestion that it should be on a blockchain. The requirement is usually right and the suggestion is usually wrong, and the reason why is a useful thing to be able to explain in a meeting.

What you are actually being asked for

Strip the requirement to its evidentiary core and it is three claims you must be able to make about a log, later, to someone sceptical:

  • No entry has been altered since it was written.
  • No entry has been removed, and none has been inserted into the past.
  • Someone other than us can check both of those without trusting us.

Notice what is absent. Nothing here requires distributed consensus, a token, a network of validators, or agreement between mutually hostile parties. Those are the problems a blockchain exists to solve, and they are expensive problems to solve.

The cheap structure that does the job

Give each entry a hash that includes the hash of the entry before it. That is the whole mechanism.

entry_1:  h1 = H( data_1 )
entry_2:  h2 = H( data_2 || h1 )
entry_3:  h3 = H( data_3 || h2 )
                 ...
entry_n:  hn = H( data_n || h(n-1) )     <- the "head"
Each link commits to everything behind it, so the final hash is a commitment to the entire history.

Change one byte of data_2 and h2 changes, which changes h3, and every hash after it. Verification is a single pass that recomputes the chain and compares. It does not merely tell you that something is wrong; it tells you which entry, because that is the point at which recomputation first diverges. Deleting an entry breaks the chain at the deletion. Inserting one breaks it at the insertion.

This is old, well-understood cryptography — it predates blockchains and is in fact the part of a blockchain that provides tamper-evidence. Everything else in a blockchain is there to solve the problem of who gets to append next when nobody is in charge.

The comparison, honestly

Hash-chained logBlockchain
Detects alterationYes, and pinpoints itYes
Independent verificationYes — recompute the chainYes
Needs consensus protocolNoYes
Needs a network / validatorsNoYes
Survives a hostile writerNoYes, by design
Operational costEffectively zeroSubstantial
Queryable as ordinary dataYesUsually not
A blockchain buys you exactly one thing a hash chain cannot: protection when the person writing the log is the person you are worried about.

So when is a blockchain the right answer?

When there is genuinely no party trusted to hold the pen. Several institutions maintaining a shared record none of them controls; a consortium where any member might benefit from rewriting history; a public registry whose credibility depends on no single operator being able to edit it. In those settings the consensus machinery is not overhead, it is the product.

Internal audit logs are almost never that. There is one writer — your system — and the adversary in the threat model is someone who later wants to quietly change what it recorded: an insider covering a mistake, an attacker erasing their traces, a well-meaning engineer “correcting” a record. A hash chain catches all three, because none of them controlled the log at the moment of writing.

The caveat almost nobody mentions

Neither structure can prove that something which happened was written down.

A hash chain proves the internal consistency of the entries that exist. If an event never entered the log — a failed write, a disabled logger, a deliberate omission before the chain was formed — the chain is perfectly valid and perfectly silent about it. This is a genuine limit, it applies equally to blockchains, and it is routinely glossed over by people selling immutability.

The partial answer is anchoring. Periodically publish the current head hash somewhere outside your control — a counterparty, a notary, a timestamping service, an auditor’s file. Once a head is published, everything behind it is frozen: you can no longer rewrite history before that point without contradicting a value someone else already holds. Anchoring does not prove completeness, but it bounds tampering to the window since the last anchor, and turns “trust our log” into “trust our log since Tuesday, and here is a third party’s copy of Tuesday”.

What we built

The AT-1 Ledgeris a hash-chained append-only log that stays compressed and queryable, which matters more than it sounds: an audit log you cannot search without rehydrating is one nobody looks at until the auditor arrives. Verification recomputes the chain and reports the exact entry where it breaks. Anyone can run it — the verifier does not need us, and it keeps working if we cease to exist, which is the only version of “independent” that means anything for a record you must keep for seven years.

No token, no validators, no network. One hash per entry and the discipline to publish the head somewhere you do not own.

Related

More from the newsroom