Glossary

Transaction Batching

Transaction batching combines multiple Bitcoin payments into a single on-chain transaction, reducing fees and block space usage.

Key Takeaways

  • Transaction batching combines multiple payments into one on-chain transaction, sharing the fixed overhead costs (input signatures, transaction header, change output) across all recipients. This can reduce network fees by 40–75% compared to sending individual transactions.
  • Exchanges and payment processors benefit most: Coinbase reported a 75.2% fee reduction and 95% fewer daily transactions after enabling batching. The per-payment cost approaches just the size of a single output (about 31 virtual bytes for P2WPKH).
  • Tradeoffs include slight payment delays (recipients wait for the next batch window), reduced privacy (all outputs in a batch are publicly linked to the same sender), and more complex UTXO management.

What Is Transaction Batching?

Transaction batching is the practice of combining multiple Bitcoin payments into a single on-chain transaction. Instead of creating a separate transaction for each recipient, the sender constructs one transaction with multiple outputs, each paying a different address. Every recipient receives their funds in the same block confirmation, while the sender pays transaction fees only once.

On the Bitcoin network, fees are determined by the data size of a transaction (measured in virtual bytes), not by its monetary value. A transaction sending 0.001 BTC costs the same in fees as one sending 100 BTC, assuming identical byte sizes. Batching exploits this by amortizing the fixed-size components of a transaction: the header overhead, input signatures, and change output are paid once regardless of how many recipients are included.

The technique is primarily used by high-volume senders like exchanges, mining pools, and payment processors that process many withdrawals or payouts within short time windows. For individual users sending to a single recipient, batching offers no benefit.

How It Works

To understand batching, it helps to know what makes up a Bitcoin transaction's size. Every transaction has three categories of data:

  • Overhead: version, locktime, and SegWit marker/flag fields consume roughly 10.5 vBytes per transaction, regardless of how many inputs or outputs it contains
  • Inputs: each input (spending a previous UTXO) requires a signature and reference data, consuming about 68 vBytes for P2WPKH or 57.5 vBytes for P2TR (Taproot)
  • Outputs: each output (a payment to a recipient or change back to the sender) is comparatively small at roughly 31 vBytes for P2WPKH or 43 vBytes for P2TR

Individual vs. Batched Transactions

Consider a sender who needs to pay 10 different recipients. With individual transactions, the sender creates 10 separate transactions, each paying the full overhead, input, and change output costs:

Individual approach (10 separate P2WPKH transactions):
  Per transaction: 10.5 (overhead) + 68 (input) + 31 (recipient) + 31 (change) = ~141 vB
  Total: 141 × 10 = 1,410 vB

Batched approach (1 transaction, 10 recipients):
  Single transaction: 10.5 (overhead) + 68 (input) + 31 × 10 (recipients) + 31 (change) = ~420 vB

Savings: 1,410 - 420 = 990 vB saved (70% reduction)

The savings come from eliminating nine redundant sets of overhead, nine redundant input signatures, and nine redundant change outputs. As the number of recipients grows, the per-payment cost asymptotically approaches just the cost of a single output: about 31 vBytes.

Fee Calculation Example

At a fee rate of 50 sat/vB, the difference is substantial:

Individual: 1,410 vB × 50 sat/vB = 70,500 sats (~$35 at $50k/BTC)
Batched:      420 vB × 50 sat/vB = 21,000 sats (~$10.50 at $50k/BTC)

Savings per batch: 49,500 sats
Savings per payment: 4,950 sats

During periods of high mempool congestion when fee rates spike, these savings become even more significant. An exchange processing thousands of withdrawals daily can save millions of satoshis in fees by batching consistently.

Interaction with SegWit and Taproot

Batching compounds with other fee-saving technologies. SegWit already reduces input sizes through the witness discount (witness data counts at one-quarter weight), and batching further reduces costs by eliminating redundant inputs entirely. Taproot (P2TR) inputs are even smaller at 57.5 vBytes compared to SegWit's 68 vBytes, making batched Taproot transactions the most space-efficient option available.

Use Cases

Exchange Withdrawals

