Across Across is a Crosschain Intent Bridge for Relayer Fills and Settlement
Across is a bridge between blockchains where users request an outcome and relayers advance the destination tokens. Technically, it is an intent-based interoperability protocol: an origin SpokePool escrows the input, a relayer fills the destination from its own inventory, and settlement later repays that relayer. This separation makes the user-facing transfer fast while Ethereum, UMA's Optimistic Oracle, and canonical bridges handle verification and liquidity rebalancing behind the fill.
Across Relayer Fills Versus the Optimism Standard Bridge
On the same footing, Across relayer fills suit a withdrawal that values immediate destination liquidity, while the Optimism Standard Bridge suits a user willing to wait for canonical settlement. A withdrawal from OP Mainnet to Ethereum through the Optimism Standard Bridge waits 7 days before finalization.
The trade is different, not merely faster. A canonical bridge follows the rollup's native message path and releases assets after its prescribed verification sequence. Across advances liquidity before its own later settlement, so the user accepts the protocol's relayer, SpokePool, liquidity, and optimistic-oracle model. Ethereum uses chain ID 1, while OP Mainnet uses chain ID 10; the selected direction decides which contract receives the deposit and where gas is paid. Choose the Standard Bridge when canonical timing is acceptable. Choose Across when usable destination funds now justify the quoted spread, which is treated Across walkthrough.
Preparing the Origin and Destination
A valid Across transfer starts with one supported route, the correct token contracts on both chains, enough origin gas, and a destination address that can receive the output.
Select the Exact Asset
Network names, chain IDs, and token contracts must agree with the quote. Ethereum is chain ID 1, Arbitrum is 42161, Base is 8453, Optimism is 10, and Polygon PoS is 137. The interface lists only route combinations it can quote, so a familiar ticker doesn't override the contract address attached to that entry.
Fund Origin Gas
A fresh ERC-20 allowance adds one approval before the deposit, producing two wallet confirmations. A sufficient allowance leaves one origin transaction. ETH covers gas on the four named EVM networks except Polygon PoS, which uses POL. Keep gas outside the transfer amount.
Read the Output Floor
USDC uses 6 decimal places, while WETH uses 18; one USDC therefore equals 1 000 000 base units. Across offers three quote modes: exact input, minimum output, and exact output. A minimum-output quote sets the smallest acceptable receipt after routing and fees. The next decision is whether that floor covers the destination action you intend to perform.
The Four-Stage Transfer Path
The Across transfer path is decided at quotation: a viable route then moves through approval or deposit, destination fill, and delayed protocol settlement in four operational stages.
| Stage | Protocol Action | Hard Limit or Threshold |
|---|---|---|
| 1. Quote | The route fixes chains, tokens, recipient, amounts, and deadlines. | One origin chain and one destination chain per quote |
| 2. Deposit | The SpokePool escrows the signed input on the origin. | The fill deadline is a uint32 Unix timestamp |
| 3. Fill | A relayer sends its own inventory through the destination SpokePool. | One complete fill; V3 has no partial fills |
| 4. Settlement | The HubPool verifies a bundle and enables reimbursement. | Three Merkle roots cover refunds, rebalancing, and slow fills |
Protocol limits are explicit.
Across V3 encodes the fill deadline as a 32-bit unsigned timestamp and completes each intent with one full fill rather than partial fills.
Developers using the ERC-7683 AcrossOriginSettler pass three top-level values to open(): the deadline, a 32-byte data type hash, and encoded order data. The Across order payload then carries seven route values, including the output token, amount, destination chain, recipient, exclusive relayer, exclusivity deadline, and message.
How Is an Across Fee Quote Calculated?
An Across quote is acceptable only when its output amount clears the user's minimum, because total cost appears as the gap between deposited input and delivered output.
Relayer Compensation
The relayer fee covers three inputs: destination gas, capital opportunity cost, and the exposure carried while fronted inventory awaits repayment. The documented bundle cadence is roughly 1.5 hours, so settlement timing contributes to the price a relayer accepts for a route.
Liquidity Provider Charge
This is set out Across setup. The liquidity provider fee pays for utilization and rebalancing through the Ethereum HubPool. Across converts an annualized utilization rate into a weekly rate using 52 periods, then applies that rate to the transfer size. The LP fee is 0 when the relayer requests repayment on the origin chain because no crosschain pool rebalancing is required for that fill.
Reading Programmatic Quotes
Integrations receive the same two protocol components: the LP fee and relayer fee. Percentage fields use 18-decimal fixed-point scaling, where 10 18 represents 100% and 10 16 represents 1%. Quotes expire, so an application must use the returned calldata and deadline together rather than preserving an old fee response.
Settlement Through HubPool and UMA
Correct Across settlement depends on destination fills matching origin deposits, so a Dataworker aggregates events and submits a bonded root bundle to the Ethereum HubPool.
Bundle Construction
The Dataworker matches amounts, token identifiers, recipients, chains, and fill records before building payment and rebalancing trees. Each Across root bundle contains three Merkle roots for relayer refunds, pool rebalancing, and slow fills. Aggregation keeps bundle verification at O(1) rather than charging an O(N) settlement operation for every included fill.
Optimistic Verification
UMA's Optimistic Oracle accepts a bonded bundle after its challenge window unless a monitor disputes it. The 1-of-N security assumption requires one honest participant to identify an invalid proposal, after which UMA's Data Verification Mechanism resolves the disagreement.
Repayment and Rebalancing
Relayers choose a supported repayment chain rather than receiving funds only where they filled. The HubPool accounts for that choice, and canonical bridges move liquidity between Ethereum and SpokePools after finalization. Native USDC rebalancing also uses Circle's Cross-Chain Transfer Protocol on configured routes. User delivery has already occurred at this point; this background cycle restores relayer inventory and pool balance for later transfers.
Primary Uses for Transfers, Swaps, and Calls
Across fits a transaction when the desired destination outcome is clear before signing, especially for same-asset transfers, crosschain swaps, and contract calls bundled after delivery.
- Move native USDC from Arbitrum to Base when that pair appears in the quote.
- Exchange an origin asset for a different destination asset within one routed transaction.
- Send the output to a recipient address that differs from the depositor.
- Bridge and execute an Aave deposit through the destination MulticallHandler.
- Publish an ERC-7683 intent through AcrossOriginSettler for contract-level integration.
These cases share one requirement: the quote must express the final token, minimum amount, recipient, and destination chain before the origin signature. The Swap API handles routing and approval calldata, while ERC-7683 gives applications a standard order interface also associated with Uniswap's crosschain intent work. Choose the interface that matches who constructs and submits the order.
Verification Across Two Chain Receipts
For an EVM route, Across verification is complete only when the origin deposit and destination fill agree on token, amount, recipient, and chain identifiers in both receipts. An EVM address occupies 20 bytes and normally appears as 42 characters including 0x; a transaction hash occupies 32 bytes and appears as 66 characters. Match the destination token contract rather than the ticker alone, then confirm the filled amount and recipient in the destination event. That evidence decides whether the transfer is ready for its next on-chain use.
Deadlines, Liquidity, and Execution Boundaries
The main Across trade-off appears when relayer liquidity, route economics, or destination execution can't satisfy the signed output before its fill deadline on the chosen chain.
A large output or thin route can exceed the instant-fill limit, causing the quote to return a slower path or no executable route. If the deadline passes without a fill, the escrowed input becomes eligible for a refund; Across then processes it through bundle settlement, the oracle window, and canonical messaging. That return takes several hours rather than following the fast-fill path. A destination message also adds contract-call correctness to the signed outcome. Meanwhile, an ERC-20 allowance remains an on-chain permission until its token logic spends, reduces, or replaces it. These boundaries decide whether to accept the relayer route or use a canonical path.
Choosing Among CCTP, Stargate, and Canonical Bridges
The strongest Across alternative depends on whether the transfer needs broad token routing, issuer-native USDC movement, or a chain's canonical security path for final settlement.
Circle CCTP burns USDC on the source and mints native USDC 1:1 on the destination, making it a focused choice for that asset. Stargate coordinates several route types over LayerZero, including liquidity-pool, Omnichain Fungible Token, and CCTP paths. Its V2 taxi mode sends an immediate message, while bus mode batches between 2 and 10 passengers. The Optimism Standard Bridge and Arbitrum Bridge follow their respective rollups' canonical withdrawal processes.
Under normal conditions, Across stands apart when relayer-funded speed, a quoted crosschain swap, or an embedded destination call matters more than using one issuer or one rollup's native bridge. CCTP narrows the mechanism to USDC, Stargate selects among its configured routes, and a canonical bridge follows the chain's base settlement path. The asset, destination action, and acceptable wait determine the right mechanism.
Quick answers about Across
Do I need ACX to make an Across transfer?
No, an ordinary Across transfer doesn't require the ACX token. The user needs a supported input asset, the origin chain's native gas token, and enough balance for the quoted amount. Protocol fees are reflected in the difference between input and output, rather than collected through ACX. ACX serves protocol governance, so holding it relates to voting participation, not eligibility to submit a bridge or swap transaction.
Must the destination wallet hold gas before receiving tokens from Across?
No, a destination wallet doesn't need native gas merely to receive a simple Across transfer. The relayer submits the destination fill and pays that transaction's gas, which the quote incorporates into relayer compensation. The recipient will need the destination network's native gas asset for a later transaction, such as swapping, lending, or sending the received token. An embedded action handles its configured destination execution inside the quoted flow.
May the Across recipient differ from the depositing wallet?
Yes, an Across quote can name a recipient that differs from the depositor. The recipient becomes part of the signed route data, and the relayer delivers the destination output to that address. This supports payments, treasury transfers, and transfers into another controlled account. The refund address is a separate field and belongs on the appropriate refund chain, so integrations shouldn't assume that depositor, recipient, and refund address always match.
What credentials are required for an Across Swap API integration?
A production Across Swap API integration requires a Bearer API token and a 2-byte hexadecimal integrator ID. The token authenticates each request, while the integrator ID identifies the application constructing the quote. The response then supplies allowance checks, optional approval transactions, executable swap calldata, fees, and a quote-expiry timestamp. Frontends must keep credentials out of client-visible storage and build each transaction from a fresh response.
Does Across support Solana as well as EVM chains?
Yes, Across includes Solana in its crosschain routing system, while individual token and direction combinations remain quote-dependent. EVM destinations use 20-byte hexadecimal addresses, whereas Solana uses base58 public keys, so an integration must preserve the address format returned for that chain. The supported-chain and supported-token responses determine actual compatibility for a transfer. A ticker match alone doesn't establish that a route exists between two networks.
When should an ERC-20 allowance be changed after using Across?
An ERC-20 allowance should be changed when its remaining amount exceeds what the owner wants the quoted Across spender to retain. Approval state lives in the token contract and can remain after the bridge completes, subject to that token's allowance behavior. Exact-amount approval limits the permission to the planned input, while an existing adequate allowance avoids another approval transaction. Use the spender supplied by the fresh quote because routing contracts can differ by chain and path.
Why can an Across route stop returning a quote?
An Across route stops returning a quote when the selected chain-token pair is unavailable, the amount falls outside executable limits, liquidity can't support the requested output, or a network route has been disabled. Gas, swap depth, and relayer inventory also change the economics behind a valid response. Rechecking the exact token contracts and amount separates a compatibility issue from a temporary capacity limit. An old quote shouldn't be reused because its deadline and calldata belong together.