Taproot Merkle Path

The Taproot merkle path is the sequence of sibling node hashes a spender supplies to prove that a particular script belongs to the tree committed inside a Taproot output. When spending via the script path, the witness includes a control block whose trailing bytes are exactly this path: zero or more 32-byte hashes, one per level of the tree between the revealed leaf and the root, up to a maximum depth of 128 levels. The control block is therefore 33 + 32m bytes for m path elements — a leading byte carrying the leaf version and parity, the 32-byte internal key, then the path itself.

How verification consumes it

Validators start from the revealed script, computing its TapLeaf hash. They then fold in each path element in order using TapBranch, which sorts its two inputs lexicographically before hashing — the reason the path needs no left/right position flags at all. After the final element is absorbed, the result is a candidate Merkle root. Combined with the internal key from the control block, that root re-derives the tweak t, and the spend is valid only if P + t·G reproduces the output key committed on-chain. The whole proof is verified with nothing more exotic than SHA-256 and one elliptic-curve operation, cheap enough that even the most modest full node checks it without strain — sovereignty-grade verification at negligible cost.

What the path reveals, and what it hides

This is the privacy heart of Taproot's script machinery. The Merkle path exposes only the hashes of sibling branches, never their contents. An observer learns the single script that was executed and the depth of the branch it lived on, but every alternative spending condition — the timelocked recovery clause, the emergency multisig, the inheritance path — stays hidden behind an opaque 32-byte digest forever, unless it is itself used someday. And if the output is spent via the key path instead, the entire tree remains invisible: the chain shows an ordinary signature and nothing else. A complex multi-condition contract thus presents on-chain as a plain payment until the precise moment one specific condition fires, and even then only that condition surfaces. See key path vs script path spend for how the two spending modes compare.

Path length is a fee decision

Every level of depth adds 32 witness bytes to the spend, so the path's length is money. Wallets exploit this by shaping the tree deliberately: the branches most likely to be used are placed near the root, where their proofs are short and cheap, while rarely-exercised fallbacks are buried deep, where their longer proofs cost more but will probably never be paid for. Because witness bytes are discounted under SegWit weight accounting, even a deep path is affordable — but the optimization is real, and a well-designed vault encodes its own probability estimates into its tree shape. A single-leaf tree has an empty path (m = 0), the smallest possible script-path witness.

Where it sits in the stack

The 128-level depth cap deserves a note: it bounds the worst-case witness size and validation work per input while still permitting trees with up to 2¹²⁸ leaves — unimaginably more scripts than any real contract needs. In practice, wallets rarely go beyond a handful of levels, and the cap exists as a belt-and-suspenders limit so no adversarially constructed output can force validators into pathological amounts of hashing.

The merkle path is the connective tissue of BIP 341's script commitment: leaves are hashed by TapLeaf, joined by TapBranch, proven by the path, and sealed into the Taproot Output Key through the tweak. For anyone building or auditing a Taproot vault, learning to read a control block hash-by-hash is the difference between trusting wallet software and being able to verify, byte for byte, that your coins' escape hatches are exactly the ones you designed.