Verify a transaction record

What the record is

When a transaction ends, the publishing organisation can export its transaction record: the listing as published, the parties, the confidentiality instruments and their signatures, the document inventory with its SHA-256 digests, the disclosure log, and the segment of the append-only audit log covering the transaction. It is a single JSON file, and it carries a sealed manifest — a SHA-256 digest over the whole bundle, together with the number of rows in each section.

The verifier

The script below recomputes that seal. It reads one file and uses only Node’s built-in node:crypto and node:fs — no database, no network, no credentials, no install, and nothing from The Big Help. That constraint is the point: a record only its issuer can check is a smaller claim than it sounds.

Download verify-transaction-record.mjs (v2) · Read the one-page instructions · Version manifest

SHA-256 of v2: d1e9de8e689a2690aac41d21c99a6620bb5a10fd48c77637cc11a0250023de2a (9827 bytes). Check your download against it before running it. A published version is frozen — a change to the verifier is published as a new version and the manifest pins every version it has published. v2 verifies records of format tbh.transaction-record/1 and tbh.transaction-record/2, and it also accepts a record that was saved before 4 September 2026 inside the API response wrapper ({ "data": … }); a record exported today is the bare bundle and needs no unwrapping.

Node 18 or later:

node verify-transaction-record.mjs <bundle.json>

What the exit code means

0 — Intact. The bundle still matches the seal it carries.

1 — Altered or broken. The seal does not match, a section count does not match the rows present, or a link is broken where consecutive rows belong to this transaction. The printed lines say which.

2 — Could not run. No file was given, the file could not be read, or it is not valid JSON. Nothing was checked, so this is not a result about the record.

What it checks

The seal: the bundle is re-serialised in a canonical form and hashed, so an edit to any field changes the digest. The counts: a section that has been truncated no longer matches the number of rows the sealed manifest records. The audit linkage: each exported audit row carries the hash and previous hash written by the database when it was recorded, and the script checks each exported audit row for integrity and verifies the chain wherever consecutive rows belong to this transaction. Where the preceding audit row belongs to another transaction, the verifier reports that boundary rather than treating it as an error. The format is order-sensitive, so rows that have been reordered do not verify.

What it does not check

The seal proves intactness, not truthfulness. A verified bundle is the file we sealed, unchanged. It does not establish that any document is authentic, that any party is who they say they are, or that the transaction completed.

It does not prove the record is complete. An event that was never recorded leaves no gap to detect, so a bundle can verify and still be silent about something.

It is not an outside witness. The bundle is sealed by us, so it cannot show that we did not rewrite the history before exporting it. Closing that would take a trusted timestamp over the audit chain from someone other than The Big Help, and we do not have one today.

It does not recompute the audit row digests themselves. That computation lives in the issuing database, and writing a second copy of it here would create two definitions of one serialisation that would eventually disagree. Linkage is what can be checked offline, and linkage is what is checked.

If it does not verify

Keep the file exactly as you received it and email trust@thebighelp.com.au. Do not re-export first — a second export is a different file, and comparing the two is the useful step.

More on how we handle records and disclosure: Principles, Support.