Bitcoin Batch Payment Solutions Compared

Batch Payment Methods Overview

Bitcoin batch payments consolidate multiple outgoing payments into fewer on-chain transactions, reducing the total transaction fees paid. A standard single-recipient P2WPKH transaction costs roughly 141 virtual bytes. Each additional output in a batched transaction adds only 31 vB: the fixed overhead of inputs, version fields, and the segwit marker is paid once instead of per payment.

The savings are significant. Ten individual payments consume roughly 1,405 vB total. The same ten payments batched into a single transaction with one input require approximately 420 vB: a 70% reduction in block space. At 50 sat/vB, that translates to roughly 49,000 sats saved per batch.

Four distinct approaches to batching exist across the Bitcoin ecosystem, each with different tradeoffs in fee savings, confirmation speed, privacy, and implementation complexity. The following table provides a high-level comparison.

Use the batch savings calculator to estimate your specific savings based on payment count and current fee rates.

Native Transaction Batching

Native batching is the most straightforward approach: a sender constructs a single Bitcoin transaction with multiple outputs, one per recipient. This technique exploits the fact that a transaction's fixed costs (the 10.5 vB overhead, each 68 vB SegWit input, and the change output) are amortized across all recipients.

The per-payment cost in a batch asymptotically approaches the size of a single output: 31 vB for P2WPKH or 43 vB for P2TR (Taproot). Compare that to the roughly 141 vB cost of an individual P2WPKH transaction with one input and two outputs (payment plus change). At five recipients, the effective cost per payment drops to approximately 53 vB: a 62% savings per payment.

Wallet and service support

Several wallets and services support native batching directly:

• Bitcoin Core: the sendmany RPC command constructs multi-output transactions natively
• Sparrow Wallet: "Send To Many" tool with CSV import for bulk payouts
• Electrum: "Pay to many" feature under Tools, also supporting CSV import
• BlueWallet: built-in "Send to many" batching feature
• Bull Bitcoin Batcher: open-source tool that accumulates payments and broadcasts batches every 60 minutes or when the batch reaches 1 BTC

For services managing UTXOs at scale, combining batching with coin control and periodic UTXO consolidation maximizes long-term fee efficiency. The fee estimator can help time consolidation during low-fee periods.

Exchange Batch Withdrawals

