Ledger transparency

Epoch history, preserved honestly.

Signatrust does not rewrite its ledger. Historical continuity anomalies are documented and archived under an earlier epoch. A signed recovery manifest anchors each new epoch, so per-property integrity can be reasoned about without conflating them into a single word.

Five properties, not one

Ledger "integrity" is not a single yes/no. Verifying a receipt exercises five distinct properties. Any one can pass while another does not — and we surface them separately so they cannot be confused.

Receipt integrity

The receipt's signed body has not been altered since signing. Verified by SHA-256 over the canonical body plus Ed25519 signature.

Local predecessor linkage

The receipt's previous_hash field correctly references the hash of the receipt immediately before it. A single-step check, independent of the full chain.

Epoch continuity

Within a single epoch, every receipt's predecessor linkage holds unbroken from the epoch's signed genesis onwards.

Historical ledger continuity

Whether the entire historical file forms an unbroken chain across all epochs. This is the property that can be compromised and preserved as-is.

Filesystem append integrity

Whether the on-disk ledger was appended-only. Enforced at write time; violations refused at ingestion.

Live epoch status

Fetched directly from /api/v1/verify/ledger. This is the same information used by the offline verifier's --strict-chain mode.

Loading live epoch data…

What the history contains

Individual receipts on either side of a historical break are still cryptographically valid — their signatures verify and their signed bodies match. The break is in the chain-continuity property alone.

Why the historical anomalies were preserved rather than rewritten

Rewriting a ledger to erase historical breaks would be strictly worse than preserving them: it would destroy the audit trail while giving a false impression of continuity. Signatrust instead:

  1. Preserved the historical file as Epoch 0, including the known continuity anomalies.
  2. Enforced write-time validation so no new receipt can be introduced whose previous_hash does not match its predecessor. Any such attempt is refused at ingestion.
  3. Rolled the ledger forward into Epoch 1 by anchoring a signed recovery manifest that links back to the last-known-good state.

This preserves scientific honesty: individual receipts remain independently verifiable, and the chain-continuity property is truthfully labelled per epoch.

How epoch anchoring is verified cryptographically

An epoch is only ACTIVE when:

  1. The signed recovery manifest verifies against a trust-anchor public key present in the trust bundle.
  2. The first receipt in the new epoch (the anchor receipt) carries an epoch_genesis field whose recovery_manifest_hash matches the SHA-256 of the trusted manifest body.
  3. The anchor receipt's own body hash and signature verify normally.
  4. Every receipt after the anchor links validly to its predecessor.

Until the anchor receipt is produced, the epoch is labelled DECLARED_PENDING_ANCHOR rather than ACTIVE. The label is honest about the state.

What is not claimed

Epoch continuity says nothing about the correctness of the decisions inside the receipts. A receipt whose signed body has not been altered can still describe a decision that was, in the real world, wrong. Signatrust records evidence; it does not judge outcomes.