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—the same block hash you see 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

                 [ Block hash / Merkle root ]
                        /              \
                 [ Hash AB ]        [ Hash CD ]
                  /      \            /      \
            [ Tx A ]  [ Tx B ]  [ Tx C ]  [ Tx D ]

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 a standard proof format.
Block hash / Merkle target — the root you should arrive at if the proof is valid.

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 published block hash, the proof verifies—you were in that block.

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 Merkle proof from the blockchain and stores:

the proof nodes (sibling hashes),
the Merkle target (block root),
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, then orange block hash. 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.

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.
Merkle root: The single top hash summarizing all transactions in the block.
Block hash: The block header identifier; should match the Merkle root in the header.
Proof format: A compact, tokenized encoding of sibling hashes along the Merkle path.