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 nodeThe 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.