Transaction Batching Turns Shared Bytes Into Lower Fees

On August 12, 2020, Veriphi reported that transaction batching—combining many recipients under one transaction’s shared input and overhead—could have saved more than 21,000 BTC in fees from January 2012 through June 2020. That figure was a counterfactual estimate, not an observed rebate: researchers reconstructed potentially batchable activity from public blocks and compared its weight with a modeled alternative.

What does a batch actually share?

A batch replaces several separate transactions with one transaction containing multiple payment outputs. On Bitcoin, every standalone payment ordinarily carries inputs, fixed transaction fields and a change output. A batched sender pays much of that overhead once, then adds a smaller output for each recipient.

Bitcoin Optech’s March 2021 P2WPKH example makes the arithmetic visible. One conventional payment occupied about 140 virtual bytes. Expanding it to five recipients produced a 264-vbyte transaction, or roughly 53 vbytes per receiver. Sending five separate 140-vbyte transactions would consume about 700 vbytes. The coins transferred do not shrink; the repeated packaging does.

Account-based networks apply the same principle differently. An exchange or smart contract can group actions beneath a shared transaction envelope, while rollups aggregate many state changes before posting compressed data or a commitment to the settlement chain. The common economic result is amortization: more transfers share fixed verification and publication costs.

The savings move through several counterparties

• Senders purchase fewer bytes or less execution overhead for the same withdrawal count.
• Recipients share one confirmation event and may wait while the operator fills the batch.
• Miners or validators receive a fee for the combined transaction rather than several independent fees.
• Other users face less block-space competition if batching removes redundant data at scale.

Operators can improve the result by consolidating fragmented Bitcoin inputs when fee rates are low, then spending a larger input into later batches. That changes treasury timing: funds are reorganized before demand arrives, and withdrawals may remain queued longer. The operational note labeled Manta Bridge points to an adjacent constraint—efficient transfer execution does not eliminate the need to retain native assets for subsequent gas.

Where does batching create new costs?

Waiting for more recipients lowers average cost but increases withdrawal latency. A multi-output transaction also exposes a relationship among payments: observers can see that the outputs settled together, even if they cannot prove who controls them. More outputs are observable; identifying an exchange, payroll processor or bridge as the sender remains attribution unless a wallet is disclosed or independently labeled.

Fee management becomes less flexible, too. One underpriced batch can delay every recipient. Replacement may confuse wallets, while a recipient attempting child-pays-for-parent can face an uneconomic burden because the child must help lift a large shared parent. Larger batches also concentrate operational mistakes into a wider payout set.

The unresolved question is who captures the savings

Batching clearly lowers marginal network consumption, but lower production cost does not guarantee cheaper withdrawals. An operator can pass the saving through, use it to stabilize fixed fees, or retain it as spread. The evidence to watch is the joint movement of labeled services’ output counts, mempool fee rates, consolidation timing and published withdrawal charges. That comparison—not transaction shape alone—will show whether batching improves market access or merely widens an intermediary’s margin.