Across protocol is an intent-based bridge with HubPool settlement

Across protocol is a system for moving tokens between blockchains, where relayers use their own funds to deliver the requested asset. This intent-based design lets a user specify the destination chain, token, amount, and recipient, then receive a fast fill before the protocol completes its accounting. On relayer-filled routes, Ethereum’s HubPool later batches repayments and SpokePool rebalancing, while UMA’s Optimistic Oracle supplies the dispute layer. User delivery and network settlement therefore run on separate timelines.

Updated on 2026-07-30

Across relayers and Circle CCTP serve different routes

In the same way, Across relayers front destination liquidity, while Circle CCTP burns and mints native USDC. Both mechanisms deliver native USDC on supported routes, but their scopes differ. CCTP waits for Circle’s attestation to authorize minting. An Across intent pays a relayer to deliver the output first, then reimburses that relayer through settlement.

Direct CCTP fits a USDC-only application that wants issuer-controlled burn-and-mint semantics. The Across Swap API covers token-to-token outcomes, route discovery, and embedded destination calls; it also selects CCTP or an Omnichain Fungible Token path when that settlement method better fits the quote. On a relayer-filled path, SpokePools hold deposits, relayers front funds, and Ethereum’s HubPool later batches repayment. One interface can therefore expose several settlement paths while preserving the exact destination asset as the user’s binding outcome.

What does an Across transfer cost?

An Across quote deducts liquidity-provider and relayer charges from the amount delivered to the recipient. For a same-token bridge, the difference between input and output represents the quoted cost. A cross-token quote reports its components alongside the exchange result.

Relayer compensation has three parts: destination gas, the opportunity cost of committed capital, and capital risk during reimbursement. The LP component reflects HubPool utilization and the need to rebalance liquidity between chains. When the relayer chooses repayment on the origin chain, the LP fee is 0% because no crosschain pool rebalance is required. Other repayment paths use route-specific utilization parameters. The quote’s output amount remains the useful comparison because gas prices, available relayer inventory, and any origin or destination swap affect the final receipt.

Integrators may add an app fee from 0 to 1, where 0.01 represents 1% of the output. Production API requests also carry a 2-byte integrator ID. Raw token units require equal care: USDC uses 6 decimals, while WETH uses 18 decimals. A fresh quote keeps those units, fee fields, deadlines, and transaction data synchronized before the wallet signs.

Choose the route before signing

A correct origin, destination, token pair, and recipient determine whether the quoted route is usable. Run this five-point decision check before asking the wallet to sign:

• Confirm that both networks appear in the supported-chain response.
• Select token contracts returned for those specific chains.
• Check that the recipient accepts the quoted destination asset.
• Compare the output amount with the minimum required receipt.
• Keep enough origin-chain gas for approvals and the deposit.

Set the two networks

Chain IDs remove naming ambiguity: Ethereum is 1, Optimism is 10, Polygon is 137, Base is 8453, and Arbitrum is 42161. Select the origin network in the wallet before signing. A valid recipient on another network doesn’t correct a deposit submitted to the wrong SpokePool (set out Across protocol essentials ).

Read the quote as a commitment

The Swap API exposes three trade types. exactInput fixes the spend, minOutput establishes a receipt floor, and exactOutput fixes the destination amount. The response identifies the token contracts, output amount, expected fill time, fees, and deadlines. Integrations must convert human-readable quantities into the token’s 6-decimal or 18-decimal units before constructing transaction data.

Approve, submit, and track

Execute any ERC-20 approval returned with the quote, then submit the main swap transaction. Save the origin transaction hash and deposit identifier. Tracking exposes four core states: pending, filled, expired, and refunded. A destination-chain balance or fill transaction confirms delivery more reliably than a wallet animation.

Which assets and chains fit the protocol?

Supported token contracts and both selected chains decide whether Across can produce an executable quote. The route matrix includes established networks such as Ethereum, Arbitrum, Base, Optimism, Polygon, Avalanche, and Solana, but coverage is token-specific. USDC, ETH or WETH, and selected stablecoin routes don’t imply that every asset works between every pair. The Swap API’s chain and token responses are the operative compatibility check; hard-coded lists age as deployments change. A usable pair resolves two exact token contracts, such as USDC on Arbitrum and Base.

Crosschain swaps and embedded actions

Across supports plain asset transfers, crosschain swaps, and destination actions within one quoted flow. The requested output, rather than a manually chosen sequence of bridges and exchanges, defines success.