Cryptocurrency exchanges are the largest beneficiaries of transaction batching. When users request withdrawals, the exchange queues them and periodically (every 10 to 30 minutes) combines all pending requests into a single transaction. Coinbase reported a 75.2% reduction in transaction fees and a 95% decrease in daily transaction count after implementing batching, with all savings passed to customers.

Other major exchanges including Binance and Bitfinex also batch withdrawals. When you withdraw Bitcoin from an exchange and see multiple outputs in the transaction on a block explorer, that is batching in action.

Mining Pool Payouts

Mining pools distribute rewards to hundreds or thousands of miners after each block. Without batching, each payout cycle would require thousands of individual transactions. Batching lets the pool pay all miners in a single transaction, dramatically reducing the pool's fee overhead and leaving more of the block subsidy for miners.

Payment Processors and Payroll

Businesses that make regular Bitcoin payments (merchant payouts, payroll, affiliate commissions) can batch disbursements on a schedule. Rather than paying each recipient immediately, the system accumulates payments and sends them in periodic batches. This is particularly effective for payroll and recurring payments where slight delays are acceptable.

UTXO Consolidation

While not batching in the strictest sense, the same principle applies to UTXO consolidation: combining many small UTXOs into fewer large ones in a single transaction. Services that receive many small payments (donation addresses, lightning channel closes, mining rewards) periodically consolidate during low-fee periods to prepare efficient inputs for future spending.

Why It Matters

Transaction batching reduces demand for scarce block space. When high-volume senders batch their transactions, they free up space for other users, which helps moderate fee pressure across the entire network. Bitcoin Optech has identified batching as one of the most impactful scaling techniques available today, alongside SegWit adoption and efficient coin selection.

For businesses building on Bitcoin, batching is often the single most effective way to reduce operational costs. The technique requires no protocol changes: it works with standard Bitcoin transactions and has been available since the network launched. The only requirement is software that supports constructing multi-output transactions and a workflow that allows brief queuing of outgoing payments.

Layer 2 solutions like Spark take a different approach to scaling by moving transactions off-chain entirely, but for entities that need on-chain settlement, batching remains the most straightforward optimization. Understanding transaction batching is also foundational for grasping broader UTXO management strategies and fee estimation techniques.

Risks and Considerations

Payment Delays

Batching requires accumulating payments before sending, which means individual recipients experience a delay. If an exchange batches every 30 minutes, a withdrawal request submitted just after the previous batch might wait up to 30 minutes before being broadcast. For time-sensitive payments, this delay may be unacceptable. Most implementations offer an "instant withdrawal" option at a higher fee for users who cannot wait.

Privacy Implications

All outputs in a batched transaction are publicly visible on the blockchain, linked to the same set of inputs. This means every recipient in the batch can see (or infer) that all other outputs were paid by the same entity. While this is obvious for known exchange addresses, it can leak information in other contexts.

Chain analysis firms exploit this through the common input ownership heuristic: all inputs in a transaction are assumed to belong to the same wallet. Batching confirms this heuristic for the sender and can reveal payment patterns, volumes, and counterparty relationships. Techniques like PayJoin can break this heuristic but are not compatible with standard batching workflows.

Fee Bumping Complexity

If a batched transaction gets stuck in the mempool due to an unexpectedly low fee rate, fee bumping becomes more complex. Using replace-by-fee (RBF) requires re-signing the entire transaction with a higher fee, which may require re-validating all outputs. Child-pays-for-parent (CPFP) is possible but requires spending one of the batch's outputs, which may not always be practical. Some implementations reserve a small change output specifically for CPFP fee bumping.

UTXO Management Overhead

Batching changes the sender's UTXO profile. Instead of creating one change output per payment, a batch creates one change output for all payments combined. This can result in larger individual UTXOs or, if the sender is not careful with coin control, may require spending more inputs than necessary for subsequent transactions. Effective batching requires thoughtful coin selection to maintain a healthy UTXO set over time.

Recipient Confusion

Recipients of batched transactions may be confused when they look up their transaction on a block explorer and see many unrelated outputs. Some users may worry their funds are mixed with others or that something went wrong. Exchanges typically address this with documentation explaining that batched transactions are normal and that the user's specific output is their payment.

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.