Transparency Checkpoint · transparency.checkpoint
You keep the log. Hive rebuilds the tree, hands the root to a public timestamp authority that has nothing to do with us, checks the authority's signature, and signs a checkpoint. Anyone can then prove one receipt is in the log, and that the log only ever grew.
Live in production
Hive keeps a transparency log for the decisions software makes. Every decision is recorded as a typed event, signed when it happens, and chained into the log. Anyone can verify that an event existed, in order, at that time, without asking the system that made it.
Say you issue signed receipts. Good. Every one of them verifies on its own, forever. Now someone asks a harder question: is this the whole set? Two years from now, when the other side's expert is looking at your evidence, how do they know a receipt was not deleted, or swapped, or backdated into the pile after the fact?
Signatures do not answer that. A signature proves a single record is intact. It says nothing about the shape of the collection around it. If you control the store, you control what is in it, and everyone in the room knows that.
This is the part that matters to the three teams who actually block a deal. Legal wants evidence that holds up if you get sued. Compliance wants something that passes an audit without taking your word for it. Risk wants to know it will not blow up later. All three are asking the same question, and it is a question about the log, not the record.
One digest per receipt. Not the receipt. We build the RFC 6962 Merkle tree over those digests and recompute the root ourselves. If you try to hand us a root, we refuse the request.
The root goes to a public RFC 3161 timestamp authority. They sign the root and hand back a token. We check it: status granted, the imprint equals the root we computed, the signed attributes match, the signature verifies, and the certificate the token carries was valid at the time it claims. We do not chain that certificate to a trust anchor, so you pin the authorities you accept and read the signer subject, issuer, and serial we record. And we refuse any authority running on our own hosts.
Root, tree size, the authority's identity, and the gap between when you declared the checkpoint and when the authority stamped it. Next checkpoint carries a consistency proof from the last one, so the history is pinned end to end.
Two things fall out of that, and they are the whole point. Anyone can ask for an inclusion proof and confirm one receipt root sits in the tree without seeing a single other leaf. Anyone can ask for a consistency proof between two checkpoints and confirm the older tree is still an exact prefix of the newer one. Delete a leaf, swap one, or fork the history, and the check refuses. Move the anchor to a different root and the imprint check refuses.
Run it
This button calls the live production API. Nothing here is precomputed and nothing is mocked. The timestamp tokens come from public authorities, and you can verify every one of them yourself against the endpoints listed below.
Forty one gates on a full checkpoint, in order, and the verifier stops at the first one that fails and tells you which. Two more routes check a single proof with no receipt involved at all.
| Gate | Check |
|---|---|
| SCHEMA | receipt conforms to transparency-checkpoint-v1.json |
| ISSUER_KEY_MATCH | the issuer key resolves to a trusted eligible key |
| PAYLOAD_DIGEST_VALID | payload_sha256 recomputes from signed_body |
| SIGNATURE_VALID | the Ed25519 signature verifies |
| CHECKPOINT_INSTANT_ORDERED | the declared instant is at or before the witness instant |
| CHECKPOINT_SKEW_RECOMPUTE | the recorded skew recomputes from the two instants |
| CHECKPOINT_SKEW_BOUND_SATISFIED | the observed skew sits inside the declared bound |
| LOG_ID_BINDING | the log identifier recomputes from the origin string |
| MERKLE_PARAMETERS_FIXED | RFC 6962 SHA-256 with the fixed leaf and node prefixes |
| TREE_SIZE_SANE | the tree size is a positive integer at or under the ceiling |
| LEAF_SET_FORM | every supplied leaf is a distinct 64 character lowercase digest |
| LEAF_COUNT_AGREEMENT | the supplied leaf count equals the signed tree size |
| LEAF_DISTINCTNESS | no leaf appears twice in the supplied set |
| ROOT_RECOMPUTE_FROM_LEAVES | the signed root recomputes from the supplied leaves |
| SPOT_CHECK_INDEX_IN_TREE | the spot check index sits inside the tree |
| SPOT_CHECK_LEAF_MATCHES_SET | the spot check leaf equals the supplied leaf at that index |
| INCLUSION_PATH_FORM | the inclusion path is a digest list of the expected depth |
| INCLUSION_PATH_RECOMPUTE | folding the path from the leaf reproduces the signed root |
| INCLUSION_TAMPER_REFUSED | a single bit flipped in the leaf no longer reaches the root |
| APPEND_ONLY_CLASS_DECLARED | the append only class is one of the closed classes |
| PREVIOUS_SIZE_NOT_GREATER | the previous tree size is not larger than the current one |
| PREFIX_MATCHES_PREVIOUS_ROOT | the previous root is still the root of the current prefix |
| CONSISTENCY_PROOF_FORM | the consistency proof is a well formed digest list |
| CONSISTENCY_PROOF_RECOMPUTE | the proof carries the old root forward to the new one |
| ROOT_ADVANCED_WHEN_SIZE_GREW | the root changed whenever the tree size grew |
| ANCHOR_CLASS_DECLARED | the time anchor class is one of the closed classes |
| ANCHOR_TOKEN_BINDING | the anchor digest matches the supplied token bytes |
| ANCHOR_STATUS_GRANTED | the authority returned RFC 3161 PKIStatus granted |
| ANCHOR_CONTENT_TYPE_CORRECT | the token is an id-ct-TSTInfo signed data structure |
| ANCHOR_IMPRINT_EQUALS_ROOT | the imprint the authority stamped is the signed log root |
| ANCHOR_MESSAGE_DIGEST_ATTRIBUTE | the signed attribute digest matches the content |
| ANCHOR_SIGNATURE_VERIFIED | the authority signature verifies over the signed attributes |
| ANCHOR_IDENTITY_BINDING | the signer identity recorded here matches the certificate |
| ANCHOR_GEN_TIME_PARSED | the authority generation time parses as a real instant |
| ANCHOR_SIGNER_VALID_AT_GEN_TIME | the certificate was inside its validity window then |
| ANCHOR_LAG_RECOMPUTE | the recorded anchor lag recomputes from the two instants |
| ANCHOR_LAG_BOUND_SATISFIED | the anchor lag sits inside the ceiling |
| ANCHOR_AUTHORITY_INDEPENDENT | the authority host is not one of ours |
| NO_RECEIPT_BODY_LEAK | no public field carries a receipt body, payload, or text |
| POSSESSION_CLASS_DECLARED | the receipt declares that Hive does not hold the log |
| BOUNDARY_PRESENT | the fixed schema boundary text matches |
| Gate | Check |
|---|---|
| LEAF_FORM | the leaf is a 64 character lowercase digest |
| ROOT_FORM | the claimed root is a 64 character lowercase digest |
| TREE_SIZE_SANE | the tree size is a positive integer at or under the ceiling |
| LEAF_INDEX_IN_TREE | the leaf index sits inside the claimed tree size |
| INCLUSION_PATH_FORM | the path is a well formed digest list |
| INCLUSION_PATH_RECOMPUTE | folding the path from the leaf reproduces the claimed root |
| Gate | Check |
|---|---|
| OLD_ROOT_FORM | the old root is a 64 character lowercase digest |
| NEW_ROOT_FORM | the new root is a 64 character lowercase digest |
| OLD_TREE_SIZE_SANE | the old tree size is positive and at or under the ceiling |
| NEW_TREE_SIZE_SANE | the new tree size is positive and at or under the ceiling |
| SIZE_DID_NOT_SHRINK | the new tree size is not smaller than the old one |
| CONSISTENCY_PROOF_FORM | the proof is a well formed digest list |
| CONSISTENCY_PROOF_RECOMPUTE | the proof carries the old root forward to the new one |
This is worth being blunt about, because it is the objection every security team raises in the first ten minutes. We cannot hand over your log in discovery, because we do not have it. The contract is stateless and recomputing. You supply the leaf digests and the proofs, we recompute everything and anchor it, and nothing is stored on our side.
No receipt body, payload, or text may cross the boundary either. The schema will not let one
through, and NO_RECEIPT_BODY_LEAK refuses the receipt if one appears in a public
field. What we see is a list of digests, and a digest is not the thing.
That also means an inclusion proof discloses nothing beyond the leaf being proven and the sibling hashes on its path. The rest of the tree stays closed. Someone can confirm your receipt is in the log without learning how many other receipts you issued that day, or what they were.
| Route | What it does |
|---|---|
GET /v1/demo/transparency-checkpoint | Ten worked examples minted against live timestamp authorities: two that verify, four refusals, and both standalone proof cases. |
POST /v1/verify/transparency-checkpoint | Full checkpoint verify. Open, no key, no account. |
POST /v1/verify/transparency-checkpoint/inclusion | Check one inclusion proof. No receipt involved. |
POST /v1/verify/transparency-checkpoint/consistency | Check one consistency proof between two roots. |
POST /v1/mint/transparency-checkpoint | Mint a checkpoint. Token gated, fails closed. |
POST /v1/mint/transparency-checkpoint/open | Mint with the published example key, so a browser page can run without a token. Every receipt it issues is labelled a demonstration issuance. |
This receipt fixes the shape of a log at one instant, not the meaning of what is in it. The witness holds no log and received no receipt bodies. What it received was an ordered list of digests, and it recomputed from them: the root, one full audit path for a named leaf, and, when a predecessor root was declared, both the prefix root and the RFC 6962 consistency proof between the two sizes. So this receipt states that the declared root really is the root of exactly those digests in exactly that order, that the named leaf really sits at the named index under it, and that the earlier root really is a prefix of this one. It also states that a public timestamp authority signed this root, with the imprint inside the token equal to the root and the token signature checked against the certificate the token carries. It does not chain that certificate to any trust anchor, so a relying party pins the authorities it accepts and reads the signer subject, issuer, and serial reported here to do it. It does not claim the leaves are Hive receipts, that the log is complete, that no second log exists, or that anything outside the supplied list ever happened. Nothing here is a claim about the content behind a digest.
Transparency Checkpoint is one instrument in the Hive canon. It is the one that makes every other receipt harder to argue with, because it removes the "you could have edited the pile" objection from the table.
Patent pending. Hive Civilization, The Hivery, Inc.