A stablecoin route can start and end in USDC, while a broader swap can accept a different origin asset and return the requested destination token. When the input isn’t directly bridgeable, the routing layer incorporates an origin swap before crosschain settlement. The quote still names the exact output contract and minimum amount. Underneath that interface, the system selects among relayer intents, Circle CCTP for native USDC, and LayerZero’s OFT mechanism for suitable omnichain tokens such as USDT0.

A GET request handles a simple bridge or swap, while POST adds a destination message for embedded execution. The MulticallHandler performs the attached calls on the destination chain as part of the fill. A wallet or application can therefore bridge USDC, convert it, and deposit the resulting asset into Aave without requiring a separate user-signed destination transaction.

Relayer liquidity changes the user experience

Relayer inventory determines whether the fast user fill remains economical at the quoted size. A relayer pays the destination output from its own balance, then receives repayment after bundle settlement, so the user doesn’t wait for canonical rebalancing. Across quotes expose an expected fill time and route limits; well-served paths target about 2 seconds, while larger orders face separate instant and short-delay limits. That separation matters when moving USDC between Arbitrum and Base.

Security boundaries around SpokePools and settlement

Before any of that matters, Across security rests on upgradeable contracts, bonded bundle proposals, and an open dispute process. Destination confirmation proves delivery, while reimbursement and pool rebalancing are finalized through a later process.

Contract control

SpokePool contracts use UUPS-upgradeable proxies whose administration traces to HubPool governance on Ethereum. The contract suite includes OpenZeppelin audit reports, yet upgrade authority and token allowances remain explicit trust boundaries. An ERC-20 approval stays active until it is spent or changed, so the spender and amount shown by the wallet deserve review before the deposit is submitted.

Optimistic verification

Dataworkers propose root bundles and post a bond. Each proposal enters a challenge period, and UMA’s Optimistic Oracle resolves a disputed result through its Data Verification Mechanism. The central assumption is one honest validator willing to check deposits, fills, fees, block ranges, and Merkle roots rather than continuous agreement among every relayer. The same ground is retraced Across protocol overview.

Unfilled deposits

From a timing perspective, Across V3 removed partial fills, leaving two pre-refund outcomes: a relayer completes the whole intent, or the fill deadline expires. An expired deposit remains in the origin SpokePool until bundle settlement processes its refund. The refund address belongs to the transaction design, especially when the recipient and depositor are different accounts.

How does HubPool settlement work?

HubPool settlement batches validated activity on Ethereum and repays relayers after users receive their destination assets. The lifecycle separates initiation, destination fulfillment, and final accounting.

Deposit and fast fill

The flow has three phases: deposit, fill, and settlement. A V3 EVM depositV3() call carries 12 parameters, including both tokens, both amounts, the recipient, destination chain, relayer fields, deadlines, and an optional message. Its quote timestamp, fill deadline, and exclusivity deadline are 32-bit values. A relayer reads the deposit event and supplies the promised output from destination-side inventory.

Bundle proposal

A dataworker reconstructs activity across the covered block ranges and proposes three functional Merkle roots: relayer refunds, pool rebalancing, and slow fills. UMIP-157 and UMIP-179 define how deposits, fills, fees, and repayment amounts enter that bundle. Settlement cost is O(1), not O(N), because many fills are aggregated into one bundle proposal.

Repayment and rebalancing

After the challenge period closes, the accepted roots direct refunds and liquidity movements. Canonical messaging carries the required instructions to SpokePools, and relayers claim repayment on their selected chains. Choosing an origin-chain repayment avoids a crosschain LP rebalance; choosing another chain shifts liquidity toward the place where the relayer needs working capital.

Fast fill and final accounting run on separate clocks. The relayer serves the user first; HubPool settles the network later, around the 1.5-hour minimum bundle cadence.

Stargate, canonical bridges, and direct CCTP

Stargate, canonical bridges, and direct CCTP differ mainly in liquidity and verification paths. The right alternative follows the asset, destination, and trust boundary required by the transaction.

Stargate V2 uses LayerZero messaging, liquidity pools, and pathway credits, making it a close comparison for native-asset routes. A canonical bridge follows a chain’s own messaging system and suits users who accept its settlement clock; an Arbitrum withdrawal to Ethereum carries the rollup’s 7-day challenge period. Direct Circle CCTP specializes in native USDC burn-and-mint transfers and caps one burn at 10 million USDC. Across protocol fits outcome-based routing when relayer delivery, token conversion, and one Swap API matter together.

Across protocol questions worth asking