Overview

An epoch is the batch that Truestamp uses to perform Block Commitment. After many internal blocks have been finalized, Truestamp gathers all of their block hashes accumulated since the last commitment of a given kind, builds a single Merkle tree over those block hashes, and records only the one Merkle root of that tree, the epoch root, on a public blockchain. Recording a single root instead of one transaction per block is what makes public commitment efficient: one public-chain transaction commits to a whole batch of blocks at once.

Each finalized block covered by the epoch then receives a small record that carries a compact Merkle inclusion proof tying that block’s block_hash to the epoch root, and the block transitions from finalized to committed. This is Block Commitment, the second of Truestamp’s two commitment events. It is distinct from Item Commitment, where an item’s item_hash becomes a leaf in a block’s own Merkle tree. The distinction between the two is covered in Item Commitment vs Block Commitment.

Truestamp commits to two independent public chains, each in its own series of epochs. On Stellar the epoch root is written as the transaction’s memo hash (MEMO_HASH); on Bitcoin the epoch root is written as OP_RETURN data. A single block can end up in one Stellar epoch and one Bitcoin epoch at the same time, giving it redundant, cross-chain external witnesses. The epochs and per-block inclusion records are part of the public, verifiable ledger and can be read by anyone; each block’s detail page in the public explorer renders its Stellar and Bitcoin commitment details.

What an epoch batches

An epoch always describes one commitment method and one contiguous range of internal blocks:

• method - which public chain this epoch was recorded on, either Stellar or Bitcoin.
• block range - the first and last internal block covered, inclusive. The range starts at the first block that had not yet been committed by this method and ends at the current stable head of the internal chain at the time the epoch was formed.
• epoch Merkle root - the root of the Merkle tree built over the block_hash of every block in the range. This is the single value recorded on the public chain.

Because each method advances independently, Stellar epochs and Bitcoin epochs cover overlapping but separately tracked ranges. Every new epoch for a method begins where that method’s last fully recorded epoch ended, so together the epochs for one method tile the internal chain without gaps. Truestamp also stores an Ed25519 signature over the epoch’s committed fields, so the epoch-level record is itself tamper-evident before you even reach the public chain.

The epoch Merkle tree and per-block proof

The epoch tree is an ordinary Merkle tree whose leaves are the block hashes in the range, one leaf per block, ordered by block id. Its root is the epoch root that goes on-chain. For every block in the epoch, Truestamp derives that block’s inclusion proof: the short list of sibling hashes that, combined with the block’s own block_hash, recomputes the epoch root. That proof is stored as a compact binary structure on a per-block record, one record per block per method.

This is a deliberate two-layer arrangement of Merkle trees. The lower layer is a block’s own tree, whose leaves are item hashes and whose root is that block’s Merkle root (this is Item Commitment). The upper layer is the epoch tree, whose leaves are block hashes and whose root is recorded publicly (this is Block Commitment). A complete proof walks both layers: an item resolves to its block’s Merkle root, the block’s block_hash resolves to the epoch root, and the epoch root is found on the public chain. The structure of a single Merkle inclusion proof is described in Merkle inclusion proofs.

The per-block record does not need its own signature. Its integrity comes from Merkle math: replaying the stored proof against the epoch’s signed root either reproduces that exact root or it does not. There is no third outcome, so a tampered block hash or a tampered proof simply fails to verify.

Recording the root on a public chain

Recording an epoch is split into steps so that a crash or a network failure between the public-chain call and Truestamp’s own bookkeeping can never charge a fee twice or leave a half-written epoch:

1. Reserve. Truestamp first records its intent to commit: it fixes the block range and computes the epoch root, and stores a pending epoch with no chain transaction yet. The pairing of method and epoch root is unique, so two attempts can never claim the same commitment.
2. Submit. Truestamp submits the epoch root to the public chain. On Stellar the root becomes the transaction memo hash; on Bitcoin it becomes the OP_RETURN payload. When the chain accepts the transaction, Truestamp records the chain’s transaction details alongside the epoch and marks it submitted.
3. Record. In one all-or-nothing step, Truestamp creates the per-block inclusion records for the whole range, transitions every finalized block in the range to committed, and marks the epoch fully recorded. Either all of this happens or none of it does.

If a worker retries after any step, it resumes from wherever the epoch already is rather than resubmitting to the chain. Only a fully recorded epoch counts as the prior epoch when the next range is computed, so an in-flight reservation is always finished before any new work begins.

Verifying an epoch against the public chain

Block Commitment is the part of a proof that anyone can re-check against an independent public chain, without trusting Truestamp. Verification takes two parts and both must hold:

• On-chain match. The value the external transaction actually recorded is read back from the chain, the Stellar memo hash or the Bitcoin OP_RETURN data, and compared to the epoch root. A mismatch fails.
• Inclusion match. The block’s stored inclusion proof is replayed to confirm the block’s block_hash resolves to that same epoch root. A mismatch fails.

Only when both parts pass, the epoch root is present on the public chain and the block provably belongs to that epoch, is the block treated as committed by that method. Each chain has its own verification path, and a given commitment reports valid only when its external record is found and matches. The end-to-end sequence that carries an item from submission through Item Commitment and Block Commitment is described in the proof lifecycle.

Reading epochs

Epochs and their per-block inclusion records are public read-only ledger data. They can be listed and fetched over the public read APIs, and they are never updated or deleted once recorded. A block itself exposes whether it has a Stellar commitment and whether it has a Bitcoin commitment, so you can see at a glance which public chains have witnessed it. A block that is still merely finalized has been fully committed to internally but is not yet part of any recorded epoch; watching for its transition to committed is how you know the public-chain step has completed.

Limitations

• An epoch proves that every block in its range existed before the public chain recorded the epoch root. It does not, on its own, prove anything about an individual item; that is the job of the block’s own Merkle tree (Item Commitment), which the epoch sits on top of.
• The committed state on a block reflects the first public chain to witness it, not all configured chains. A block can be committed on Stellar while its Bitcoin epoch is still in flight, or the reverse.
• A block is only committed once its epoch is fully recorded. Between finalization and the next epoch being recorded on a chain, the block is witnessed internally but has no public witness yet.