Overview

Truestamp uses the word “commitment” for two distinct, load-bearing events, and a complete proof depends on both. Item Commitment happens when an item’s item_hash becomes a leaf in the Merkle tree of a finalized internal block, which places the item inside that block’s submission window and moves the item into a committed state. Block Commitment happens when a finalized block is included in a batch (an epoch) whose Merkle root is recorded on a public blockchain such as Stellar or Bitcoin, which proves the Truestamp block existed before the public chain recorded it and moves the block into a committed state. The first event ties your item to Truestamp’s internal ledger; the second ties that ledger to an independent, external witness. Keeping the two meanings separate is essential when reading proofs, state, and verification results.

Item Commitment

Item Commitment binds a single item to one internal block. When a block is finalized, Truestamp builds a Merkle tree over the items collected for that block, and each item’s item_hash becomes a leaf of that tree. That inclusion is recorded as a per-item commitment record holding the compact Merkle inclusion proof, the block’s Merkle root, and an Ed25519 signature, so the binding can be checked independently later. Exactly one such commitment exists per item.

Because the item is now provably a member of that block’s Merkle tree, it is provably inside the block’s submission window. At that point the item transitions from its processing state to committed. This is what committed means for an item: it has received Item Commitment through Merkle-tree inclusion in a finalized block. It does not yet imply anything about any public blockchain.

Item Commitment on its own establishes an internal, self-consistent record: given the item’s hashes, the Merkle proof, the block’s Merkle root, and the block signature, anyone can confirm the item belongs to that specific block. What it cannot do by itself is prove that Truestamp did not construct the whole block retroactively. That is the job of Block Commitment. For how the inclusion proof itself is structured, see Merkle inclusion proofs.

Block Commitment

Block Commitment binds internal blocks to a public blockchain. Once a block is finalized it carries a block_hash that commits to all of the block’s fields, including its Merkle root. Rather than write each block_hash to a public chain on its own, Block Commitment batches many finalized blocks together: it builds a Merkle tree over all the block hashes accumulated since the last commitment and records the single Merkle root of that batch on an external chain such as Stellar or Bitcoin. This batch is called an epoch, and the value written on-chain is the epoch’s Merkle root. Because the public chain’s own record is timestamped by a network Truestamp does not control, recording the epoch root there proves every Truestamp block in that batch existed before the public chain wrote it down.

Batching is what makes Block Commitment efficient: one public-chain transaction commits to a whole batch of blocks through their shared Merkle root, and each individual block gets a compact inclusion proof (its block_hash and a short list of sibling hashes) that resolves to that on-chain root. So a block’s block_hash is not written on-chain by itself; instead the block is proven to belong to the batch whose root was written.

A block is created directly in a finalized state. When at least one public-blockchain commitment covers it, the block transitions to committed. The transition is idempotent and designed for multiple chains: the block flips to committed on the first successful public-chain commitment, and later commitments to other chains add redundant external proof without changing the state again. A single block can therefore carry commitments to both Stellar and Bitcoin for cross-chain redundancy, with committed reflecting the first one recorded rather than all configured chains.

Block Commitment is the piece that a downstream verifier can independently re-check against the public chain, and it takes two steps. First, verification confirms that the epoch’s Merkle root really appears on-chain: it reads the value the external transaction recorded (a Stellar memo hash or a Bitcoin OP_RETURN) and checks that it matches the epoch root. Second, verification replays the block’s own inclusion proof to confirm the block_hash resolves to that same epoch root. Only when both hold, the epoch root is on the public chain and the block provably belongs to that epoch, is the block treated as committed. Each chain has its own external verification path, and a commitment reports as valid only when the external record is found and matches.

Why both matter

The two commitments answer two different questions, and a trustworthy proof needs both.

• Item Commitment answers “is this specific item part of a specific Truestamp block?” It proves membership and integrity against Truestamp’s internal ledger, but that ledger is authored by Truestamp.
• Block Commitment answers “did that Truestamp block exist before an independent public blockchain recorded it?” It removes the need to trust Truestamp’s clock or good faith, because an external network witnessed the epoch root that the block’s hash provably resolves to.

Chained together, an item that has received Item Commitment inside a block that has received Block Commitment is provably a member of a block whose existence was witnessed by a public chain. That chain of reasoning is what lets a proof establish the item’s submission window without asking anyone to trust Truestamp. The end-to-end sequence that walks an item from creation through Item Commitment and Block Commitment is described in the proof lifecycle.

Reading state and terminology

The same word, committed, appears on both items and blocks and means different things.

• An item in the committed state has received Item Commitment: its item_hash is a leaf in a finalized block’s Merkle tree. This says nothing about public blockchains.
• A block in the committed state has received Block Commitment: it belongs to a batch (an epoch) whose Merkle root has been recorded on at least one public blockchain, with an inclusion proof tying its block_hash to that recorded root.

Both blocks and their commitment records are part of the public, verifiable ledger and are readable by anyone through the public explorer pages. A block being merely finalized means its items are already committed to it internally, but the block itself is still waiting to be recorded on a public chain. Watching for the block’s transition to committed is how you know the external, public-blockchain step has completed.