Checkpoint

This is a root over the record — what shipped, dated and attributed, sealed entry by entry. It is not the daily root over the ledger snapshot described on anchoring. Two different trees over two different things, and conflating them would make both less useful.

The current head

Origin

repo/flashy-network

Leaves

39 sealed claims

Root

ce915b551b1ce33383070f91a0f9678b82218bfea3bce024524e70130482fb85

Computed

2026-08-30

Served at /.well-known/checkpoint.json, beside the shipped/1 fragment it commits to. It is refreshed in the same job that refreshes the log, so the two never disagree — a separate job would leave a window where the published root and the published record contradict each other, and a reader hitting that window sees a forged-looking estate.

What this proves

Take the fragment, rebuild the tree, compare the root. If they match, the record you are reading is the record that was published. That catches an entry edited after the fact, an emitter that silently dropped rows, a served copy that has drifted from its source, and two parties who believe they hold the same record and do not.

What it does not prove

It does not prove the history was never rewritten. We compute the root, we publish the root, and we hold the data — so nothing in a single head stops us recomputing and republishing after changing whatever we liked. The tree gives internal consistency. It does not give append-only, and a root presented as if it did would be worse than no root at all.

Two things would close that, and neither is built:

• Consistency proofs between successive heads, so that each new root provably contains everything the previous one did. The arithmetic ships in the package; retaining every head over time and serving proofs between them is a log, with uptime, and that is the expensive half.
• A witness who is not us. A head cosigned into a public append-only medium we do not control. Until then, “we did not rewrite it” rests on our word, and a Merkle root does not change whose word it is.

The head is therefore unsigned, deliberately. A signature over a root we computed, checked against a key we published, would add ceremony and no property.

The estate root

Each property publishes its own root. Above them sits a tree whose leaves are those roots — so the hub holds one hash per property and no data at all. A property proves its own record with the hub absent entirely; the hub proves membership without holding a single claim; and one claim verifies to the estate root through two short proofs chained together.

That shape is deliberate. One tree that collected every claim in the estate would reintroduce exactly the central authority the federated record exists to remove: if the hub were down or wrong, nobody could prove anything.

Check it yourself

npx @flashyos/checkpoint check
# or, with no toolchain at all:
node vendor-checkpoint.mjs verify

The tree is RFC 6962 verbatim rather than a house variant — Certificate Transparency has had a decade of adversarial review on this exact structure, and a variant would lose all of it for nothing.