Knowledge Base

Overview

A witness is a public record that already existed at the moment you submitted, and that your submission’s composite fingerprint commits to. Each witness is named and stored as a hash inside the item’s system-generated metadata, so hashing that metadata folds every witness into the metadata hash and from there into the item hash: which witnesses an item names is fixed at submission and can never be chosen or revised afterwards. Witnesses are what open the submitted-after edge of the submission window, because a record that already existed cannot have been produced later. Their mirror image is a commitment, a public-blockchain transaction recorded after submission that closes the submitted-before edge. A proof bundle may carry the full detail of each witness so that a verifier can rehash it and confirm the match without contacting Truestamp.

The witness registry

Witness names are a long-lived contract: a name is never renamed and never removed, and a new kind of witness claims a new name.

The block witness is always present. Each entropy witness rides along only when that source had captured at least one observation by the time you submitted; a source with nothing captured simply contributes no name, and never a null. Naming fewer witnesses only makes the submitted-after claim more conservative, so entropy never blocks a submission.

signing_key_event is the one entry that is not part of an item’s metadata. It witnesses the proof’s Ed25519 signature rather than the submission, so a bundle carries it at the top level rather than inside the subject. See Ed25519 signatures for how it is checked alongside the pinned keyring.

Confirming a witness

A verifier confirms a witness in two independent stages.

1. Rehash the carried detail. The bundle carries the witness’s own bytes: the head block’s five fields for block, and the captured payload exactly as published for each entropy witness. Recomputing the hash from those bytes and comparing it to the hash the metadata commits to proves the bundle names the record it claims to name. This stage needs no network access.
2. Look the record up at its public source. Fetching the Stellar ledger, the NIST pulse, or the Bitcoin block from its own public source, and comparing the published fields, proves the record is real and pins the published time the edge rests on. This stage needs network access and is skipped when a verifier is offline.

Both stages are recorded in the verification report; see verify a proof.

Extensibility

A verifier hashes the carried metadata exactly as it finds it, so a witness name a given verifier does not recognize never breaks the fingerprint or fails the proof: it is reported as skipped, with a note that the name is unrecognized. That is what allows a new kind of witness to be added without changing the bundle format version, and it is why names are never reused for a different meaning.

Limitations

• A witness establishes only that its record already existed. It says nothing about when the submitted data was created or who wrote it; see what Truestamp does not prove.
• A witness whose detail is not carried in a bundle cannot be confirmed from that bundle alone. The metadata still names it, so the fingerprint is intact and the edge is still committed, but establishing it then requires fetching the record from Truestamp.
• An entropy source that freezes and republishes an old value still confirms as existing. Existence is confirmable; freshness is not. See entropy verification levels.