Bitcoin Taproot Use Cases: Schnorr, MAST, and What You Can Build

What Taproot Enables

Bitcoin's Taproot upgrade activated at block 709,632 on November 14, 2021, introducing three interconnected improvements defined by BIP 340 (Schnorr signatures), BIP 341 (Taproot spending rules), and BIP 342 (Tapscript). Together, these changes make complex Bitcoin transactions cheaper, more private, and more flexible.

Taproot's core insight is that most multi-party contracts resolve cooperatively. When all parties agree, a key path spend settles the transaction with a single Schnorr signature, indistinguishable from any other single-signature payment. Only when parties disagree does a script path reveal the minimum contract logic needed, with all unused branches hidden via a Merkle tree (MAST). This design gives developers a powerful primitive: build arbitrarily complex contracts on-chain while keeping the common case cheap and private.

For a deeper technical walkthrough of the cryptographic foundations, see our research article on Taproot and Schnorr signatures.

Taproot Spending Paths Compared

Every P2TR output can be spent two ways: a key path (single Schnorr signature) or a script path (reveal one Tapscript branch plus a Merkle proof). The following table compares P2TR against legacy output types on a per-input basis.

P2TR key path spending is the cheapest single-signature input type on Bitcoin: roughly 15% smaller than P2WPKH and 61% smaller than P2PKH. The savings come from Schnorr signatures being 64 bytes (vs ~72 for ECDSA) and the public key being embedded in the output rather than the input. You can examine these structures in detail with the transaction decoder.

MuSig2: Aggregated Multi-Signatures

BIP 327 defines MuSig2, a two-round multi-signature scheme that produces a single 64-byte Schnorr signature from n-of-n participants. On-chain, a MuSig2 spend is identical to a regular single-signer key path spend. No observer can determine how many parties were involved.

MuSig2 has reached production maturity. The libsecp256k1 C library includes a merged MuSig2 module, and Bitcoin Core has begun integrating MuSig2 descriptor support via BIP 390. Hardware wallet support arrived with Ledger's Bitcoin app v2.4.0 in April 2025. Lightning Loop already uses MuSig2 for its cooperative spending paths.

The practical impact is dramatic for organizations that require multi-party authorization. A 2-of-3 corporate treasury using legacy P2SH multisig publishes all three public keys and two signatures on-chain at ~296 vB per input. The same 2-of-3 setup using MuSig2 key aggregation with a P2TR key path costs ~57.5 vB per input: an 81% reduction in on-chain footprint, with zero information leaked about the signing quorum.

Note: MuSig2 is an n-of-n scheme. For t-of-n threshold setups (like 2-of-3), MuSig2 alone is insufficient. You need either FROST or a Taproot script tree with multiple MuSig2 leaves.

FROST Threshold Signatures

FROST (Flexible Round-Optimized Schnorr Threshold) extends Schnorr aggregation to arbitrary t-of-n thresholds. A 3-of-5 FROST signing group produces a single standard Schnorr signature: same 64 bytes, same key path spend, completely indistinguishable from a solo signer on-chain.

FROST is standardized as IETF RFC 9591 and has a Bitcoin-specific draft in BIP 445 (assigned January 2026). Reference implementations exist from the Zcash Foundation (Rust) and Blockchain Commons. Frostsnap is building dedicated signing devices for k-of-n threshold custody. BIP 445 remains in draft status, and no major wallet ships FROST signing in production yet, but the cryptographic foundations are considered mature.

For a deeper look at how FROST compares to Shamir's Secret Sharing and legacy threshold signature approaches, see our research on FROST threshold signatures.

Discreet Log Contracts

Discreet Log Contracts (DLCs) enable conditional payments based on oracle-attested outcomes: derivatives, insurance, prediction markets, and more. Taproot significantly improves DLCs in three ways.

First, the funding output of a DLC is a standard P2TR output, indistinguishable from any other Taproot transaction. Before Taproot, DLC funding transactions used P2WSH outputs that could be identified as multi-party contracts by chain analysis.

