Tools/Explorers

Bitcoin Taproot Fee Savings Calculator: P2TR vs Legacy Costs

Calculate how much you save on Bitcoin fees with Taproot P2TR addresses vs Legacy P2PKH and SegWit. Compare vByte sizes for single-sig and multisig transactions.

Spark TeamInvalid Date

How Much Does Taproot Save on Bitcoin Fees?

Taproot (P2TR) was activated on Bitcoin in November 2021 and introduced Schnorr signatures, which are 64 bytes compared to the ~72-byte DER-encoded ECDSA signatures used by older address types. This makes P2TR inputs the cheapest to spend of any Bitcoin script type at 57.5 virtual bytes per single-sig input. However, P2TR outputs are larger (43 bytes vs 31 bytes for P2WPKH), which means the overall fee savings depend on your transaction shape: how many inputs you spend relative to how many outputs you create.

The table below compares total transaction sizes for the four major address types across common transaction templates. All values assume single-signature key-path spending and same-type outputs.

Transaction ShapeP2PKH (Legacy)P2SH-P2WPKH (Nested)P2WPKH (Native SegWit)P2TR (Taproot)
1-in / 2-out226 vB167 vB141 vB154 vB
2-in / 2-out374 vB257 vB209 vB212 vB
5-in / 2-out818 vB530 vB413 vB384 vB
10-in / 1-out (consolidation)1,524 vB953 vB722 vB629 vB

Notice that for a simple 1-input, 2-output payment, P2WPKH is actually 13 vB smaller than P2TR. The crossover point is roughly 3 inputs: once a transaction spends 3 or more UTXOs, P2TR becomes the cheapest format overall. For input-heavy operations like UTXO consolidation, Taproot saves approximately 13% over Native SegWit and 59% over Legacy. To estimate fees for your specific transaction, use the fee estimator tool.

Input and Output Size Breakdown

The fee difference between address types comes from two components: input size (how much data is required to prove you can spend a UTXO) and output size (how much data defines the spending condition). The witness discount introduced by SegWit counts witness data at 0.25 weight units per byte instead of 1, which is why SegWit and Taproot inputs are dramatically cheaper despite containing similar raw byte counts.

ComponentP2PKHP2SH-P2WPKHP2WPKHP2TR (key-path)
Input size (vB)148916857.5
Output size (bytes)34323143
Signature typeECDSA (~72 B)ECDSA (~72 B)ECDSA (~72 B)Schnorr (64 B)
Public key in witnessYes (33 B in scriptSig)Yes (33 B)Yes (33 B)No
Witness discount appliedNoPartialYesYes

P2TR key-path spends achieve their size advantage from two sources. First, the Schnorr signature is exactly 64 bytes with no variable-length DER encoding overhead. Second, the public key is not pushed in the witness because it is already committed in the output script as an x-only 32-byte key. These two savings combine to make P2TR inputs 10.5 vB smaller than P2WPKH inputs. For a deeper look at the byte-level structure, see the transaction size reference.

Why P2TR Outputs Are Larger

A common question is why Taproot transactions are sometimes more expensive for simple payments. The answer is output size. P2TR outputs use a 34-byte scriptPubKey containing a 32-byte x-only public key, while P2WPKH outputs use a 22-byte scriptPubKey containing a 20-byte hash. With the 8-byte value field and 1-byte script length, a P2TR output totals 43 bytes versus 31 bytes for P2WPKH.

Each P2TR output costs 12 bytes more than a P2WPKH output. In a transaction with 2 outputs, that adds 24 bytes. Since each P2TR input saves only 10.5 vB over P2WPKH, a 1-input transaction has a net cost increase of about 13.5 vB. The breakeven occurs at roughly 2.3 inputs: transactions with 3 or more inputs tip in Taproot's favor.

Percentage Savings Across Transaction Types

The following table shows how much each address type saves relative to Legacy P2PKH, and how P2TR compares specifically to P2WPKH. Negative values mean P2TR is larger.

Transaction ShapeP2SH-P2WPKH vs P2PKHP2WPKH vs P2PKHP2TR vs P2PKHP2TR vs P2WPKH
1-in / 2-out-26%-38%-32%+9%
2-in / 2-out-31%-44%-43%+1%
5-in / 2-out-35%-50%-53%-7%
10-in / 1-out-37%-53%-59%-13%

