Tapleaf

Tapleaf is one leaf of the Merkle tree that a Taproot output commits to alongside its internal public key. Each tapleaf bundles a leaf version byte with a complete Bitcoin script, and the pair is hashed into a tagged TapLeaf hash. Every alternative spending condition a Taproot output supports — a timelock recovery, a multisig fallback, a hashlock — is encoded as its own tapleaf, and only the leaf actually used ever has to be revealed on-chain. The rest of the tree stays private forever, which is the heart of Taproot's privacy and efficiency story.

Anatomy of a tapleaf

The TapLeaf hash is computed as a tagged hash (per BIP340's tagged-hash convention, with the tag "TapLeaf") over three fields: the leaf version, a compact-size length prefix, and the raw script bytes. The standard leaf version is 0xc0, which selects the Tapscript validation rules defined in BIP342 — the modernized script semantics described under Tapscript. Leaf versions must be even, because the lowest bit of the control block's first byte is reserved for signaling the Y-coordinate parity of the output key, and the value 0x50 is excluded because it would collide with the annex marker. This carefully reserved structure means entirely new script versions can be introduced later by soft fork: old nodes treat unknown leaf versions as anyone-can-spend and ignore them, while upgraded nodes enforce the new rules.

Building the tree

Individual TapLeaf hashes are combined pairwise into TapBranch hashes, with each pair sorted lexicographically before hashing so the tree has a canonical form regardless of sibling order. Branches combine upward until a single Merkle root remains, and that root is tweaked into the internal key to produce the output key the world sees — the construction specified in BIP341. The tree need not be balanced: a wallet can place likely-used scripts near the top (shorter proofs, cheaper spends) and unlikely emergency clauses deeper down. Because only a Merkle path is revealed at spend time, the on-chain footprint grows logarithmically with the number of conditions, and nothing about the tree's total size or shape leaks.

Spending a leaf

To spend via a tapleaf, the spender's witness supplies three things: the inputs that satisfy the leaf's script, the script itself, and a control block containing the leaf version, the internal key, and the Merkle path proving this leaf belongs to the committed tree. Validators recompute the TapLeaf hash, walk the path to the root, apply the tweak, and check the result matches the output key. This is the script-path side of Taproot's fundamental choice — cooperative key-path spends reveal nothing at all, while script paths reveal exactly one leaf — a trade-off explored under key path vs script path spend.

Why it matters

Tooling has made tapleaves practical rather than theoretical. Output descriptors can express an entire tap tree — internal key plus nested leaves — in a single string a wallet can back up and restore, and policy compilers translate human-readable spending conditions into optimized leaf scripts and tree layouts automatically. A representative pattern: a vault whose key path is a cooperative multisig for everyday spending, with tapleaves holding a timelocked single-key recovery for inheritance and a deeper emergency clause. Used daily, the output reveals nothing but a key-path spend; the leaves exist only as hashes unless the bad day actually arrives.

Tapleaves let complex contracts ride inside outputs that look identical to simple payments. Unused conditions cost nothing and reveal nothing; a wallet can carry elaborate recovery logic without bloating the chain or advertising its security model. For anyone designing vaults, inheritance schemes, or multi-path Lightning-adjacent contracts, the tapleaf is the unit of composition: one condition, one leaf, one hash in the tree.