MAST (Merkelized Alternative Script Tree)

A Merkelized Alternative Script Tree, or MAST, is a way to lock bitcoin to many possible spending conditions while only ever revealing the one condition actually used. The idea circulated for years as a proposed standalone upgrade before being absorbed into Taproot, where it ships today as the script-path machinery specified in BIP341. It builds on the same Merkle-tree technique that summarizes transactions inside a block: commit to many things with one hash, prove membership of any single thing with a short branch of hashes.

The problem it solves

Before MAST, a contract with multiple alternative spending conditions had to publish all of them. A P2SH redeem script spelling out "spouses can spend together, OR either spouse alone after 90 days, OR a lawyer with a timelock after a year" put every branch on-chain the moment the coins moved — paying fees for bytes that were never executed and telling the whole world your contingency planning. Complex contracts were penalized twice, in cost and in privacy, which discouraged exactly the kind of robust multi-path custody a careful holder wants.

How MAST works

Each alternative script is hashed and placed as a leaf in a Merkle tree. The coins commit to the single Merkle root of that tree — one 32-byte value standing for any number of scripts. To spend, the owner reveals only the specific script being executed, its satisfying witness data, and a short Merkle proof showing that script was a leaf under the committed root. Verifiers hash their way up the branch and compare against the commitment; the sibling hashes reveal nothing about what the other branches contained, or even how many there were. Proof size grows only logarithmically, so a tree of dozens of conditions costs barely more to use than a tree of two.

Absorbed into Taproot

Standalone MAST proposals (drafted as BIPs 114 and 116-117 in earlier forms) never activated on their own. Instead, Taproot (BIP341) merged the concept with Schnorr key aggregation into something stronger: an output commits to both an internal key and an optional script tree tweaked into it. In the cooperative case, participants sign with the aggregated key — a key-path spend — and the entire script tree remains invisible forever; the sophisticated contract is indistinguishable from an ordinary single-signature payment. Only when cooperation fails does a script-path spend reveal one leaf, accompanied by a control block carrying the Merkle proof. The Schnorr signature scheme is what makes the cooperative half possible, and MAST is what makes the fallback half private.

Why it matters

For the sovereign holder, MAST-style commitments changed the economics of careful custody. Inheritance plans, decaying multisig, vault-like timelock ladders — designs that once leaked their full structure on every spend now reveal at most one branch, and ideally none. Fees track what you execute rather than what you prepared for, so there is no longer a cost penalty for planning thoroughly. Modern wallet tooling builds these trees for you: policy languages let you write "any two of my three keys now, or my recovery key after a year" and compile it into a Taproot tree, with the everyday cooperative path staying on the cheap, private key path and the emergency branches sitting silently in the tree until the day they are needed. In practice most such coins are spent cooperatively, meaning the market's growing use of script trees is largely invisible on-chain — which is itself the privacy win working as designed. MAST is one half of what makes Taproot powerful; the aggregated-key spending path is the other. Read Schnorr Signature for the key-path half, and key path vs script path spend for how wallets choose between the two at spend time.