The pattern is clear: Taproot's savings grow with the number of inputs. For UTXO consolidation transactions (many inputs, one output), P2TR offers the lowest fees of any standard script type. For simple send-and-receive payments with few inputs, P2WPKH remains slightly cheaper. Both are dramatically cheaper than Legacy P2PKH, which should be avoided entirely for fee efficiency. For strategies on managing your UTXOs to minimize fees, see the UTXO management guide.

Multisig Fee Savings with Taproot

The most dramatic fee savings from Taproot come in multisig transactions. With MuSig2 or FROST, multiple signers aggregate their keys and signatures off-chain into a single Schnorr public key and a single 64-byte signature. On-chain, the result is indistinguishable from a single-sig key-path spend: 57.5 vB per input regardless of the number of signers.

2-of-3 Multisig (1-in / 2-out)Input Size (vB)Total Tx (vB)Savings vs P2SH
P2SH (OP_CHECKMULTISIG)~296~370Baseline
P2WSH (SegWit v0)~104~201~46%
P2TR script-path (2-of-3 leaf)~107.5~204~45%
P2TR MuSig2 key-path57.5154~58%

When all parties cooperate and sign with MuSig2, a 2-of-3 multisig transaction costs the same as a single-sig payment: 154 vB for a standard 1-in, 2-out transaction. This is a 58% reduction compared to legacy P2SH multisig and a 23% reduction compared to P2WSH. The savings scale with the number of signers: a 5-of-7 multisig that would cost over 500 vB per input with P2WSH collapses to the same 57.5 vB with MuSig2. For a detailed walkthrough of the signing protocol, see the MuSig2 explainer.

Key-Path vs Script-Path Spending

P2TR outputs support two spending paths. The key-path is the default: a single Schnorr signature against the tweaked public key, costing 57.5 vB per input. The script-path reveals a script from a Merkle tree of spending conditions (the taptree) and costs more because the witness must include the script, a control block, and the Merkle proof.

For a 2-of-3 multisig implemented as a taptree with three 2-of-2 leaves, the script-path input sizes vary by which leaf is used. According to analysis by Bitcoin developer Murch, the typical costs are approximately 82.75 vB for a leaf using a hot backup key and 107.5 vB for a non-interactive backup recovery leaf. These are still cheaper than legacy P2SH multisig (296 vB) but comparable to P2WSH (104 vB). The key takeaway: Taproot multisig saves the most when all parties cooperate and use the key-path. Script-path spending is the fallback for non-cooperative scenarios, not the primary spending mechanism. For a deeper dive into spend paths, see the P2TR spend path analysis.

Fee Impact at Different Fee Rates

The actual satoshi cost of a transaction depends on the current fee rate. The table below shows what you would pay for a 10-input consolidation transaction at various fee rates, demonstrating how Taproot's vByte savings translate to real cost reductions, especially during high-fee periods.

Fee Rate (sat/vB)P2PKH (1,524 vB)P2WPKH (722 vB)P2TR (629 vB)P2TR Savings vs P2PKH
5 sat/vB7,620 sats3,610 sats3,145 sats4,475 sats
20 sat/vB30,480 sats14,440 sats12,580 sats17,900 sats
50 sat/vB76,200 sats36,100 sats31,450 sats44,750 sats
100 sat/vB152,400 sats72,200 sats62,900 sats89,500 sats

At 100 sat/vB, a 10-input consolidation from P2PKH costs 152,400 sats while the same operation from P2TR costs 62,900 sats: a saving of nearly 90,000 sats. During fee spikes, the case for migrating to Taproot becomes especially compelling. You can check current fee rates and plan your consolidation timing using the fee estimator.

When to Use Taproot for Maximum Savings

Taproot delivers the largest fee reductions in specific scenarios. The following guidelines help you decide when switching to P2TR addresses has the most impact.

  • UTXO consolidation (many inputs, few outputs): P2TR saves 13% over P2WPKH and up to 59% over P2PKH per transaction
  • Multisig wallets using MuSig2 or FROST: key-path spends collapse any threshold scheme to single-sig cost, saving 23% over P2WSH and 58% over P2SH
  • High-throughput services processing batched payments with many inputs: every additional input saves 10.5 vB compared to P2WPKH
  • Lightning channel opens and closes: Taproot channels (simple taproot channels) reduce on-chain footprint for cooperative closes
  • Privacy-sensitive transactions: all P2TR outputs look identical regardless of the underlying spending conditions, improving fungibility

