How the audit chain works.

The Due Diligence Record is the artefact a broker actually uses. The audit chain is what makes the record provable.

What we store

Every search creates one chain entry. The entry is a small struct:

{
  "id": "ac_2026-05-15-0042",
  "timestamp": "2026-05-15T03:42:11Z",
  "search_type": "ppsr_search_organisation",
  "target_hash": "sha256:7b3...",
  "certificate_hash": "sha256:9f4e2c...",
  "record_hash": "sha256:a1b2c3...",
  "user_id": "usr_…",
  "prev_entry_hash": "sha256:0e5d…"
}

Notice what's not in there: no ACN, no counterparty name, no result body. The chain stores hashes and minimal metadata. The body of the record lives elsewhere (in our R2 bucket, encrypted, accessible only to the account that generated it).

How "tamper-evident" actually works

The trick is in prev_entry_hash. Each entry's own hash includes its prev_entry_hash, which includes its predecessor's, all the way back. Changing any historic entry would change every subsequent entry's hash.

That property alone isn't enough — an attacker could regenerate the whole chain after a forged edit. So we checkpoint. Every 24 hours, we publish the current chain-head hash to a public R2 bucket at chain.assets.hoistai.com/checkpoints. Once a checkpoint is published, anything before it is fixed in place by the public record; you can't rewrite history without rewriting our public bucket too, which would itself be visible.

Verifying a record yourself

The PDF contains a SHA-256 hash of its own content (computed pre-rendering and embedded in the metadata footer). Pass that hash to GET /v1/records/{id}/verify:

curl https://api.assets.hoistai.com/v1/records/rec_01HX5F9AB2/verify \
  -H "Authorization: Bearer $HOIST_KEY" \
  -G --data-urlencode "hash=sha256:a1b2c3..."

Response:

{
  "match": true,
  "audit_chain_id": "ac_2026-05-15-0042",
  "checkpoint_id": "cp_2026-05-15-09:00Z",
  "checkpoint_public_url": "https://chain.assets.hoistai.com/checkpoints/cp_2026-05-15-09:00Z.json"
}

If a single byte of the PDF was altered, the hash you computed won't match the hash we have on file. The chain knows. The checkpoint confirms our chain knowledge is from before the alteration.

Why hashes and not signatures

A more cryptographic version of this would sign records with a Hoist private key, and let anyone verify against our public key. We considered it. We didn't ship it for v1 for two reasons:

1. Key rotation is risky in v0.1. If we rotate the signing key and historic signatures break, we've created a much worse problem.
2. Hashes are good enough. The threat model is "broker alters a deal-file PDF after the fact." A hash mismatch is sufficient evidence; the courtroom doesn't need elliptic curves.

We'll add detached signatures when customers ask for them or when our v2 schema lands — whichever comes first.

What we don't claim

• We don't claim the record is admissible evidence by itself. That's the AFSA certificate's job; the record is contemporaneity proof.
• We don't claim the chain is decentralised. It runs on our infrastructure; the public checkpoints are the only out-of-band verification surface. If you want a fully-decentralised audit chain, talk to a blockchain vendor; we'd politely decline.
• We don't claim verification means the data is correct. It means the data hasn't been altered since we recorded it. Different thing.

The open-source bit

The hashing logic, the chain implementation, and the checkpoint publisher are open-sourced at github.com/HoistAiorg/hermes under MIT. Quokkafi uses the same code. If you're building an audit chain for a similar product, copy it.

---

By the Hoist team. 2026-05-15. Changelog · Next post →