Do I need ACX to use the Across bridge?

No. A standard bridge transaction spends the selected input token and the origin chain’s native gas token, while relayer and liquidity-provider compensation comes from the quoted output amount, so users don’t need ACX unless they separately choose an activity that specifically uses the token itself.

Which network token pays gas for an Across transfer?

The origin network’s native token pays gas for a standard wallet-submitted deposit. ETH pays on Ethereum, Arbitrum, Base, and Optimism; POL pays on Polygon. The relayer covers destination execution gas and recovers that expense through the quoted relayer fee, placing it inside the output calculation.

Can an Across transfer send tokens to a different recipient?

Yes. The depositor and recipient are separate fields in the Across intent, so the destination token can go to another compatible address. The quote must contain the intended recipient before signing, and that address must be valid on the destination chain. Refunds follow the configured refund address, which is a separate choice.

Does an ERC-20 approval remain after the bridge transaction?

An ERC-20 approval remains only to the extent that allowance survives the SpokePool’s transferFrom call. An approval equal to the transferred amount falls to zero under standard allowance accounting; a larger or unlimited allowance remains until the token holder changes it. The approval concerns that specific token contract and spender on the origin chain.

Is a smart-contract recipient compatible with Across messages?

Yes. An Across intent can carry an optional message for a contract recipient, enabling destination execution after the token fill. The receiving contract implements handleV3AcrossMessage, and the calldata must match its expected interface. Plain externally owned accounts receive tokens without that message, while embedded actions use MulticallHandler to coordinate approved destination calls.

Across is an Intent-Based Cross-Chain Bridge with Relayer Settlement

Across is a cross-chain bridge where users state the outcome they want and independent relayers advance tokens on the destination network. The protocol later verifies those fills, reimburses relayers through pooled settlement, and rebalances liquidity, separating rapid delivery from the slower movement of value between blockchains.

Updated: 6 August 2026

Choosing Across by Route, Asset, and Settlement Preference

For routes where destination speed, a quoted minimum output, and route composition matter, Across offers a better fit than waiting for a canonical bridge to finish settlement. The decisive checks are the two networks, both token contracts, the requested amount, the recipient, and the fill estimate in the live quote.

Route identity matters because the same ticker can represent different contracts. Common Across paths include Ethereum, chain ID 1; Optimism, chain ID 10; Polygon, chain ID 137; Base, chain ID 8453; and Arbitrum, chain ID 42161. Those identifiers stay fixed, while route availability and quoted capacity follow relayer inventory and protocol configuration. Match both the network and token contract, then inspect the exact output asset. A USDC-to-USDC route targets native USDC where supported; some quotes include an origin swap or a different destination token. That distinction decides which balance appears after the fill.

Outcome-based routing is especially useful when the transfer must end with a known token and recipient, rather than merely leave the origin chain. The same material is presented Across for beginners.

The quote should settle the decision: it states input and output amounts, fees, estimated fill time, minimum and maximum route limits, and the transaction to sign. Submit the transaction built from that fresh response, since relayer inventory and gas conditions change between requests.

Fees Before the Wallet Signs

A transfer quote from Across expresses pricing through two protocol components: the liquidity-provider fee and the relayer fee, both reflected in the difference between inputAmount and outputAmount. The relayer fee covers three drivers - destination gas, capital time, and settlement risk. The LP fee follows an Aave-style two-slope utilization curve; origin-chain repayment sets that LP component to zero because no cross-chain rebalancing is required. Fresh quotes also include any origin swap and optional integrator fee.

From Route Quote to Destination Balance

The standard Across transfer begins with an origin chain, destination chain, input token, output token, amount, recipient, and fresh quote whose minimum output is acceptable. A wallet then signs the calldata produced for that route.

