Gas math: why batched coordinator commits beat per-message bridges

The 40% gas savings claim on our homepage is not a magic trick. It comes from a single architectural decision: the coordinator commits messages in batches, so destination chains amortize calldata across the bundle. That decision pays back roughly four times out of five. The fifth time, it loses. This post is the honest accounting of all five.

The basic math

For a single cross-chain message landing on Ethereum mainnet, you pay three gas costs:

1. Source emission. The cost of the transaction on the source chain that triggers the message. This is yours regardless of which bridge you use.
2. Destination verification. The cost of the receiving contract reading the proof and verifying it. Depends on the verifier type.
3. Destination calldata. The cost of the bytes representing the payload, posted on the destination chain.

Of those three, (1) is roughly equal across all bridge designs (you have to trigger somewhere), (2) varies by verifier (light-client proofs are more expensive to verify than threshold signatures), and (3) scales linearly with payload size.

For a typical per-message bridge — Wormhole, LayerZero, CCIP — you pay (2) + (3) once per message. For Switchboard, the coordinator program commits a batch of messages in one Solana transaction, and the destination submission posts a Merkle root with per-message proofs. The destination pays (2) once for the batch plus a much smaller (3) per message inside the batch.

The savings depend on the batch size and the message size. Let us write it down properly.

A worked example on Ethereum mainnet

Assume:

• Ethereum gas price: 25 gwei
• ETH price: $3,400
• Verifier cost per call: 120,000 gas (light-client proof)
• Calldata cost per byte: 16 gas (assume non-zero bytes)
• Average payload: 384 bytes

For a single message, per-message bridge:

• Verifier: 120,000 × 25 gwei × $3,400 / 10^18 × 10^9 = $10.20
• Calldata: 384 × 16 × 25 × $3,400 / 10^18 × 10^9 = $1.30
• Total destination cost: $11.50

For a batch of 10 messages on Switchboard:

• Verifier: 120,000 × 25 × $3,400 / 10^18 × 10^9 = $10.20 (once, amortized across 10)
• Per-message calldata + proof: 384 + 96 bytes Merkle proof = 480 × 16 × 25 × $3,400 / 10^18 × 10^9 = $1.63
• Per-message effective cost: ($10.20 / 10) + $1.63 = $2.65

That is a 77% saving at a batch size of 10, for this payload shape, on this chain, at this gas price. For batch sizes of 50+ on a hot corridor, the per-message verifier cost effectively vanishes and the savings push past 85%.

The 40% number on our homepage is the average across all customer workloads in Q1, not the best case. It includes long-tail workloads with batch sizes of 2–3 where the savings are real but smaller.

When batching loses

There are three ways batching makes things worse, and we should be explicit about each.

Latency-pinned routes. If your application cannot wait for a batch window to fill, you have to set the batch size to 1 and pay the per-message cost. Switchboard supports this — a route can declare batch: 'never' — but if you set it, you have given up the gas savings. We make sure the latency win is still real (~250ms p50 even at batch size 1), but the gas savings shrink to roughly 5%.

Tiny payloads on cheap chains. If your destination is a chain with extremely cheap calldata (e.g. an alt-L1 with $0.001 transactions) and your payloads are small, the verifier cost is the entire bill and batching helps a lot. But if your payload is small and your destination is cheap, you do not have a gas problem to solve in the first place. The 40% claim does not really apply because the absolute dollar amounts are tiny.

Failed batches. If a batch contains 10 messages and one of them is malformed (e.g. the destination contract reverts), some bridge designs revert the entire batch. Switchboard does not — we split on failure and retry the bad message individually — but the retry costs more gas than if it had been a single-message dispatch from the start. Empirically this happens in well under 0.1% of operations for healthy customers, but if your application is producing routinely-rejecting messages, batching is making things slightly worse for you.

The honest comparison table

Here is the gas-cost summary we put in customer briefs. Numbers are p50 for the corridor and payload shape, mid-2026 gas prices.

Corridor	Per-message bridge	Switchboard (batched)	Saving
Solana → Ethereum	$14.20	$3.60	75%
Arbitrum → Base	$0.18	$0.08	56%
Ethereum → Polygon	$11.40	$4.10	64%
Polygon → Sui	$0.41	$0.36	12%
Base → Optimism (sz1)	$0.14	$0.13	7%

The Polygon → Sui row is interesting: Sui is cheap enough that batching does not help much, but it also does not hurt. The Base → Optimism row at batch size 1 is where you see the floor: even with zero batching, we are slightly cheaper because the verifier cost on a light-client proof is competitive with threshold-sig verification, and our calldata footprint is leaner.

Why this matters more than people think

A lot of cross-chain economic discussion focuses on “the bridge fee” as a fixed percentage. That framing hides the part of the cost that scales with payload size, batch behavior, and verifier choice. For high-throughput applications — orderbooks, real-time games, MEV routing — the variable gas cost is the dominant line item, and a 50% reduction translates directly into more aggressive pricing for end users.

We made the architectural call early to batch at the coordinator because we wanted to give that pricing power to customers. The two-service architecture is what makes the batching practical to implement and operate. The Solana coordinator is what makes the batching latency tolerable.

How to think about it for your project

Three quick questions:

1. What is your batch tolerance? If you can wait 200ms to gather a batch of 4–8 messages, you will see the full savings. If every message has to ship immediately, you will see closer to 5%.
2. What is your payload size? Small payloads (< 128 bytes) make the verifier cost dominant and batching very effective. Large payloads (> 2KB) shift the cost back toward calldata, and the per-message savings shrink.
3. What is your destination chain? Expensive chains (Ethereum, Bitcoin) are where batching pays the most. Cheap chains are where batching helps least, and where most of your gas savings come from picking the right verifier anyway.

Plug those into the calculator in the SDK (@switchboard/sdk/cost-estimate) and you will get a real number for your real workload. The 40% figure is an average; your number could be 75% or 7%. We will tell you which on the first call.