Why we hash-chain the audit log instead of using a blockchain.
When the audit-trail subject comes up in a buyer call, somebody — engineer, product manager, occasionally a board member — asks "so is it on a blockchain?" The honest answer is no, and the reasons are interesting enough to write down. Both designs produce a tamper-evident log. Only one of them survives a procurement conversation with a Canadian bank.
What both designs share
Strip the marketing off, and a blockchain audit log and a hash-chained audit log are the same primitive: each new record contains a cryptographic hash of the previous record. Tampering with any old record changes its hash, which invalidates every subsequent record's hash. An external party can verify the chain in linear time without trusting the operator's word.
This is not a blockchain invention — it is much older. Hash chains are how Git models commit history. They are how rsync's content-addressed storage works. They are the substrate of certificate transparency logs. Bitcoin's contribution was the consensus mechanism on top, not the chained hashes underneath.
If your goal is "an external auditor can verify that no row was deleted, edited, or reordered," a hash chain delivers it. The blockchain part adds something else.
What blockchain adds — and what that costs
The blockchain part adds distributed consensus. Multiple parties — typically not trusting each other — agree on the order and content of new records, without relying on any single operator. This is genuinely useful when the threat model includes "the operator may collude with an attacker to retroactively rewrite history."
For an enterprise audit log, that threat model is wrong on two counts.
First, the operator is the regulated party. The operator is the bank, or the bank's vendor under contract. The bank's auditor isn't worried that the bank will collude with itself to delete records — that would itself be the violation, and it is detectable. They are worried about a malicious insider, an external intruder, or a misconfigured system. None of those threats are addressed by adding miners.
Second, the cost of distributed consensus is real and gets paid every transaction. A public chain (Ethereum, Bitcoin, even Polygon) charges per record and has commit latencies measured in seconds to minutes. A private chain trades latency for the loss of decentralization — and once you trust a small set of operators to validate writes, you have built a hash chain with extra steps.
An enterprise audit system needs to write thousands of decisions per second under load, with sub-millisecond local-write commits. Even with optimizations, no widely-deployed blockchain meets that bar. The ones that come close are essentially hash chains pretending otherwise.
The procurement question that decides it
The single sentence that ends most "should we use a blockchain" debates is asked by the prospect's procurement officer:
"Walk us through how our internal audit team would verify the integrity of this log, in our office, without an internet connection or a third-party service."
For a hash-chained log, the answer is: you export the log, you run a verifier (provided), it walks the chain in O(n) and reports the first row whose hash doesn't match. The verifier is a few dozen lines of code that we publish; their team can rewrite it in their language of choice in an afternoon. Nothing leaves their network.
For a blockchain-backed log, the answer involves a wallet, an RPC node, gas considerations, and the assumption that some external chain will exist five years from now. The procurement officer is not in the mood for any of that.
This is not a hypothetical. We have had it happen. The blockchain answer turns the meeting into a 30-minute education on Merkle proofs and validator economics. The hash-chain answer takes 30 seconds and moves on to the next question.
What hash-chaining actually requires
The design has fewer surprises than people expect. We are not going to enumerate every detail — implementation specifics are part of what differentiates a product that has thought about this from one that hasn't. But the conceptual ingredients are public.
Append-only storage. Audit rows are written once and never updated. The storage layer enforces this through application invariants and database constraints. Any mutation path is itself audited.
Per-row hashing. Each row contains a hash that covers the row's own canonical content plus the previous row's hash. The canonical-content step is the subtle part — you must canonicalize so that "the same logical row" produces the same hash regardless of how it was serialized.
Tenant scoping. Each tenant has their own chain. Cross-tenant interleaving is a category error; their audit history is theirs.
A single verification endpoint. One API call that walks the chain and returns "valid" or "broken at row X." External auditors can call it. Internal auditors can call it. The frontend shows it as a green badge.
Periodic anchoring (optional). If the operator wants to defend against retroactive collusion with the storage layer — paranoid but legitimate for some buyers — the head hash can be periodically signed by an external service or published to a public log. This is the only place a public chain can productively appear, and even there a transparency log (like CT) is a better fit than a smart-contract chain.
What about cryptographic timestamps
A reasonable adjacent question: should the audit log be timestamped by an external authority? RFC 3161 timestamps from a TSA, or anchored into a public ledger, give an extra property: not just "this row's hash hasn't changed since it was written," but "this row existed before this date." For most enterprise audit scenarios, this is overkill — the operator's own NTP-synced clock and immutable storage are accepted as sufficient. For a small set of regulated industries (notably some pharmaceutical and clinical-research contexts), external timestamping is a contractual requirement.
If a buyer needs that, you bolt it on as a periodic anchoring step. The internal chain doesn't change.
The deeper point
There is a pattern in infrastructure choices: pick the older, more boring design unless the threat model specifically requires the new one. Hash chains are 1979. Merkle trees are 1979. Git's chained-commit model is 2005. SQL databases are older still. The marginal value of using a newer, more interesting design is almost always negative on the procurement side, because the buyer is paying you to take risk off their plate, not to add it.
Blockchains are a real engineering achievement and they solve real problems. The audit log of an authorization decision in a regulated enterprise is not one of them.