Skip to content

THE CHECKPOINT

Receipts prove that a record hasn't changed. The checkpoint proves something harder: that the log the records live in hasn't quietly changed shape behind you. It is a small signed statement — the log's name, how many entries it holds, and a hash that commits to all of them — published at a public address. Once a checkpoint is out, every entry behind it is pinned: silently rewriting or dropping one would break the math against a statement we already signed and you may already hold.

Read it yourself

The checkpoint is public, free, and needs no account — fetch it any time:

The response lists each log with its origin name, its status, and its latest signed note — a compact, standard format (a C2SP checkpoint) that existing transparency-log tooling can read — plus the publication cadence, printed so you can hold us to it. The note carries its own timestamp; whatever it says when you fetch it is the current truth, and this page deliberately bakes none of it.

What a stranger can do with it

  1. Poll it. Save the note you fetched. The log's size may only grow; a checkpoint that ever shows fewer entries than one you already hold is not an apology we could write our way out of — it is proof.
  2. Demand consistency. /v1/transparency/consistency?log_id=&from=&to= returns an RFC 6962 consistency proof between any two published checkpoint sizes: a short chain of hashes showing the smaller log is a prefix of the larger one. Which sizes exist is one GET, never a guess — /v1/transparency/checkpoints/history?log_id= lists every published size, newest first (the list is an unsigned convenience index and says so in its own bytes; take a proof's numbers from a signed note). If the proof fails, history was rewritten — and the two notes in your hand are the evidence.
  3. Check a receipt against its keys — the receipt-level walk is its own page: how to verify a receipt.

What is admitted

Admission is mechanical, not editorial. A receipt is admitted to the log inside the same transaction that mints it — nobody sits between the mint and the log choosing which receipts the record gets to see, and an entry, once admitted, is admitted forever. Selection is the editorial power in any archive; here the selection rule is everything, at mint, in order, and the checkpoint is how you catch us if that ever stops being true.

What a holder can ask that a stranger cannot

There is no public browse-everyone's-receipts index, by design: receipts can concern private business, and the log proves integrity without exposing contents. But if you hold a receipt, its own inclusion is yours to check at /v1/transparency/inclusion— possession of the receipt's chain_self value is the credential, so only a holder (or their delegate) can open that read. The answer names your leaf, the audit path, the signed checkpoint note, and a binding: included means committed under a signed checkpoint, claiming no external anchor; anchored is the stronger word — it requires an offline-verifiable external time anchor (an OpenTimestamps-confirmed Bitcoin commitment, or a held qualified timestamp) covering that tree size, never an internal marker. The anchor has its own published checker now — verify_anchor.py, one command, no key of ours anywhere in it: it walks the stored timestamp proofs from the checkpoint root and settles the block against a quorum of public chain APIs nobody here operates. An anchored answer carries an anchor block pointing at the anchor's own public record and raw proof bytes, so the claim is followable — and checkable, with a stock OpenTimestamps client — not just stated.

A holder who paid can ask one more thing: /v1/transparency/payments counts how many entries in the log are bound to their settlement transaction — the number a payer wants to be 1. It opens only to the transaction hash and a receipt-derived key together (a transaction hash is public, so alone it opens nothing), and it answers with a count and a membership assertion, never a list of receipts. The count is scoped to receipts admitted to the log, and the response publishes on its own face how many receipts predate admission and can never be counted.

What it deliberately does not do

A checkpoint is not a verdict: it proves the record's shape is honest, never that any claim inside a receipt is true.

The deeper mechanics — the note format, the proof math, walking the log with your own tooling — live in the docs: walk the log. The archive's broader story — what is kept and for how long — is at the archive.

← BlueFox