Major exchanges batch customer withdrawal requests automatically, combining hundreds or thousands of individual withdrawals into a few large transactions per hour. Users experience a short delay between requesting a withdrawal and seeing it broadcast, but pay lower fees (or no on-chain fee at all, depending on the exchange's pricing model).

Coinbase launched batching in March 2020 and reported a 75.2% reduction in customer transaction fees. Their system also reduced the exchange's daily transaction count by approximately 95%, meaningfully reducing congestion on the Bitcoin network. Coinbase batches at least once per minute, so withdrawal delays are typically short.

Strike uses a more advanced approach: Replace-By-Fee (RBF) to append new outputs to unconfirmed batch transactions. When a new withdrawal request arrives, Strike can fee-bump an existing unconfirmed transaction and add the new recipient as an additional output, achieving 30-50% cost savings per payment. Their tiered service offers faster settlement for paid plans.

Binance and Kraken also batch withdrawals at regular intervals, though neither exchange publicly documents their exact batching schedule. Typical withdrawal processing times at these exchanges range from 15 to 40 minutes.

BTCPay Server Payout Processors

BTCPay Server introduced payout processors in version 1.5.0, giving merchants and businesses a self-hosted batching solution. The system queues approved payouts and processes them on a configurable schedule: hourly, daily, weekly, or at custom intervals.

Three processor types are available:

• Automated processor: runs at set intervals and processes as many queued payouts as the wallet balance allows
• PayJoin processor: combines scheduled payouts with incoming PayJoin transactions, improving privacy while batching
• Manual processor: allows operators to review and approve batches before broadcast

BTCPay's payout system integrates with its pull payment feature, making it useful for recurring payroll, affiliate payouts, and refund processing. The same system supports BOLT11 invoices, Lightning addresses, and LNURL for off-chain batch payouts. For more on payment processor options, see the payment gateway comparison.

Lightning Multi-Path Payments

Multi-path payments (MPP) on the Lightning Network take a fundamentally different approach to the batching problem. Instead of combining multiple payments into one on-chain transaction, MPP splits a single payment across multiple channels simultaneously. This enables payments larger than any single channel's capacity and often finds cheaper routing paths by distributing volume across the network.

All parts of an MPP share the same payment hash and settle atomically: the receiver holds the first HTLC and waits (up to 60 seconds) for all remaining parts before releasing the preimage. Either the entire payment succeeds or none of it does.

MPP is now standard across all major Lightning implementations. LND added sending support in v0.10.0 (May 2020), Eclair in v0.3.3 (February 2020), Core Lightning in July 2020, and LDK in April 2020. End-user wallets built on these libraries (Phoenix, Zeus, Breez) inherit MPP support automatically.

For high-volume Lightning senders, MPP reduces the need for large individual channels and makes inbound liquidity constraints less binding. It also enables more efficient use of routing fees by finding lower-cost paths that might not have sufficient capacity for the full payment amount.

Fee Savings Comparison

The following table shows concrete fee savings for native on-chain batching at different batch sizes, assuming P2WPKH inputs and outputs. All sizes are calculated from Bitcoin Optech's component values: 10.5 vB overhead, 68 vB per input, and 31 vB per output.

Batched totals assume a single input (68 vB) plus one change output (31 vB). Real-world transactions often require multiple inputs when the sender's UTXO set is fragmented, which reduces the savings percentage but still yields substantial improvement over individual transactions. The savings scale linearly with the fee rate: during fee spikes exceeding 500 sat/vB, batching 10 payments saves nearly 500,000 sats (roughly $330 at $67,000/BTC).

Privacy Implications

On-chain batching creates an inherent privacy tradeoff. Every recipient in a batched transaction can observe all other outputs, and chain analysis tools assume that all inputs belong to the same entity (the common-input-ownership heuristic). This means batching reveals relationships between otherwise unconnected payments.

The practical impact depends on context. For exchanges processing thousands of withdrawals, batching leaks minimal additional information because chain analysts already identify exchange transactions through other patterns. For a business running payroll, batching would reveal every employee's payment amount to every other recipient (and to anyone monitoring the blockchain).

PayJoin partially mitigates this by having both sender and receiver contribute inputs, breaking the common-input-ownership assumption. BTCPay Server's PayJoin processor combines this privacy benefit with batching. The emerging multiparty PayJoin protocol (BIP 77) extends this further: a prototype has demonstrated five-party transactions where the input-output relationships become ambiguous to outside observers.

Lightning MPP has the opposite privacy profile. Each path segment is onion-routed independently, and with basic MPP, intermediate nodes see only their own forwarded amount. However, nodes observing multiple parts with the same payment hash can infer they belong to the same payment. Atomic Multipath Payments (AMP) address this by using unique hashes per part, though AMP adoption remains more limited.

Choosing the Right Approach

The best batching strategy depends on your payment patterns, volume, and tolerance for confirmation delay.

If you send many on-chain payments daily (exchange, payroll service, mining pool): native transaction batching with a scheduled interval delivers the highest fee savings. Accumulate payments for 15-60 minutes, then broadcast a single transaction. Pair this with RBF so you can add late-arriving payments to an unconfirmed batch.

If you run a merchant or payment processing service: BTCPay Server's payout processors provide a turnkey self-hosted solution. Configure hourly or daily batches and use the PayJoin processor if privacy matters.

If you need instant settlement and low per-payment costs: Lightning with MPP eliminates on-chain fees entirely for routed payments. Layer 2 solutions like Spark can further reduce costs for high-frequency Bitcoin-native transfers.

If you are withdrawing from an exchange: batching is handled automatically. The only decision is whether to accept the exchange's batching delay or pay a premium for priority withdrawal processing where available.

Frequently Asked Questions

How much does Bitcoin transaction batching save on fees?

Savings range from roughly 39% (2 recipients) to over 75% (25+ recipients) compared to sending individual transactions. The exact savings depend on the number of recipients and the number of inputs required. Coinbase reported a 75.2% reduction in customer transaction fees after implementing batching in 2020. The dollar value of savings scales directly with the fee rate: the same batch saves 10x more during a 50 sat/vB fee environment than at 5 sat/vB.

Does batching delay my Bitcoin transaction?

Native batching itself adds no on-chain delay: the batched transaction confirms just as fast as an individual one. The delay comes from the accumulation window: the sender waits to collect enough payments before broadcasting. Exchanges typically batch every 1-40 minutes. BTCPay Server allows configuring the interval from minutes to weekly. For time-sensitive payments, senders can broadcast immediately with fewer recipients and still capture partial savings.

Is Bitcoin batching safe for privacy?

Batching creates an on-chain link between all recipients in the transaction. Every recipient can see every other output amount and address. Chain analysis firms use the common-input-ownership heuristic to associate all inputs with the sender. For exchanges, this is acceptable because their transactions are already identifiable. For businesses paying individuals, batching can expose payment amounts to other recipients. PayJoin can help mitigate this by breaking input-ownership assumptions.

What is the difference between transaction batching and Lightning multi-path payments?

Transaction batching combines multiple payments into one on-chain transaction with multiple outputs, reducing the virtual bytes consumed. Lightning multi-path payments split a single payment across multiple off-chain routes. Batching saves on-chain block space; MPP improves Lightning routing efficiency and enables payments larger than any single channel. They operate at different layers and can complement each other: a service might batch on-chain settlements while using MPP for Lightning payouts.

Which wallets support Bitcoin batch payments?

Bitcoin Core supports batching through the sendmany RPC command. Sparrow Wallet provides a "Send To Many" graphical tool with CSV import. Electrum has a "Pay to many" feature under its Tools menu. BlueWallet includes built-in batch sending. BTCPay Server offers server-side batching through its payout processor system. Most Lightning wallets support MPP automatically through their underlying implementation (LND, CLN, Eclair, or LDK).

Can I use Replace-By-Fee with batched transactions?

Yes. RBF and batching work well together. If a batched transaction is still unconfirmed, the sender can create a replacement transaction that adds new recipients, adjusts the fee rate, or both. Strike uses this technique to continuously append withdrawal requests to unconfirmed batches, achieving 30-50% savings per payment. RBF-enabled batching is particularly valuable for services with a steady stream of outgoing payments.

How does CPFP interact with batched transactions?

Child-Pays-For-Parent (CPFP) allows any recipient of a batched transaction to speed up confirmation by spending their output with a high-fee child transaction. This is useful when one recipient needs faster confirmation than others. However, the child transaction pays for the entire parent, which can be expensive for large batches. RBF is generally more fee-efficient for the sender, while CPFP gives individual recipients control over confirmation priority. See the RBF vs CPFP comparison for a detailed breakdown.

This tool is for informational purposes only and does not constitute financial advice. Fee savings estimates are based on P2WPKH transaction component sizes from Bitcoin Optech and assume idealized conditions. Actual savings vary based on input count, output types, and fee rate at time of broadcast. Always verify current fee conditions before making payment decisions.