Taproot is less advantageous for simple one-input payments where P2WPKH is 9% smaller. If your wallet primarily sends single-UTXO payments with two outputs, the fee difference is negligible (13 vB). In practice, most wallets will encounter both scenarios, so defaulting to P2TR addresses provides the best average outcome over time. Layer 2 protocols like Spark move most transactions off-chain entirely, making the base-layer address type relevant primarily for channel management and settlement.

Taproot Adoption

As of mid-2026, Taproot transactions account for roughly 15 to 20% of Bitcoin network activity, down from a peak of approximately 42% in 2024 that was driven largely by Ordinals inscriptions. The current level reflects organic adoption from wallets, exchanges, and protocols. Major wallets including Bitcoin Core, Sparrow, BlueWallet, and hardware wallets from Trezor and Ledger now support P2TR addresses. Adoption is tracked in real time on the SegWit and Taproot adoption tracker.

Frequently Asked Questions

Is Taproot always cheaper than SegWit?

No. For simple single-input, two-output payments, native SegWit (P2WPKH) is about 9% cheaper than Taproot (P2TR) because P2WPKH outputs are 12 bytes smaller. Taproot becomes cheaper once you spend 3 or more inputs in the same transaction, because P2TR inputs are 10.5 vB smaller than P2WPKH inputs. For multisig using MuSig2, Taproot is always cheaper.

How much does Taproot save on multisig transactions?

With MuSig2 or FROST, a Taproot multisig key-path spend costs 57.5 vB per input regardless of the number of signers. This is 58% cheaper than legacy P2SH multisig (~296 vB per input) and 45% cheaper than P2WSH (~104 vB per input). The savings increase with larger signer sets because the on-chain cost remains constant.

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

Key-path spending uses a single Schnorr signature to spend a P2TR output, costing 57.5 vB per input. Script-path spending reveals a script from the taptree and costs more (82 to 108 vB depending on the script) because the witness must include the script, Merkle proof, and control block. Key-path is the cooperative default; script-path is the fallback when not all parties are available to sign.

Should I consolidate my UTXOs into Taproot addresses?

If you hold UTXOs in Legacy (P2PKH) addresses, consolidating to P2TR during low-fee periods can significantly reduce your future spending costs. A P2PKH input costs 148 vB to spend versus 57.5 vB for P2TR: a 61% reduction per input. Watch the mempool for periods below 5 sat/vB to minimize consolidation costs. Use the consolidation calculator to estimate the optimal timing.

Why are P2TR outputs 43 bytes instead of 31?

P2TR outputs use a 32-byte x-only public key directly in the scriptPubKey, while P2WPKH outputs use a 20-byte HASH160 (RIPEMD160 of SHA256) of the public key. The larger output commits to the full key rather than a hash, which enables key-path spending without revealing the public key separately. This tradeoff makes outputs 12 bytes larger but inputs 10.5 vB smaller, netting out favorably for input-heavy transactions.

How do Taproot fees compare when sending to different address types?

The input cost depends on the address type of the UTXO being spent, and the output cost depends on the recipient's address type. If you spend a P2TR input but send to a P2WPKH address (31-byte output), you get P2TR's input savings with P2WPKH's smaller output. This mixed scenario can be the cheapest option for simple payments. Use the transaction size reference to calculate exact sizes for mixed-type transactions.

Does Taproot improve privacy in addition to saving fees?

Yes. All P2TR outputs use the same 34-byte scriptPubKey format regardless of the underlying spending conditions. A single-sig output is indistinguishable from a 5-of-7 multisig or a complex timelock contract. This uniformity prevents chain analysis from inferring the spending policy by examining the output script, which improves fungibility across the network. Script details are only revealed when spent via the script-path.

This tool is for informational purposes only and does not constitute financial advice. Transaction sizes are calculated from standard Bitcoin script templates using the Bitcoin Optech transaction size calculator methodology. Actual sizes may vary slightly due to signature length variability in ECDSA (which uses variable-length DER encoding). Always verify current fee rates before broadcasting transactions.

Build with Spark

Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.

Read the docs →