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 three linked stages: an item is submitted and its cryptographic fingerprint is placed into a Truestamp block (item commitment), the block’s own fingerprint is then 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 a the item’s composite fingerprint (independent, domain-separated hashes bound into one value, see hashing and domain separation) and assigns it an identifier whose timestamp records when it entered the system. A freshly submitted item begins in a created state.

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 before a particular block was finalized. 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 all items waiting since the previous block 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, the Merkle inclusion proof from the item commitment, the block’s fields, and the public-chain commitment evidence from the block commitment. That artifact is what a verifier checks. You can generate it as an item proof from the API or take it to the public verify page.

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. The underlying facts never change; the amount of independent public corroboration grows as more commitments confirm.

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 before a block was finalized, and that the block was committed to a public chain, 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.