Guide

Merkle proofs & paths

How DataSeal.net shows that your timestamp transaction really landed in a specific block—and how anyone can check that story with math, not trust. New to blockchains? Start with our truth machine guide.

What problem does this solve?

When you timestamp content with DataSeal.net, we anchor a fingerprint on the blockchain. A public certificate shows that anchor—but a careful reader will ask: how do I know this transaction is actually inside the block you claim?

A Merkle proofanswers that question. It is a compact bundle of hashes that proves your transaction is a leaf in the block's Merkle tree, and that the tree's root matches the block header.

Two different hashes—don't mix them up

Clone-proof fingerprint — the SHA-256 hash of your file or text. This proves what you timestamped.
Transaction ID— the on-chain anchor transaction that carries your fingerprint (and related metadata). The block's Merkle tree uses this transaction as its leaf—not your content fingerprint directly.

The Merkle proof shows your transaction landed in a block. Your fingerprint still proves which bytes that transaction referred to.

How the pieces connect

Your file or text
      │
      ▼  SHA-256
Clone-proof fingerprint  ──embedded in──▶  Anchor transaction  ──▶  Merkle leaf
 (on the certificate)                         (transaction ID)         (in the block)

Verifying a certificate usually means checking both layers: recompute the fingerprint from your bytes, and check that the published transaction ID is included in the block via the Merkle path.

Blocks are trees of hashes

Imagine a block as a sealed package of transactions. To summarize every transaction efficiently, blockchains build a binary tree of hashes called a Merkle tree:

Each transaction becomes a leaf.
Pairs of hashes are combined upward until one hash remains: the Merkle root.
That root is stored in the block header as the Merkle root field—separate from the block hash shown on a certificate.

If even one leaf changed, the root would change. That is why the root acts like a fingerprint for the entire block's transaction list.

Simple mental picture

                 [ Merkle root in block header ]
                        /              \
                 [ Hash AB ]        [ Hash CD ]
                  /      \            /      \
            [ Tx A ]  [ Tx B ]  [ Tx C ]  [ Tx D ]

Block hash = hash of the full header (includes Merkle root + other fields)

Your timestamp transaction is one leaf—not your content fingerprint. A Merkle proof collects the sibling hashes you need to walk from that transaction back up to the root.

What is a Merkle path?

A Merkle path (or Merkle branch) is the list of sibling hashes along the climb from your leaf to the root. At each step you combine your current hash with the sibling from the proof, then hash the pair to move one level up.

On a DataSeal.net certificate you will see:

Transaction ID — your anchored transaction (the leaf you start from).
Proof nodes — sibling hashes supplied by the blockchain network in the TSC standard.
Block header Merkle root — the root your proof should reach; stored in the block header and used to build the block hash.

The TSC standard

On Bitcoin SV, Merkle proofs are exchanged in a shared format called TSC (Transaction Signature Component). It is documented by the Bitcoin SV Technical Standards Committee as TS 2020.010 — Merkle proof standardised format.

TSC defines how proof data is structured—typically as JSON with fields such as the transaction index, sibling hashes (nodes), the Merkle target (target), and the leaf transaction identifier. That standardisation matters because it lets wallets, block explorers, and verification tools all speak the same language when proving that a transaction is inside a block.

DataSeal.net fetches TSC proofs from the network after your anchor transaction confirms, then publishes the proof nodes and Merkle target on your public certificate. Independent verifiers can recompute the path using the same TSC rules—no proprietary format required.

Read the specification: Merkle proof standardised format (TSC).

Worked example (simplified)

Suppose your transaction leaf is L, proof nodes are N1 then N2, and the block root is R:

Combine leaf + first node: H(L, N1) → A
Combine result + second node: H(A, N2) → R
If the final value equals the block header Merkle root, the proof verifies—you were in that block's transaction tree.

Real proofs on the blockchain follow exact hashing rules and leaf ordering; the idea is the same even when there are many more levels.

What you see on a public certificate

When a proof link is active and the network has confirmed your transaction, DataSeal.net fetches a TSC Merkle proof from the blockchain and stores:

the proof nodes (sibling hashes),
the block header Merkle root (when synced),
and metadata such as confirmation counts and block height.

The interactive 3D Merkle path on the certificate maps the full story: blue diamond for your data fingerprint (dashed line into the anchor), gray transaction sphere, teal sibling nodes, red Merkle root sphere, then orange block hash cube. Click any node to read its full hash.

Two layers of proof

Merkle inclusion proves your anchor transaction is in a specific block. It does not, by itself, prove the semantic meaning of your original file—that still comes from your clone-proof SHA-256 fingerprint and independent verification of your bytes.

Think of it as two layers working together:

Content fingerprint — proves which data you timestamped (your file or text bytes). Learn about hashing.
Merkle proof — proves when and where the anchor transaction that carries that fingerprint landed on-chain.

Related guides

Confirmations & Merkle timing — when first confirmation, deep confirmation, and Merkle “Ready” usually appear
Verify a proof yourself — checklist once the certificate shows inclusion evidence

Glossary

Content fingerprint: SHA-256 of your file or text—the hash shown at the top of a certificate.
Transaction ID: Identifier of the on-chain anchor that embeds your fingerprint; this is the Merkle leaf.
Leaf: A transaction in the block's Merkle tree—not your content fingerprint.
Proof node: A sibling hash supplied so you can combine upward one level.
TSC: Transaction Signature Component—the BSV Technical Standards format (TS 2020.010) for Merkle inclusion proofs.
Merkle root: The single top hash summarizing all transactions in the block.
Block hash: The block header identifier (hash of header fields, including the Merkle root).
Proof format: The encoding used for proof data on a certificate; DataSeal stores TSC proofs as JSON.