VERIFY · IN BUILD

Settlement log

The rail’s append-only log of sealed settlements. Prove — in your own browser — that a given hash is in the log, and that the log only ever appended. Hashes and proofs only: no amounts, no identity.

Every settlement seals to a hash. Those hashes form an append-only RFC 6962 Merkle log, and the log publishes a tree head — a single root over every hash in it. Two things are then checkable without trusting us:

  • Inclusion — a given hash is in the log at its position, under the published head. Recomputing the root from the audit path proves it.
  • Append-only — a newer head is an extension of an older one, with nothing inserted, reordered or removed. A consistency proof between the two proves it.

The server hands the feed over unchecked; the arithmetic below runs on your machine, with crypto.subtle and the rule from vendor-explorer.mjs — the same bytes you can copy out of this repository and run yourself.

READING THE LOG…

Without this page

Nothing here is privileged. Copy vendor-explorer.mjs out of this repository — one file, no imports, runs in a shell or a browser — and check a proof you fetched yourself:

# a proof for one entry hash, and the head it is issued against
curl -s https://<rail>/v1/explorer/proof/<hash> > proof.json
# then verifyInclusion(hash, seq, head.size, proof, head.root) in node

The verifier is byte-for-byte the one the rail publishes, so it agrees with the log by construction — a drift test fails the build otherwise.

What this does not prove

That a head you are shown is the same head everyone else is shown. A log operator who served two different histories to two readers would pass every check on this page for each of them separately. Closing that gap needs a witness who is not us cosigning the head, and, for those who want it, a periodic anchor of the head onto a public chain. The head is deliberately unsigned until that witness exists — the checkpoint makes the same distinction for the record.