Taproot Multisig Fee Calculator: MuSig2 vs Legacy Costs

Taproot MuSig2 Multisig Fee Savings

Taproot combined with MuSig2 key aggregation makes multisig transactions indistinguishable from single-signature spends on the Bitcoin blockchain. A key-path spend using MuSig2 produces a single 64-byte Schnorr signature regardless of how many cosigners participated, collapsing a 2-of-3, 3-of-5, or even 5-of-7 policy into an input of just 57.5 virtual bytes.

Legacy multisig formats scale linearly with the number of signatures and public keys in the spending script. A P2SH 5-of-7 input costs 652 vB while the equivalent MuSig2 key-path input costs 57.5 vB: a 91% reduction. The table below compares complete transaction sizes for a standard 1-input, 2-output transaction across the three major address types.

The MuSig2 column is constant at 154 vB because the on-chain footprint never changes: one Schnorr signature, one x-only public key, regardless of the threshold policy. Legacy formats grow with every additional signature and public key pushed to the blockchain. For single-signature Taproot savings, see the Taproot fee savings calculator.

Input Size Breakdown by Address Type

Transaction fees are dominated by input costs. The input contains the authorization proof: signatures, public keys, and any redeem or witness script. The following table isolates input sizes to show exactly where MuSig2 saves bytes.

P2SH inputs are the most expensive because every byte of the redeem script and all signatures sit in the scriptSig with no witness discount. P2WSH moves the signatures and witness script into the witness, where each byte counts as only 0.25 vB instead of 1 vB. MuSig2 eliminates the scaling problem entirely: the aggregated signature is always 64 bytes in the witness plus 41 bytes of non-witness input data, yielding 57.5 vB regardless of the number of cosigners.

For a complete breakdown of input and output sizes across all Bitcoin script types, see the transaction size reference.

Fee Calculation at Common Fee Rates

The formula for calculating a multisig transaction fee is straightforward: fee (sats) = transaction size (vB) × fee rate (sat/vB). To convert to USD, multiply by the current BTC price and divide by 100,000,000. The table below shows fees for a standard 1-input, 2-output transaction at three representative fee rates.

During high-fee periods, a 5-of-7 P2SH multisig spend at 100 sat/vB costs 74,800 sats. The same spend via MuSig2 costs just 15,400 sats: a saving of 59,400 sats per transaction. For organizations that execute dozens of multisig transactions per week, the annual savings can be significant. Check current fee market conditions with the fee estimator.

Key-Path vs Script-Path Spending

A P2TR output commits to both an internal public key (for key-path spending) and an optional Taproot tree of scripts (for script-path spending). For multisig setups, this creates a two-tier fee structure depending on how many signers cooperate.

Key-path spending is the optimal case. All participants run the MuSig2 protocol off-chain to produce a single aggregated Schnorr signature. On-chain, the transaction looks exactly like a single-signature P2TR spend at 57.5 vB per input. No script is revealed, no public keys are exposed beyond the output's x-only key, and no observer can determine that the output was controlled by multiple parties. This is the scenario reflected in the tables above.

Script-path spending is the fallback when not all signers are available. For a 2-of-3 policy, the Taproot tree typically contains three leaves, each holding a MuSig2 aggregate key for one of the three possible 2-of-2 signer combinations. Any two cooperating signers select their leaf, produce an aggregated signature, and reveal the script plus a Merkle proof (the control block) to the chain. This script-path spend costs roughly 83 vB per input for a 2-of-3 at tree depth 1: larger than key-path but still cheaper than P2WSH at 105 vB.

For higher thresholds, the Taproot tree grows combinatorially. A 3-of-5 requires C(5,3) = 10 leaves, and a 5-of-7 requires C(7,5) = 21 leaves. Deeper trees mean larger control blocks (each tree level adds 32 bytes to the Merkle proof). At these scales, FROST threshold signatures become attractive because FROST produces a key-path-eligible aggregated signature requiring only the threshold number of signers, avoiding the tree entirely. For a deep dive into both protocols, see MuSig2 multisignatures explained.

