Ledger verifier
Recompute the chain in your browser.
Every step of an execution is recorded in a SHA-256 hash-chained ledger. Paste an export below and recompute the chain in your own browser, with no server round-trip.
Verify
Paste an export, or watch the sample verify.
The check runs in this browser via Web Crypto (“crypto.subtle”) and makes no server round-trip.
The chain
How the chain works, and where it stops.
The algorithm on this page replicates lib/execution/ledger.ts exactly: entry_hash = SHA-256(prev_hash + "." + canonicalJson(step)). Ledger rows live in nervos_execution_steps, under row-level security, one chain per proposal.
Identifiers such as HIST-01 refer to the claims register, described on the trust page.
- 01
Why hash-chaining
Each step’s entry hash is SHA-256 over the previous step’s hash plus a canonical (key-sorted) JSON serialization of the step’s contents — sequence, status, provider, action type, idempotency key, request hash, external id, detail, and timestamp. A change to one step is detected at that step: an edited or reordered row, or a deleted row with steps after it, breaks the chain where it was changed. The chain has no external anchor. Deleting the last steps leaves a shorter chain that still verifies, and so does rewriting a step and every step after it. Members cannot update or delete a step: row-level security has no policy that allows it. The database owner can, and until a pending migration is applied (HIST-01) so can anyone holding the service key.
- 02
What a green verdict shows
With an export in hand, an auditor recomputes every hash offline. This page does exactly that, in your browser, with Web Crypto. A green verdict means every step matches its stored hash and links to the step before it: change one step’s amount, transaction id, timestamp or position and the chain breaks there. It does not rule out the removal of the last steps, or a rewrite of a step and every step after it. To catch either, keep the step count and the last hash of an earlier export. A later export must have at least that many steps, and the same hash at that step.
- 03
How Nervos writes the chain
Every stage of an execution — preflight, execute, persist, plus rollback and replay — is appended to the ledger at execution time via a service-role write, stamped with the tenant’s org id and chained to the previous step (the first step chains to a genesis hash of 64 zeros). If the preflight step cannot be written, nothing is sent. If the step recording a sent write cannot be written, the result is flagged ledgerMissing and that write is missing from the chain. A member whose role holds audit:read can export a proposal’s chain via GET /api/actions/proposals/{id}/ledger, which also re-verifies it server-side on every read.
Talk to us
Bring a decision you have to get right.
A forty-five minute call with the engineer and the operator. You bring the decision.