Why a public log
A [verifiable timeline](/docs/verifiable-timeline) proves a single shipment's history was not rewritten after sealing. But there is a sharper question an auditor asks: could TrackJet quietly re-seal a different history and pretend it was always so? The transparency log answers it — and the answer does not require trusting us.
How it works
Every sealed chain head is folded into an append-only Merkle tree, and the tree's root is published periodically (spec: tjmt1). Two properties follow from the maths, not from our good behaviour:
- append-only — a published root commits to every head before it; you cannot remove or alter a past entry without changing the root;
- inclusion proofs — for any sealed shipment, a short proof shows that exact head is committed under a published root.
If anyone — including TrackJet — silently rewrote a past timeline, the old inclusion proof would stop matching the published root, and whoever holds that proof can demonstrate the rewrite.
The live endpoints
The root history is public and machine-readable:
`` GET /api/v1/transparency/root # the latest published Merkle root GET /api/v1/transparency/roots # the append-only root history ``
These are open on purpose: a transparency log you cannot read is theatre.
What it proves — and what it does not
It proves non-equivocation: we cannot show one history to you and a different one to someone else, nor rewrite the past, without it being detectable against the published roots.
It does not vouch for the carrier's original data, and it only covers histories that were actually sealed — a redirect-only number that never built a chain has nothing in the log.
Verify it yourself
Inclusion and chain proofs check offline with the open-source tjverify CLI — see [transparency for auditors](/docs/transparency-for-auditors) for the step-by-step, and [the Verifiable Timeline](/docs/verifiable-timeline) for how a single shipment is sealed in the first place.