The Swap API exposes three trade types: exactInput, minOutput, and exactOutput. A standard quote returns an approval transaction when an ERC-20 allowance is insufficient, followed by the swap transaction. A fresh route therefore requires two on-chain signatures when approval is needed; an existing allowance removes the first step. Native USDC uses 6 decimals, so 1 USDC equals 1,000,000 base units. WETH uses 18 decimals, so 1 WETH equals 1,000,000,000,000,000,000 base units. The quote handles unit conversion, yet the wallet must display the selected contract and output amount clearly before signing.

After submission, tracking follows four core states: pending, filled, expired, and refunded.

The recipient can differ from the depositor. For a plain transfer, the destination SpokePool pays the output token directly. With an embedded action, MulticallHandler executes attached calls after the fill, such as depositing into Aave. The action parameters and recipient contract must match the quote because destination execution belongs to the same requested outcome.

Fixed Parameters in the Intent Envelope

The V3 intent envelope in Across uses fixed field widths so relayers, SpokePools, indexers, and settlement software interpret one deposit consistently across chains during execution. Seven core parameters show where those encoding limits sit.

The V3FundsDeposited event encodes depositId, quoteTimestamp, fillDeadline, and exclusivityDeadline as 32-bit unsigned integers, while amounts and chain IDs use 256-bit unsigned integers.

Parameter	Function	Encoded Value	Hard Limit Or Threshold
depositId	Identifies the deposit	32-bit unsigned integer	4,294,967,295 maximum
quoteTimestamp	Anchors quote timing	32-bit Unix timestamp	4,294,967,295 Unix seconds
fillDeadline	Ends fill eligibility	32-bit Unix timestamp	4,294,967,295 Unix seconds
exclusivityDeadline	Ends exclusive fill rights	32-bit Unix timestamp	4,294,967,295 Unix seconds
inputAmount	Records escrowed units	256-bit unsigned integer	2 ²⁵⁶ − 1 maximum
outputAmount	Records destination units	256-bit unsigned integer	2 ²⁵⁶ − 1 maximum
destinationChainId	Selects the destination	256-bit unsigned integer	2 ²⁵⁶ − 1 maximum

Field capacity is separate from route capacity. The Swap API supplies live deposit limits because inventory, gas, and pool utilization move. Production integrations also attach a 2-byte integrator ID, represented by exactly 4 hexadecimal digits after 0x. Contract encodings set the hard ceiling; the executable quote sets the usable amount.

Pink silhouette of a rearing unicorn on textured white background

Relayer Speed and the Trade-Offs Behind It

Relayer delivery separates user speed from settlement speed: Across gives the recipient destination liquidity first, then verifies reimbursement and rebalances protocol capital later in bundles.

Each intent accepts one valid fill. Relayers monitor deposits, compare the offered fee with destination gas and capital cost, and commit inventory when the route is profitable. A transfer above quoted capacity waits for another settlement path or reaches its fill deadline. An expired deposit enters bundle-based refund processing on the origin side, so the return isn’t immediate, as set out Across comparison in depth.

The settlement security model uses UMA’s Optimistic Oracle and a 1-of-N assumption: one honest validator is enough to dispute an invalid root bundle. A proposer posts an Across Bond Token bond, and a disputing validator posts a matching bond; the HubPool’s configurable bondAmount sets the quantity. The design uses no majority-validator threshold. Correct contracts, available relayers, and eventual bundle execution remain the relevant dependencies.

This design concentrates the user decision in route terms and deadlines, while settlement participants carry the reimbursement workload.

How Does Across Settle a Relayer-Funded Fill?

A relayer-funded fill in Across settles through three phases: initiation on the origin SpokePool, delivery on the destination SpokePool, and bundled verification plus repayment through Ethereum.

At initiation, depositV3 escrows the input token and emits V3FundsDeposited with the recipient, token pair, amounts, destination chain, deadlines, and optional message. Relayers read that event and call fillV3Relay with their own destination-chain tokens. The destination SpokePool records the completed relay, preventing a second valid fill for the same intent. Users therefore receive the quoted outcome before the origin funds have crossed through settlement. This split is the protocol’s defining mechanism: delivery comes from relayer inventory, while escrowed funds support reimbursement later.

