Key Path Spend

What Is a Key Path Spend?

A key path spend is the simplest way to spend a Taproot output. Every P2TR output encodes two possible spending paths: the key path (a direct signature against the output's public key) and the script path (revealing and satisfying a script from a hidden Merkle tree of conditions). The key path spend uses only a single Schnorr signature to authorize the transaction, making it the cheapest and most private option available.

Introduced as part of the Taproot upgrade (BIP 341) that activated on Bitcoin in November 2021, key path spending was designed to be the common case. The idea is straightforward: if all parties to a transaction agree, they can simply sign together and spend the output without revealing that any alternative conditions existed. The script path serves only as a fallback when cooperative spending is not possible.

How It Works

To understand key path spending, it helps to know how a Taproot output is constructed. A P2TR output commits to an output key Q, which is derived from two components:

1. An internal key P: the public key that can authorize a key path spend
2. An optional script tree: a Merkle tree of spending scripts (the "taptree") that provides fallback spending conditions

The output key Q is computed by tweaking the internal key P with the Merkle root of the script tree. If there is no script tree, the tweak uses an empty value. This construction is what allows a single output to support both spending paths without revealing which one is available.

Key Path Witness Structure

According to BIP 341, when exactly one element remains in the witness stack (after removing any annex), the spend is treated as a key path spend. That single element is the Schnorr signature, validated against the output key Q using BIP 340 verification rules:

# Key path spend witness (single element)
Witness:
  [64-byte Schnorr signature]   # SIGHASH_DEFAULT (0x00)
  or
  [65-byte Schnorr signature]   # explicit sighash type in final byte

The total witness data for a key path spend breaks down as follows:

No public key appears in the witness because it is already encoded in the output's scriptPubKey (the witness program). This is a notable difference from P2WPKH, which includes both a signature and a compressed public key in its witness.

Script Path Comparison

A script path spend, by contrast, must include the script being executed, a control block containing the internal key and Merkle proof, and whatever data satisfies the script. Even the simplest single-signature script path spend weighs approximately 167 WU (41.75 vB) in the witness: more than 2.5 times the key path cost. This is why the key path is always preferred when cooperative signing is possible.

Key Path vs. Other Spend Types

The efficiency of key path spending becomes clear when compared to other Bitcoin output types. Because Taproot uses Schnorr signatures (always exactly 64 bytes) instead of variable-length ECDSA signatures (71 to 73 bytes) and eliminates the public key from the witness, key path spends produce the smallest inputs of any standard transaction type.

A P2TR key path spend saves approximately 15% per input compared to P2WPKH and 61% compared to legacy P2PKH. For transactions with many inputs (such as UTXO consolidation), these savings add up significantly.

Multi-Party Key Path Spends

One of the most powerful features of key path spending is that multiple parties can cooperate to produce a single Schnorr signature. Because Schnorr signatures are linearly aggregatable, protocols like MuSig2 and FROST can combine partial signatures from multiple signers into one standard 64-byte signature. The resulting on-chain transaction is completely indistinguishable from a solo wallet spend.

MuSig2 (n-of-n)

MuSig2 (BIP 327) is a two-round multi-signature protocol for n-of-n signing. All participants must cooperate to produce the signature. The process works as follows:

1. Key aggregation: each signer's public key is combined into a single aggregate public key, which becomes the Taproot internal key
2. Nonce exchange (round 1): each signer generates and shares cryptographic nonces
3. Partial signing (round 2): each signer produces a partial signature using their private key share and the aggregated nonce
4. Aggregation: partial signatures are combined into a single 64-byte Schnorr signature

The result on chain: one 32-byte public key in the output and one 64-byte signature in the witness. A 10-party MuSig2 spend occupies the same 57.5 vB input as a single-signer key path spend. For more details, see the MuSig2 deep dive.

FROST (t-of-n)

FROST (Flexible Round-Optimized Schnorr Threshold signatures) extends key path spending to threshold setups where only t out of n signers need to participate. This provides fault tolerance: if some signers are offline, the remaining participants above the threshold can still produce a valid signature.

FROST was standardized in RFC 9591 (June 2024), and a Bitcoin-specific variant (FROST3) is specified in the draft BIP 445 for compatibility with BIP 340 signatures. The signing process uses a distributed key generation phase so that no single party ever holds the complete private key, followed by a threshold signing round that produces a standard Schnorr signature.

The efficiency gain is dramatic for multisig setups. A traditional P2WSH 2-of-3 multisig input costs approximately 104.75 vB. The equivalent FROST key path spend costs 57.5 vB: a roughly 45% reduction. For a 5-of-7 setup, the savings are even greater because the P2WSH input would be approximately 450 vB while the FROST spend remains at 57.5 vB. See the FROST deep dive for a full explanation of the protocol.

Privacy Benefits

Key path spending delivers a significant privacy improvement over previous Bitcoin output types. When a Taproot output is spent via the key path, the transaction reveals nothing beyond the signature itself:

• No script conditions are exposed: observers cannot tell whether a script tree existed at all
• Spending policies are hidden: a 3-of-5 FROST spend looks identical to a single-key wallet spend
• All key path spends are uniform: regardless of wallet software, custody arrangement, or signing protocol, every key path transaction has the same on-chain fingerprint

This uniformity makes chain analysis significantly harder. With previous output types, the script itself revealed information about the spending policy (P2SH exposed the redeem script, P2WSH exposed the witness script). Key path spending eliminates this information leak entirely. For a broader look at how Taproot improves Bitcoin transactions, see Taproot and Schnorr Signatures Explained.

Use Cases

Single-Signature Wallets

The most common use case is everyday wallet spending. Modern wallets that support Taproot (Bitcoin Core, Sparrow, hardware wallets like Ledger and Trezor) default to key path spending for standard transactions. Users get smaller transactions and lower fees automatically.

Collaborative Custody

Businesses and institutions can use MuSig2 or FROST to set up multi-party custody where the cooperative spending path (key path) is used for routine operations. The script path can encode fallback conditions such as timelocked recovery or emergency keys, but these are never revealed during normal operation.

Layer 2 Protocols

Layer 2 systems like the Lightning Network and Spark benefit from key path spending. When channel participants cooperate to close a channel, they can use a key path spend via MuSig2 to produce a transaction that looks like a regular single-signature payment. This hides the fact that a channel existed at all, improving both privacy and efficiency.

UTXO Consolidation

Because key path spends produce the smallest possible inputs, they are ideal for UTXO consolidation during low-fee periods. The 15% per-input savings over P2WPKH translates to meaningful fee reductions when consolidating dozens or hundreds of UTXOs.

Adoption and Wallet Support

As of mid-2026, Taproot transactions account for roughly 15 to 20% of Bitcoin network transactions. Key path spending is supported by all major wallet software and hardware devices, though major exchanges still commonly default to SegWit v0 deposit addresses.

MuSig2 hardware support is emerging: Ledger shipped MuSig2 signing in their Bitcoin app v2.4.0 (April 2025), and Nunchuk launched a Taproot MuSig2 multisig wallet in beta. FROST wallet integration remains in the standardization phase, with BIP 445 still in draft status.

Risks and Considerations

Key Path Only Works with Cooperation

Key path spending requires all relevant parties to be available and willing to sign. In a MuSig2 setup, if even one signer is offline or uncooperative, the key path cannot be used. This is why Taproot outputs typically include a script tree as a fallback: the script path can encode alternative conditions (such as timelocked recovery) for non-cooperative scenarios.

Output Size Tradeoff

While P2TR inputs are smaller than any other type, P2TR outputs are slightly larger than P2WPKH outputs (43 bytes vs 31 bytes). For transactions with few inputs and many outputs, this can offset the input savings. The net benefit depends on the transaction shape, but for most real-world spending patterns, the input savings dominate.

Nonce Management in Multi-Party Signing

Both MuSig2 and FROST require careful nonce management. Reusing nonces or mishandling the nonce exchange can lead to private key exposure. Hardware wallets and signing libraries must implement robust deterministic nonce generation or secure random number generation to prevent nonce reuse attacks.

Standardization Is Ongoing

While MuSig2 (BIP 327) is well-established, FROST integration with Bitcoin (BIP 445) is still in draft. Developers building on FROST should track the specification closely, as details may change before finalization.

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.