Protocol is how HubPool bundles cut crosschain settlement gas costs

Protocol is across Protocol’s settlement design in which the Ethereum HubPool accepts one bonded root-bundle proposal covering many relayer fills, then authorizes grouped refunds through Merkle proofs. Shared proposal, verification, and delivery work replaces repeated per-fill settlement overhead. The saving grows as more valid fills share a bundle, although token transfers and chain execution still consume gas.

This page isolates that settlement cost path: what becomes shared, what remains per leaf, how repayment-chain selection changes fees, and where V4 delivery alters the final mile. It assumes the deposit-and-fill workflow is already familiar.

Across HubPool bundles versus Circle CCTP settlement

Across HubPool batching amortizes repayment verification across many relayer fills, while Circle CCTP handles each native USDC transfer through its own burn-and-mint message lifecycle path. CCTP’s two token actions map directly to one transfer, whereas Across separates a fast user fill from later reimbursement. That separation lets one Ethereum proposal and grouped destination-chain leaf executions cover a set of fills. It adds inventory time and optimistic finality, so the better design depends on whether the route values native USDC issuance or relayer-funded speed.

Where do HubPool bundles save gas?

HubPool bundles save gas by sharing bundle proposal, optimistic verification, root publication, and proof infrastructure across fills instead of repeating those steps for every repayment.

Each fill still creates a deposit record, a destination fill, and an eventual token refund. The saving sits around those transfers. Ethereum sees one proposeRootBundle call for the covered block ranges, and each target SpokePool receives compact roots rather than a full list of payments. An executor later submits one Merkle proof for a leaf holding several refund addresses and matching amounts. Storage writes, ERC-20 transfers, calldata, and destination gas remain. This distinction matters: bundling compresses shared coordination and verification; it does not turn sixty token movements into one onchain balance update.

High bundle occupancy therefore matters most when Ethereum proposal overhead would otherwise dominate small, separate reimbursements.

The fixed settlement transactions and the variable bill

Across settlement always needs a root-bundle proposal on Ethereum and later leaf execution on repayment chains, while the number of leaves follows token and chain groupings.

The cost model has three shared layers: proposal gas on Ethereum, root delivery to a SpokePool, and Merkle-proof verification when a refund leaf executes. The variable layer includes calldata bytes, proof depth, each ERC-20 transfer, and any chain-specific message fee. A leaf holds one token address, one chain ID, parallel arrays of refund addresses and amounts, plus any amount returned toward the HubPool. Because refund arrays must have equal length, grouping works cleanly only when the repayment chain and token match. Base, Arbitrum, and Optimism still price their own execution and data.

No fixed dollar saving belongs to the Protocol. Ethereum base fees, destination gas prices, proof length, token behavior, and fills per leaf set the realized amount.

Why do larger refund batches lower per-fill overhead?

Larger refund batches lower per-fill overhead because the single HubPool proposal cost is divided across more fills, while each added refund mainly contributes calldata and transfer work.

The numerator is shared settlement gas; the denominator is the count of valid fills using it. If a bundle covers N fills, proposal overhead per fill is proposal gas divided by N. Leaf execution adds another shared term, but grouping by repayment chain and token prevents every fill from landing in one leaf. A busy Ethereum-to-Base USDC period therefore spreads the HubPool transaction broadly, while a thin WETH route on another chain carries a larger share per fill at the same block fee. No market price is needed to understand that arithmetic.

The benefit flattens once ERC-20 transfer loops dominate the shared proposal and proof costs.

A related page handles this in practice. Refund leaf size has practical bounds. More addresses enlarge calldata and extend the transfer loop, so executors split the tree into leaves economical to submit. A refund leaf uses a 32-bit leafId, and the SpokePool records claims in a bitmap to prevent second execution.

Bundle frequency adds another trade-off. Across targets proposals about every 1.5 hours, so waiting longer solely to enlarge a batch would tie up relayer capital and raise the capital component of quotes. Efficient operation balances occupancy against reimbursement time. A direct CCTP transfer avoids that inventory loan, while Across uses batching to support an immediate relayer-funded fill.

Three Merkle commitments organize the bundle

Each HubPool proposal commits to three Merkle roots: pool rebalancing, relayer refunds, and slow fills, separating accounting jobs while sharing one optimistic decision on Ethereum.

Each root is a 32-byte bytes32 value, so the proposal does not publish every payment as flat Ethereum storage. The pool-rebalance root directs liquidity between the HubPool and SpokePools. The refund root commits to leaves grouping addresses and amounts for a token on a repayment chain. The slow-fill root covers deposits served from protocol liquidity after the fast path does not complete. Only the refund and slow-fill roots travel into the SpokePool’s relayRootBundle call; the HubPool consumes the rebalance root through its own execution path.

The pool-rebalance leaf count uses an 8-bit unsigned integer, whose type range tops out at 255. The contract also requires at least one rebalance leaf before accepting a proposal. These limits keep bundle execution enumerable without exposing the full payment list in the proposal.