How MuSig2 Key Aggregation Reduces On-Chain Cost

BIP-327 defines the MuSig2 protocol: a two-round multi-signature scheme that leverages the linearity of Schnorr signatures. The process works as follows:

1. Each signer generates a key pair. Their individual public keys are combined into a single aggregated public key using a deterministic algorithm. This aggregated key becomes the internal key of the Taproot output.
2. When spending, each signer produces a nonce commitment (round 1) and then a partial signature (round 2). These partial signatures are combined into a single valid Schnorr signature for the aggregated key.
3. The final transaction contains one 64-byte signature in the witness, identical in structure to a single-signer P2TR spend. Validators verify it against the output's x-only public key with no knowledge of the underlying multi-party setup.

This stands in stark contrast to legacy OP_CHECKMULTISIG, which pushes m full signatures and n public keys directly into the transaction. A P2SH 3-of-5 must include three 72-byte ECDSA signatures, five 33-byte compressed public keys, and the full redeem script (173 bytes): all counted at full weight in the non-witness scriptSig. MuSig2 replaces all of this with a single 64-byte signature in the discounted witness.

Tapscript (activated by BIP-342) also introduced OP_CHECKSIGADD as a more efficient replacement for OP_CHECKMULTISIG in script-path spending. OP_CHECKSIGADD eliminates the off-by-one dummy element that OP_CHECKMULTISIG requires and counts each signature validation as exactly one sigop. However, even OP_CHECKSIGADD script-path spends are larger than MuSig2 key-path spends because they still push individual signatures to the chain.

Why the Witness Discount Matters for Multisig

The witness discount, introduced by SegWit, counts witness bytes at one-quarter the weight of non-witness bytes. This discount was specifically designed to reduce the cost of signature data, which is the largest component of transaction inputs.

For multisig transactions, the discount has an outsized effect. Consider a P2WSH 2-of-3 input: the 41 non-witness bytes (outpoint, empty scriptSig, sequence) contribute 164 weight units, while the 254 witness bytes (signatures and witness script) contribute only 254 WU. Total weight: 418 WU, or about 105 vB. Without the discount, the same input would cost 295 vB.

P2SH multisig receives no witness discount at all because the entire scriptSig sits in non-witness space. This is why the gap between P2SH and P2WSH widens as the multisig complexity grows: more signatures mean more bytes that could benefit from the discount but don't. Migrating from P2SH 5-of-7 (652 vB per input) to P2WSH 5-of-7 (193 vB) saves 70% before even considering MuSig2.

How to Calculate Your Multisig Transaction Fee

To estimate the fee for your specific multisig transaction, follow these steps:

1. Determine your input size from the input table above based on your address type and multisig configuration. If you have multiple inputs, multiply by the number of UTXOs being spent.
2. Add the output sizes. Each P2TR output is 43 bytes. Each P2WPKH output is 31 bytes. Each P2SH output is 32 bytes.
3. Add the transaction overhead: 10 bytes for non-SegWit (P2SH) or 10.5 vB for SegWit transactions (P2WSH, P2TR).
4. Multiply total vBytes by the current fee rate in sat/vB.

For example, a 3-of-5 P2WSH multisig spending 3 inputs to 2 P2TR outputs: (3 × 140) + (2 × 43) + 10.5 = 516.5 vB. At 50 sat/vB, the fee is 516.5 × 50 = 25,825 sats. The same transaction using MuSig2 key-path: (3 × 57.5) + (2 × 43) + 10.5 = 269 vB, costing just 269 × 50 = 13,450 sats: a saving of 12,375 sats.

