Knowledge Base

Overview

A Truestamp proof is not created in one step. It comes to exist through a lifecycle that turns a piece of submitted data into a compact artifact anyone can verify offline, and that artifact strengthens as commitments to public blockchains confirm. The lifecycle has four linked stages: an item is submitted and fixes the public records it witnesses, its cryptographic fingerprint is placed into a Truestamp block (item commitment), the block’s own fingerprint is recorded on public blockchains such as Stellar and Bitcoin (block commitment), and once at least one public commitment exists the proof becomes generatable and independently verifiable. This concept follows that arc. It does not define the proof file layout (see the proof bundle format) or the step-by-step verification checks.

Stage 1: submission

Everything starts when you submit an item. An item can be a hash of an external file, or the claims content itself when no hash is supplied. At submission Truestamp computes the item’s composite fingerprint, binding a hash of your claims to a hash of the system-generated timing metadata, each of them domain-separated (see hashing and domain separation). The item is also given an identifier whose timestamp records when it entered the system, and a freshly submitted item begins in a created state.

The same moment fixes the item’s witnesses: the block then at the head of Truestamp’s ledger, which is always named, and the newest observation captured from each public entropy source that had one. Each is recorded by hash inside the item’s system-generated metadata, which is hashed into the composite fingerprint, so which records an item was submitted against is decided once, at submission, and can never be chosen or revised afterwards.

At this moment the item exists in Truestamp but has no proof. Nothing has been committed to a block yet, and no block has been committed to a public blockchain. The item is simply waiting for the next block to be built.

The proof’s timing guarantee originates here. A proof attests to a submission window: it proves the item was submitted after the records it witnesses were published, and before the public-chain transaction that later committed the block holding it. It does not prove when the underlying fact originally came to exist, only that it was submitted within a verifiable window.

Stage 2: item commitment

Truestamp builds blocks on a regular cadence. When a block is built, the fingerprints of everything waiting since the previous block, the items submitted in that interval among them, are gathered into a single Merkle tree, and the block records that tree’s root. Inclusion of an item’s fingerprint as a leaf in a finalized block is the item commitment: it cryptographically proves the item existed within that block’s submission window. As the item moves through this, its state advances from created to processing to committed.

Each item commitment is recorded as its own durable, immutable record that stores the Merkle inclusion proof binding the item to its block. That inclusion proof is the piece a proof later carries to show the item’s fingerprint really belongs to the block’s Merkle root.

Item commitment proves membership in a Truestamp block, but a Truestamp block by itself is still internal. The next stage, block commitment, is what makes the proof trustworthy without trusting Truestamp.

Stage 3: block commitment

A newly built block starts in a finalized state. It has a complete Merkle tree, a block hash, and a signature, but it has not yet been committed to any public blockchain. Block commitment is the step that records the block’s fingerprint, batched together with other blocks, onto a public chain such as Stellar or Bitcoin. Once a block has been committed to at least one public blockchain, its state advances from finalized to committed.

Because block hashes are recorded on chains outside Truestamp’s control, a committed block can be independently confirmed against the public chain. This is what lets a proof be verified without ever contacting a Truestamp server: the block fingerprint is out there, publicly and permanently.

Block commitment happens on more than one chain, and the chains confirm at different speeds. A Stellar commitment typically appears within minutes, while a Bitcoin commitment takes longer. The block reaches the committed state on the first successful public commitment; later commitments to additional chains add further public evidence without changing the state. A block that has been committed to both Stellar and Bitcoin carries redundant, cross-chain evidence.

Stage 4: a verifiable proof

A proof can only be generated once the item’s block has been committed to at least one public blockchain. Ask for a proof before then and generation is refused: there is no external commitment yet, so the artifact would rest on Truestamp’s own signature alone, which would defeat the offline-verifiability promise. This gate is the reason the earlier stages must complete first.

Once the block is committed, generating a proof assembles a single self-contained artifact that carries the item’s submitted data, its metadata naming every witness by hash, the Merkle inclusion proof from the item commitment, the block’s own fields, and the public-chain commitment evidence from the block commitment. Nothing in it is opaque: the maps that hashes are computed over travel with the file, so a verifier recomputes each hash instead of being handed one. That artifact is what a verifier checks. You can generate and download it from the app or the API, and check it on the public verify page.

Generation also decides how much of the earlier edge travels with the file. By default a proof carries the full detail behind each witness, plus the ledger block that introduced the signing key when that block has itself been committed, so the whole submission window can be checked without asking Truestamp for anything. When the head block an item witnesses is not the direct predecessor of the block holding it, the file also carries the ledger blocks in between, so the link from one to the other is walkable. A compact variant leaves the witness details out. It verifies under the identical signature, because what is signed covers the fingerprint, the block and the commitment roots and never the witness details, and the metadata still names every witness by hash. Establishing the earlier edge from a compact file means fetching those records back from Truestamp. See proof claims by availability for what each variant survives.

The proof keeps strengthening after it first becomes verifiable. If it was generated when only the Stellar commitment had confirmed, regenerating it after the Bitcoin commitment lands yields a proof that carries both chains’ evidence, and a proof regenerated after the signing key’s own key-event block is committed carries that too. The underlying facts never change; the amount of independent public corroboration grows as more commitments confirm. The witnesses are the one part that never moves: they were fixed at submission, so an early proof and a late one name exactly the same ones.

Limitations

• A proof cannot exist before its block has a public-blockchain commitment. Submission and item commitment alone do not produce a verifiable proof.
• A proof attests to a submission window, not to creation time or original authorship. It proves the item was submitted after the public records it witnesses were published and before the public-chain transaction that committed the block holding it, nothing more.
• The committed block state means at least one public commitment succeeded, not that every configured chain has committed. Which chains are present depends on how far the independent commitment steps have progressed when the proof is generated.
• A proof can only be generated while the item itself is in the committed state. If the item is later redacted or scheduled for deletion, generating a new proof is refused; a proof generated earlier, while the item was still committed, remains independently verifiable no matter what happens to the item afterward.
• A proof can only be generated while the item’s stored data still reproduces the fingerprint recorded at submission. Generation recomputes the claims hash and the metadata hash from the stored maps and checks both against what was committed. If either no longer matches, generation is refused as subject_not_recomputable, naming which half drifted, rather than issuing a proof whose subject hash is absent from the block’s Merkle tree and which therefore no verifier could ever confirm. The refusal is permanent for that item, not a transient state worth retrying.
• A proof never carries less than was asked for. If Truestamp cannot sign it at that moment, cannot find a witness the subject’s fingerprint commits to and the request asked to carry, or cannot read a record the proof is built from, generation is refused and the proof is temporarily unavailable, rather than issued without that witness or record. The pages say so, and the APIs answer signing_unavailable, witness_unavailable (naming the witness) or lookup_failed. Nothing about the subject is at fault, and a later request can succeed.