MAST (Merkelized Alternative Script Trees)

What Is MAST?

MAST (Merkelized Alternative Script Trees) is a technique for encoding multiple spending conditions into a single Bitcoin output using a Merkle tree. Each spending condition becomes a leaf in the tree, and the tree's root is committed to the output. When spending, the user reveals only the specific condition they are executing along with a compact Merkle proof that it belongs to the tree. Every other condition stays hidden.

The concept was first described by Russell O'Connor in 2013 and formalized in a 2014 MIT paper by Jeremy Rubin, Manali Naik, and Nitya Subramanian under the original name "Merklized Abstract Syntax Trees." It was later renamed to "Merkelized Alternative Script Trees" by Anthony Towns, since the actual implementation organizes alternative Bitcoin Script branches rather than compiling scripts into abstract syntax trees.

Several standalone proposals attempted to bring MAST to Bitcoin (BIP-114 by Johnson Lau in 2016, BIP-116/117 by Mark Friedenbach in 2017), but none were activated independently. Instead, the MAST concept was incorporated into the Taproot upgrade, which activated at block height 709,632 on November 14, 2021.

How It Works

MAST in Taproot combines two spending paths into a single output: a key path for cooperative spending and a script path that uses the Merkle tree of alternative conditions.

Building the Script Tree

Each spending condition is written as a Bitcoin Script and becomes a leaf node in a binary Merkle tree:

1. Each leaf is hashed using a tagged hash function: hashTapLeaf(leaf_version || script_length || script)
2. Pairs of hashes are combined upward: hashTapBranch(lower_hash || higher_hash), with operands sorted lexicographically to eliminate the need for ordering metadata
3. Recursive hashing continues until a single 32-byte Merkle root remains

The Merkle root is then used to tweak an internal public key P, producing the output key Q = P + t*G, where t is derived from hashTapTweak(P || merkle_root). This leverages Schnorr signatures' linearity: tweaking both public and private keys by the same value preserves their validity as a key pair.

Key Path Spend (Cooperative)

When all parties agree, they produce a single Schnorr signature against the tweaked output key. No scripts, no Merkle proofs, nothing about the tree is revealed. The transaction looks identical to any ordinary single-key P2TR spend, costing approximately 57.5 vbytes per input.

This is Taproot's central insight, credited to Gregory Maxwell: most multi-party contracts have an "everyone agrees" outcome that should be optimized for. MAST provides the fallback complexity without penalizing the common case.

Script Path Spend (Non-cooperative)

When the cooperative path is unavailable, a script path spend reveals just the relevant leaf:

1. The spender provides the script inputs (data satisfying the script)
2. The leaf script itself
3. A control block containing the internal public key, the leaf version, and the Merkle path (the sibling hashes needed to reconstruct the root)

Validators reconstruct the Merkle root from the leaf hash and the provided path, verify it matches the output's tweak, and then execute the script. The control block is 33 + 32m bytes, where m is the path depth (0 to 128).

# Conceptual structure of a MAST tree with 4 spending conditions
#
#              Merkle Root
#              /         \
#           Branch       Branch
#          /     \      /     \
#     Leaf A   Leaf B  Leaf C  Leaf D
#  (2-of-3)  (time-   (arbi-  (inheri-
#             lock)    trator)  tance)
#
# Spending via Leaf B requires:
#   - Script inputs satisfying the time-lock condition
#   - Leaf B script
#   - Merkle proof: [Hash(Leaf A), Hash(Branch CD)]
#   - Internal public key
#
# Leaves A, C, and D remain completely hidden

Huffman Optimization

Spending conditions expected to be used more frequently should be placed closer to the root, resulting in shorter Merkle paths and smaller witness data. This Huffman-style optimization ensures that the most likely spending paths are also the cheapest to execute on-chain.

MAST vs. Legacy Script

Before MAST, complex spending conditions used P2SH or P2WSH outputs, which required revealing the entire script at spend time:

For a detailed walkthrough of these output types, see the Bitcoin address types research article.

Use Cases

Complex Multisig with Fallbacks

Consider a business treasury controlled by three partners. MAST enables a tiered spending policy:

• Key path: 3-of-3 cooperative spend using FROST or MuSig2 (cheapest, most private)
• Leaf A: 2-of-3 multisig (if one partner is unavailable)
• Leaf B: 2-of-3 multisig with a different subset
• Leaf C: third 2-of-3 combination

With legacy P2WSH, all three fallback branches would be exposed whenever any one was used. With MAST, using Leaf A reveals nothing about Leaves B or C.

Time-Locked Alternatives

MAST pairs naturally with timelocks for progressive fallback conditions:

• Key path: immediate 2-of-2 cooperative spend
• Leaf A: after 30 days, one party can spend with CSV
• Leaf B: after 90 days, a designated arbitrator can intervene

Inheritance planning is a natural extension: family members set up an output requiring all signers initially, with progressively relaxed requirements as time passes (e.g., after 6 months only N-1 signers needed, after 12 months N-2, eventually a single heir with legal assistance).

Conditional Payments and HTLCs

Hash time-locked contracts used in Lightning and atomic swaps naturally map to a two-leaf MAST tree: one leaf for the hash-lock payment clause, another for the time-lock refund clause. PTLCs, the next-generation replacement using adaptor signatures, further leverage Taproot's Schnorr foundation alongside MAST.

Policy-Driven Spending with Miniscript

Miniscript compiles human-readable spending policies into optimized Bitcoin Scripts. When combined with MAST, complex policies compile into efficient script trees with each condition as a separate leaf, automatically optimized for the most likely spending path. For more on how spending policies compose, see the Miniscript spending policies research article.

Why It Matters

MAST makes Bitcoin smart contracts practical at scale. Before Taproot, a contract with 10 spending conditions required revealing all 10 at spend time, leaking the contract's full logic and creating large transactions. With MAST, the same contract reveals only 1 condition plus a 4-hash Merkle proof, regardless of total complexity.

The privacy implications are significant: observers cannot determine what alternative conditions existed, how many parties were involved, or what fallback logic was available. When the cooperative key path is used, the transaction is indistinguishable from an ordinary single-key spend.

Layer 2 protocols like the Lightning Network and Spark benefit directly. Channel outputs can encode complex state transitions, penalty mechanisms, and cooperative close paths in a MAST tree, keeping the cooperative case cheap and private while retaining the security of on-chain enforcement when needed.

Risks and Considerations

Complexity in Script Design

Designing an optimal MAST tree requires careful consideration of which conditions are most likely and how to arrange them for minimal proof size. Poorly structured trees waste witness space. Tools like Miniscript and output descriptors help automate this, but the design space is still more complex than legacy scripts.

Recovery and Backup

A MAST output is only spendable if the user retains the full tree structure (all leaf scripts and the internal key). Losing any branch means losing the ability to reconstruct the Merkle root, potentially making verification of alternative spending paths impossible. Wallet backup strategies must account for the full descriptor including all tree branches, not just the key path.

Maximum Tree Depth

BIP-341 limits the Merkle path to 128 levels, theoretically allowing 2^128 leaf scripts. In practice, trees beyond a few dozen leaves are rare. The depth limit exists because scripts at deeper levels would have an execution probability below Bitcoin's security bound of 1 in 2^128, making them effectively unreachable.

Adoption and Tooling

While Taproot activated in November 2021, wallet and application support for script-path spends (the MAST functionality) has been slower to develop than key-path support. Developers building MAST-based contracts need libraries that support Tapscript construction, BIP-342 script validation, and proper tree commitment.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.