Second, cooperative resolution (the common case where both parties agree on the outcome) uses a key path spend with a single MuSig2 signature. This is the cheapest and most private settlement possible.

Third, when disputes arise and oracle attestation is needed, MAST ensures only the specific outcome branch is revealed. A contract with hundreds of possible outcomes only publishes one script leaf plus a compact Merkle proof, hiding all other contract terms.

Active DLC projects include DLC.Link (trustless Bitcoin bridges using DLCs), Lygos Finance (non-custodial bitcoin-backed lending, which acquired Atomic Finance's DLC technology in 2025), and LN Markets (derivatives trading). The earlier project 10101 wound down operations in November 2024.

Lightning Network Improvements

Taproot enables "simple taproot channels" where the funding output is a MuSig2-aggregated P2TR key. When a Lightning channel is opened or cooperatively closed, it looks identical to a regular single-sig transaction. This is a substantial privacy improvement: before Taproot, channel opens were identifiable as 2-of-2 P2WSH multisig outputs, allowing chain analysis firms to map the Lightning Network topology.

LND has shipped simple taproot channels in production (available experimentally since v0.17.0-beta in October 2023, with RBF cooperative close and MuSig2 support added in later releases). Eclair merged support including dual funding and splicing in taproot channels. CLN and LDK have implementations in progress.

PTLCs: Decorrelated Payment Routing

Point Time-Locked Contracts (PTLCs) replace HTLCs as the routing primitive for Lightning payments. Where HTLCs use hash preimages (the same hash value at every hop, creating a correlation vector), PTLCs use Schnorr adaptor signatures with a unique elliptic curve point at each hop. No single value links the hops together.

The privacy improvement is significant. With HTLCs, two colluding nodes on the same payment route can identify they are routing the same payment by comparing hash values, enabling the "wormhole attack" where intermediate routing fees are stolen. PTLCs eliminate this correlation entirely. Each routing node sees a cryptographically independent point.

PTLCs are not yet deployed in production on any major Lightning implementation. The current development priority is stabilizing simple taproot channels first. PTLC support requires all nodes along a payment route to support the protocol, making it a network-wide upgrade rather than a unilateral improvement. For more technical detail, see our research on PTLCs as the next evolution of Lightning.

MAST: Script Privacy Through Merkle Trees

Merkelized Alternative Script Trees (MAST) encode multiple spending conditions into a Merkle tree whose root is tweaked into the P2TR public key. When spending via key path, no script conditions are revealed at all. When spending via script path, only the executed branch and its Merkle proof are published on-chain.

Consider a vault contract with four spending conditions: immediate spend by the owner, a 2-of-3 recovery key, a timelock after 6 months, and an emergency freeze by a designated guardian. Pre-Taproot, spending through any of these paths would reveal the entire script, exposing all four conditions regardless of which one was used. With MAST, spending through the owner's key path reveals nothing. Even spending through the recovery path only reveals that one branch plus two 32-byte hashes for the Merkle proof.

The savings scale with script complexity. A script tree with 8 branches requires only the executed branch plus 3 Merkle hashes (96 bytes of proof data) instead of publishing all 8 branches. For contracts like DLCs with hundreds of outcome branches, MAST reduces the on-chain footprint by orders of magnitude while keeping all unused terms private.

Developers working with Miniscript can compile complex spending policies into optimized Taproot script trees automatically. The compiler determines the optimal arrangement of branches to minimize expected spending cost based on probability-weighted usage patterns.

Ordinals and Inscriptions

Taproot's removal of the previous ~10,000-byte witness script size limit, combined with the SegWit witness discount (witness data costs one-quarter the fee rate of non-witness data), enabled Ordinals inscriptions. The commit/reveal mechanism stores arbitrary data (images, text, code) in Taproot script-path witnesses.

Ordinals drove Taproot adoption from under 1% of transactions in early 2023 to a peak of 75.77% on May 7, 2023. As inscription activity subsided, Taproot usage settled to roughly 15-20% of transactions through 2025 and into 2026. While inscriptions remain controversial among some Bitcoin developers, they demonstrated the raw flexibility of Taproot's script-path spending and generated significant miner fee revenue.

Building on Taproot Today

For developers, Taproot support is available across the major Bitcoin libraries. The BIP 86 derivation path (m/86'/0'/0') provides standard key-path-only wallets. For MuSig2, BIP 327 is the reference specification. PSBTs support MuSig2 fields via BIP 373. Tapscript-based contracts can be constructed using Miniscript policy compilers.

Layer 2 protocols built on Bitcoin benefit directly from Taproot's privacy and efficiency gains. Spark, for example, leverages Taproot-era primitives to provide fast, low-cost Bitcoin and stablecoin transfers. As MuSig2 and FROST mature further, expect more sophisticated multi-party protocols to emerge on Bitcoin without the on-chain bloat that previously made them impractical.

Frequently Asked Questions

What are the main use cases for Bitcoin Taproot?

Taproot's primary use cases are cheaper single-signature transactions (key path spending at ~57.5 vB per input), private multi-party contracts (MuSig2 and FROST produce indistinguishable single signatures), improved Lightning Network channels (taproot channels hide channel opens/closes), DLCs with hidden contract terms via MAST, and data inscriptions (Ordinals). The common thread is that Taproot makes the cooperative case cheap and private while keeping complex fallback logic available when needed.

How does Schnorr improve Bitcoin multisig?

Schnorr signatures enable key aggregation through schemes like MuSig2 (n-of-n) and FROST (t-of-n). Multiple signers combine their keys and signatures into a single 64-byte Schnorr signature and single public key. On-chain, this is identical to a single-signer transaction: no observer can determine the number of participants. A 2-of-3 multisig that previously cost ~296 vB with legacy P2SH now costs ~57.5 vB via FROST, an 81% size reduction with complete privacy of the signing structure.

What is the difference between MuSig2 and FROST?

MuSig2 (BIP 327) is an n-of-n scheme: all participants must sign. FROST is a t-of-n threshold scheme: any t participants from a group of n can produce a valid signature. Both output a standard Schnorr signature. MuSig2 is more mature (merged into libsecp256k1, hardware wallet support shipping) while FROST is still in draft (BIP 445) with reference implementations available but no production wallet integration yet.

How does Taproot improve Lightning Network privacy?

Before Taproot, Lightning channel opens were 2-of-2 P2WSH multisig outputs, easily identified by chain analysis. Taproot channels use MuSig2 key aggregation so the funding output is a standard P2TR output, indistinguishable from regular payments. Cooperative closes are also single-signature key path spends. Future PTLC adoption will further improve routing privacy by eliminating hash correlation between payment hops.

Are PTLCs available on the Lightning Network today?

No. PTLCs are not deployed in production on any major Lightning implementation as of 2026. The current development focus is on simple taproot channels (LND has shipped this; Eclair, CLN, and LDK are in progress). PTLCs require network-wide support since all nodes along a payment route must understand the protocol. Deployment depends on taproot channel adoption reaching critical mass first.

What is MAST and how does it hide Bitcoin script conditions?

MAST (Merkelized Alternative Script Trees) organizes multiple spending conditions into a Merkle tree. The tree root is cryptographically committed to the Taproot public key. When spending, only the executed script branch and its Merkle proof are published on-chain. All other branches remain hidden. For key path spends, no script conditions are revealed at all. This means complex contracts (vaults, DLCs, timelocked recovery) leave minimal on-chain footprint regardless of how many conditions they contain.

What percentage of Bitcoin transactions use Taproot?

Taproot usage peaked at 75.77% of daily transactions on May 7, 2023, driven by the Ordinals inscription wave. After inscription activity subsided, adoption settled to roughly 15-20% through 2025 and into 2026. The percentage fluctuates with inscription cycles and wallet adoption. Key path spends account for the majority of Taproot transactions under normal conditions, with script path spends spiking during periods of heavy inscription activity.

This tool is for informational purposes only and does not constitute financial advice. Technical specifications and adoption data are based on publicly available information and BIP documentation. Implementation status changes frequently. Always verify current capabilities against the relevant BIP specifications and software release notes before building production systems.