MAST

The idea predates its deployment. Two proposals, BIP-114 and BIP-116, described it in 2016 and 2017 and neither activated; Taproot shipped it in 2021 as the taptree, whose script path spends reveal one leaf plus a proof of 32 bytes per level. For a wallet with several recovery paths, the chain only ever learns about the one you actually took.

How it works

A tree of scripts collapses into a single hash, and that hash is what the address commits to.

Start with the conditions you want. Say four: your everyday key, a two-of-three family quorum, a lawyer's key after a year of inactivity, and an emergency key held offsite. Each condition is written as its own small script, and each is hashed into a leaf. Leaves are paired and hashed, those results are paired and hashed again, and the process ends at one 32-byte root.

Spending reveals the leaf you used, its script, and the sibling hashes along the path from that leaf back to the root. Two levels of tree means two sibling hashes, 64 bytes, and anyone can recompute the root and confirm the script was committed to. The other three conditions never appear. Nobody learns that a lawyer's key exists, that the family quorum was two-of-three, or that an offsite key was ever part of the arrangement.

The cost grows with the logarithm of the number of conditions, which is what makes the structure worth using. A tree of 8 scripts adds 3 hashes to the witness, a tree of 128 scripts adds 7, and BIP-341 permits a depth of 128 levels, so the control block accompanying a script path spend tops out at 4,129 bytes.

Naming is a mess and always has been. MAST is expanded as merkelized alternative script tree and as merkelized abstract syntax tree depending on who is writing; the second comes from BIP-114, where the tree held pieces of one script rather than a set of alternatives. Both refer to the same construction in practice.

Where you see it

Every Taproot address that has more than one way to spend it is running MAST, whether or not the wallet uses the word.

Timelocked inheritance wallets are the clearest case. Liana, for example, funds an address whose taptree holds a normal spending key and a recovery branch that becomes usable after a fixed wait, and a normal spend never publishes the recovery branch at all. Lightning uses the same shape for its newer channel outputs, keeping the punishment path hidden during a cooperative close.

There is a fee angle worth knowing before you build one. Balance matters: a leaf you expect to use often should sit near the top of the tree, because each extra level adds 32 bytes to the witness of every spend that goes through it. Wallets that let you set the tree layout usually do this for you, but coordinator software that dumps every condition into a flat balanced tree will make the common path pay for the rare ones.

MAST vs Taproot

MAST is the tree; Taproot is the tree plus an escape hatch. A pure MAST design would force every spend to reveal some script, so the chain would always learn that a contract existed even if it learned nothing about the unused branches.

Taproot adds a key at the root. The address commits to an internal public key tweaked by the Merkle root, and if everyone involved agrees, they sign with the tweaked key and publish nothing but a single signature. That spend is indistinguishable from a one-person payment. The tree is still there, still enforceable, and simply never shown. MAST supplies the privacy between branches, and Taproot supplies the privacy between a contract and an ordinary payment.