For organizations running multisig treasuries with frequent transactions, these savings compound. Users seeking to avoid on-chain fees entirely for day-to-day payments can move funds to a layer 2 like Spark, which settles transactions off-chain while inheriting Bitcoin's security model. For hardware, software, and service costs of running a multisig setup, see the multisig cost calculator.

Frequently Asked Questions

How much does a Taproot multisig transaction cost?

A Taproot multisig transaction using MuSig2 key-path spending costs the same as a single-signature P2TR transaction: approximately 154 vB for a standard 1-input, 2-output transaction. At 50 sat/vB, that is 7,700 sats. This is the same regardless of whether the underlying policy is 2-of-3, 3-of-5, or 5-of-7, because MuSig2 aggregates all partial signatures into a single 64-byte Schnorr signature before broadcasting.

Is MuSig2 the same as traditional multisig?

No. Traditional multisig using OP_CHECKMULTISIG pushes every individual signature and public key on-chain. MuSig2 is an n-of-n multi-signature protocol defined in BIP-327 that produces a single aggregated signature off-chain. On-chain, the spend is indistinguishable from a single-signer transaction. For threshold policies (m-of-n where m < n), MuSig2 is typically combined with a Taproot script tree of signer sub-combinations, or replaced by FROST which natively supports threshold signing.

What is the difference between key-path and script-path spending?

Key-path spending uses the Taproot output's internal key directly, requiring a single Schnorr signature (57.5 vB per input). It is used when all participants cooperate via MuSig2. Script-path spending reveals a script from the Taproot tree plus a control block containing the Merkle proof, used as a fallback when not all signers are available. Script-path inputs are larger (roughly 83 to 140 vB depending on tree depth and script complexity) but still typically cheaper than legacy P2WSH multisig.

Which wallets support MuSig2 Taproot multisig?

MuSig2 adoption is accelerating. The libsecp256k1 library shipped a production MuSig2 module in v0.6.0 (November 2024). BitGo offers MuSig2 Taproot hot wallets for institutional clients, reporting approximately 30% fee reduction versus native SegWit. Ledger added MuSig2 signing in Bitcoin app v2.4.0 (April 2025). Nunchuk launched Taproot MuSig2 multisig support (up to 5 keys) in beta. LND graduated Simple Taproot Channels with MuSig2 to production in v0.21. Most desktop wallets still default to P2WSH for multisig, but the tooling gap is closing rapidly. Check the multisig setup comparison for current wallet support.

Does MuSig2 work for 2-of-3 multisig?

MuSig2 is strictly an n-of-n scheme: all participants must sign. For a 2-of-3 threshold policy, the standard approach is to construct a Taproot output with a 3-of-3 MuSig2 internal key (for the cooperative key-path) and a script tree containing three leaves, one for each possible 2-of-2 MuSig2 combination (keys 1+2, keys 1+3, keys 2+3). If all three signers cooperate, the key-path spend costs 57.5 vB. If only two are available, the script-path spend costs roughly 83 vB. Both are cheaper than the P2WSH 2-of-3 alternative at 105 vB.

How does Taproot reduce multisig fees compared to SegWit?

SegWit (P2WSH) already provides major savings over legacy P2SH by moving signatures into the discounted witness. Taproot adds two further optimizations: Schnorr signatures are 64 bytes instead of approximately 72 bytes for ECDSA, and MuSig2 key aggregation replaces multiple signatures with one. For a 5-of-7 multisig, P2WSH needs five 72-byte ECDSA signatures plus the full witness script (193 vB per input). MuSig2 key-path needs one 64-byte Schnorr signature (57.5 vB per input): a 70% reduction over SegWit and 91% over legacy P2SH.

This tool is for informational purposes only and does not constitute financial advice. Transaction sizes are calculated using worst-case 72-byte ECDSA signature estimates for P2SH and P2WSH. Actual sizes may vary by 1 to 3 vB depending on DER encoding. Fee rates fluctuate with network demand. Always verify current fee conditions before broadcasting transactions.