Merkle root

The Merkle root is how a 108-byte header vouches for a block full of transactions.

Every transaction ID in the block is hashed in pairs, the pairs are hashed in pairs, and so on, until one hash is left. That hash goes into the header. Change, add, remove or reorder a single transaction and the root comes out different, so the header no longer matches the block.

The tree itself is explained step by step in Merkle trees. This page is about the header field: where it sits, what it covers and what it doesn’t, and the part it plays in Pearl’s mining.

Try it

Add, edit or reorder transactions and watch the root recompute.

Where is it in the header?

Size

32 bytes

Type

SHA256d Merkle root of the txids

Format

Internal byte order (shown reversed)

Bytes 36 to 67. In block 130,827 they are 6389faa3…0c1cc2c6, which an explorer shows reversed as c6c21c0c4204b9f39e17d7f79811aff53eac88ea0d80fcdeffdad96ba3fa8963. That block has 6 transactions, so its tree has three levels above the leaves:

A node rebuilds the tree from the transactions it received and compares the result with the header. If they differ, the block is invalid, before any expensive checks run.

What does the simplest tree look like?

One leaf. If a block contains only its coinbase, the Merkle root is the coinbase’s txid.

Block 1 is such a block. Its coinbase’s txid is 36b18b26fba6b71149951d88904945c64137e74b250de8d76c4beded90560be2, and here it is in the header, stored reversed:

This is common on Pearl. In a 200-block sample taken on 2026-10-20, 107 blocks contained nothing but their coinbase.

What does the root cover, and what not?

It covers the txids. A txid is the hash of a transaction without its witness data, the signatures that unlock its inputs. So the header’s Merkle root doesn’t directly cover signatures.

Witnesses are covered one step removed, exactly as in Bitcoin’s segwit:

1. A second tree over wtxids

   The node builds another Merkle tree over every transaction’s wtxid (the hash including witness data), with the coinbase’s set to 32 zero bytes.

2. Its root goes into the coinbase

   SHA256d of that root and a 32-byte reserved value is written into a coinbase output starting 6a24aa21a9ed: the witness commitment.

3. The coinbase is under the main root

   The coinbase’s txid is the first leaf of the header’s tree, so the header vouches for the witness commitment, which vouches for every witness.

Here is the witness commitment in block 130,825’s coinbase, output 1:

A coinbase-only block can leave the commitment out: it has no witnesses to commit to. Some Pearl miners do, and others include it anyway.

The certificate is not under the Merkle root. It isn’t a transaction. It is tied to the header through the last field, the proof commitment, which hashes the certificate’s version and public data.

Why does the Merkle root matter to miners?

Because it is one of the inputs to the mining puzzle. The first 76 bytes of the header, Merkle root included, are hashed into the job key, and the job key seeds all of the noise a miner must add to its matrices.

So any change to the block’s transactions gives the miner a completely new puzzle:

• a new transaction from the mempool changes the root;
• so does changing a few bytes of the coinbase. Pools put an extranonce there, as in Bitcoin, and on Pearl every new extranonce means a fresh job. Kryptex’s coinbase in block 130,825 ends with 12 such bytes, 1550cad31e016e7bf00f2ecb, after its pool tag /pool.kryptex.com/.

Can a light wallet use Merkle proofs on Pearl?

It can, but it would only be trusting the header. Bitcoin’s old way for light wallets (BIP 37) sends a merkleblock: a header plus a Merkle proof for the wallet’s transactions. Pearl still has that message, but it carries the bare 108-byte header with no certificate, so a client relying on it alone couldn’t check that the block was really mined.

Pearl’s own light client works differently. It follows the compact-filter design (BIP 157/158), downloads every header with its certificate, and verifies each certificate’s zero-knowledge proof before trusting the chain. See light clients.

calcMerkleRoot := CalcMerkleRoot(block.Transactions(), false)
if !header.MerkleRoot.IsEqual(&calcMerkleRoot) {
	str := fmt.Sprintf("block merkle root is invalid - block "+
		"header indicates %v, but calculated value is %v",
		header.MerkleRoot, calcMerkleRoot)
	return ruleError(ErrBadMerkleRoot, str)
}