The Dataworker then matches fills to deposits and builds three Merkle roots: relayer refunds, pool rebalancing, and slow fills. Aggregation makes verification cost O(1) at the bundle level instead of O(N) per fill. The HubPool on Ethereum receives the proposal, optimistic verification gives validators a dispute window, and finalized instructions reach SpokePools for execution. Bundle proposals follow an operating cadence of about 1.5 hours, separate from the user’s fill time.

Across V4 changes only the third phase. It keeps UMA’s optimistic bundle verification on Ethereum, stores the finalized message in HubPoolStore, and uses Succinct’s SP1 proving network plus SP1Helios on the destination. The proof service tracks four states, its Ethereum input includes a 512-validator sync committee, and submission uses two destination-chain transactions. The finalizer waits about 12-15 minutes for Ethereum finality before proof generation; relayer-funded user delivery has already completed by then.

Repayment timing affects relayer capital costs and LP fees, yet it stays outside the recipient’s destination confirmation.

Move Money Across Chains text over glowing token symbols

Across, CCTP, Stargate, and Canonical Bridges

Fast relayer delivery makes Across a strong fit for outcome-based transfers, while Circle CCTP, Stargate, and canonical bridges expose different asset, messaging, and settlement assumptions.

Circle’s Cross-Chain Transfer Protocol, or CCTP, burns native USDC on the source chain and mints native USDC on the destination after attestation. Its message flow has three steps, and CCTP’s EVM contracts cap one burn transaction at $10 million. Direct CCTP suits USDC-only movement where native burn-and-mint is the desired mechanism. Across also uses CCTP for selected settlement paths, while relayers preserve the fast-fill experience above that layer.

Stargate routes assets through several mechanisms: V1 unified pools, V2 pools and Hydra, Omnichain Fungible Token transfers, and CCTP, with LayerZero carrying messages for its native and OFT routes. That architecture emphasizes asset-specific route selection and shared liquidity rather than Across’s relayer-first intent fill. Route availability still follows the configured token mesh.

Canonical options such as Arbitrum Bridge and Optimism Standard Bridge use each rollup’s native contracts and settlement assumptions. They fit transfers where ecosystem-native verification matters more than destination speed. The choice is therefore mechanical: use Across for a quoted outcome funded by relayers, CCTP for direct native USDC burn-and-mint, Stargate for its configured liquidity or OFT routes, and a canonical bridge for the rollup’s own path.

Practical questions about Across

Do I need ACX to use the Across bridge?: No. A standard bridge transaction spends the selected input token and the origin chain’s native gas token, while relayer and liquidity-provider compensation comes from the quoted output amount, so users don’t need ACX unless they separately choose an activity that specifically uses the token itself.
Which network token pays gas for an Across transfer?: The origin network’s native token pays gas for a standard wallet-submitted deposit. ETH pays on Ethereum, Arbitrum, Base, and Optimism; POL pays on Polygon. The relayer covers destination execution gas and recovers that expense through the quoted relayer fee, placing it inside the output calculation.
Can an Across transfer send tokens to a different recipient?: Yes. The depositor and recipient are separate fields in the Across intent, so the destination token can go to another compatible address. The quote must contain the intended recipient before signing, and that address must be valid on the destination chain. Refunds follow the configured refund address, which is a separate choice.
Does an ERC-20 approval remain after the bridge transaction?: An ERC-20 approval remains only to the extent that allowance survives the SpokePool’s transferFrom call. An approval equal to the transferred amount falls to zero under standard allowance accounting; a larger or unlimited allowance remains until the token holder changes it. The approval concerns that specific token contract and spender on the origin chain.
Is a smart-contract recipient compatible with Across messages?: Yes. An Across intent can carry an optional message for a contract recipient, enabling destination execution after the token fill. The receiving contract implements handleV3AcrossMessage, and the calldata must match its expected interface. Plain externally owned accounts receive tokens without that message, while embedded actions use MulticallHandler to coordinate approved destination calls.