Compact commitments move the expensive detail to proof-backed execution on the chain holding the refund liquidity.

The two-hour challenge window and its cost trade-off

The HubPool’s default liveness window lasts 7,200 seconds, or two hours, giving validators time to reconstruct the proposed roots before settlement becomes executable on Ethereum. The contract permits governance to change liveness but rejects settings of 600 seconds or less, preserving a minimum above ten minutes. A dispute pauses execution and introduces a second bond-bearing participant through UMA’s Data Verification Mechanism. The delay reduces premature finality risk, yet it increases relayer inventory time compared with direct finality paths.

When does repayment-chain choice remove the LP fee?

Repayment on the origin chain sets the Across LP fee to zero because deposited funds are already available there and no crosschain pool rebalancing loan is required.

That zero applies only to the LP component. The relayer still prices destination fill gas, capital use before reimbursement, and operational risk; an integrator can also add an app fee between 0 and 1, where 0.01 represents 1%. When repayment lands on Base after an Arbitrum deposit, the pool must account for liquidity movement, so route parameters and utilization enter the LP calculation.

Relayers choose repayment placement to manage inventory across Ethereum, Arbitrum, Base, and Optimism. A user quote reflects that treasury decision indirectly through input-versus-output spread, not a separate HubPool transaction charged to the wallet.

A settlement-cost decision checklist

A useful settlement-cost check separates user-facing quote components from protocol execution, then tests whether enough same-token, same-chain refunds exist to amortize the HubPool work efficiently.

Use these conditions when assessing a route or reviewing a relayer’s reimbursement plan.

• Confirm the quote separates LP, relayer, gas, and optional app fees.
• Check whether repayment stays on the origin chain, making the LP fee zero.
• Group only refunds sharing a repayment chain and token.
• Count expected fills per bundle, not transfers per day across unrelated routes.
• Allow for the two-hour challenge plus root-delivery and leaf-execution time.

The checklist prevents two common accounting errors. First, dividing proposal gas by every Across transfer overstates sharing because separate tokens and repayment chains require separate leaves. Second, treating the input-output spread as pure gas ignores capital and LP components. Track the bundle proposal transaction, the destination leaf transaction, and the refund count inside that leaf. A high-volume USDC route on Base presents a different amortization profile from a sparse WETH route on Ethereum, even when both fills entered the same root bundle. Circle CCTP remains the cleaner comparison when the only objective is native USDC burn-and-mint settlement.

Validation reconstructs the shared accounting

Across validators recompute every covered deposit and fill, then compare three expected Merkle commitments with the proposed bundle before the two-hour liveness period closes on Ethereum.

The checks match input and output tokens, amounts, chain IDs, recipients, block ranges, fee calculations, and duplicate handling. UMIP-157 defines the original Across V2 bundle rules, while UMIP-179 extends validation for V3 intent data. The Dataworker performs the same reconstruction before proposing. Independent software needs archive access across supported chains because a current-state RPC view cannot replay the covered history reliably. The follow-on topic is treated in First steps.

Optimistic verification compresses the onchain decision into one bonded assertion, but it does not discard transaction-level evidence. One honest validator is sufficient to challenge a mismatched proposal under the design’s 1-of-N assumption. The proposer posts Across Bond Token, an ERC-20 derived from WETH9 with 18 decimals and proportional ETH deposits. A challenger posts a matching bond before the window ends. UMA resolves a contested root through its Data Verification Mechanism, and the losing side forfeits its bond. This economic path replaces mandatory onchain verification of every fill with replayable offchain computation.

The Protocol saves gas because Ethereum stores the commitment and decision, while validators shoulder the heavier reconstruction outside consensus.

V4 delivers finalized roots with Ethereum state proofs

Across V4 keeps HubPool bundle verification on Ethereum, then uses Succinct SP1 proofs of finalized Ethereum state to deliver approved settlement messages to Universal SpokePools.

After Ethereum finality, described as 12 to 15 minutes for this path, a finalizer requests a proof. SP1 Helios verifies a proof built from a beacon-chain sync committee of 512 validators and a Merkle proof of the HubPoolStore slot. The proof service tracks four states: waiting for finality, generating, success, and error. Destination submission then uses two transactions: one updates the light client, and one executes the verified message.

Relayer repayment still ends at executeRelayerRefundLeaf, so V4 changes root delivery rather than the underlying refund-array economics. Gas moves from a custom canonical-bridge adapter path toward proof generation and two destination calls. The destination still verifies the leaf, checks its chain ID, marks the 32-bit leaf ID claimed, and transfers the stated ERC-20 amounts. Across extends the same batch logic to a broader verification design without pretending proof delivery is free. Circle CCTP remains distinct because it authenticates a USDC burn-and-mint message rather than a HubPool refund root.