Across protocol is an intent-based bridge powered by relayers

Updated July 2026

Across protocol is a bridge where an intent states the destination result you want, while a relayer fronts the funds and receives repayment after settlement. It moves supported fungible assets among Ethereum, Layer 2 networks, and other listed chains without making the user wait for final rebalancing. The quoted output, route limits, and available liquidity decide whether a transfer proceeds.

That design makes speed a delivery property, not a promise that every route shares the same economics. A useful review therefore starts with chain identity and quote details, then examines relayer behavior, settlement, limits, and alternatives.

In short: It is an intent-based cross-chain bridge for moving assets between Ethereum and L2s, using relayers to front funds while routes depend on relayer liquidity.

Verify chain and token identity before signing

The most common Across protocol mistake is approving a route after reading only the token symbol, without confirming the origin chain, destination chain, recipient, and final output amount. Each of those fields changes what the transaction authorizes.

Chain IDs remove ambiguity. Ethereum uses chain ID 1, Optimism 10, Arbitrum One 42161, Base 8453, Polygon PoS 137, and Linea 59144. Those identifiers are not amounts, so they never take thousands separators. Token precision adds another check: USDC commonly uses 6 decimals, meaning 1 USDC equals 1,000,000 base units; WETH and DAI use 18 decimals, while WBTC uses 8. The quote must bind the exact token contract on each chain because matching symbols alone do not establish a valid route.

Read the destination recipient last. That final check catches a correct route pointed at the wrong account or an incompatible contract.

The quote exposes cost before approval

An Across protocol quote states the input amount, expected output, route limits, and fee components before the wallet submits a transaction. The difference between input and output represents the transfer's quoted cost in token terms.

Liquidity-provider pricing

The liquidity-provider fee follows a utilization curve adapted from lending markets such as Aave. Pricing rises after a route crosses its utilization kink because rebalancing becomes harder. The annualized curve is converted through 52 weekly periods for fee calculation. When a relayer takes repayment on the origin chain, the route requires no cross-chain rebalancing and the liquidity-provider fee is 0.

Relayer compensation

The relayer component covers destination gas, the time value of capital, and settlement exposure. It changes with the destination network, transaction size, reimbursement path, and available inventory. Integrators may add an app fee expressed from 0 to 1; an app-fee value of 0.01 represents 1%. Users should compare the final output amount, rather than combining displayed percentages independently.

Stablecoin and ETH routes cover the main transfer jobs

Across protocol primarily serves supported fungible-token transfers, cross-chain swaps, and application flows that need funds delivered before slow settlement completes. Common route candidates include USDC, USDT, DAI, WETH, WBTC, and other assets returned by the live quote interface.

Stablecoin movement is the clearest use case because a user frequently wants native liquidity on another network rather than a wrapped bridge representation. The Swap API also supports an origin-side swap when the supplied asset is not directly bridgeable. An application may pair delivery with a destination action, such as depositing into Aave or trading through Uniswap, provided the quoted route supports that call. Solana routes require a valid base58 recipient, while EVM routes use hexadecimal addresses.

A wallet transfer follows a short, observable path

A first Across protocol transfer starts with a fresh route quote, continues through any required ERC-20 approval, and finishes when a relayer fills the deposit on the selected destination chain. Each step produces information that the user can inspect.

The interface needs an input token, output token, amount, origin chain, destination chain, and recipient. After the wallet confirms the approval when required, it submits the deposit transaction to the origin SpokePool. An EVM address contains 20 bytes and is normally displayed as 40 hexadecimal characters after its prefix. A transaction hash contains 32 bytes, displayed as 64 hexadecimal characters. Saving that hash makes the deposit traceable through pending, filled, expired, and refunded states.

Deposit addresses provide a separate path for exchanges, payment services, and automation that cannot request an interactive wallet signature. Each generated Across deposit address has a 24-hour time-to-live and is intended for one quoted transfer. A fresh address preserves the expected token, chain, amount range, recipient, and refund settings.

Do not reuse an old deposit address. Its monitoring window and quoted conditions belong to the original transfer.

A five-point route check prevents avoidable reversals

A short pre-signing checklist gives an Across transfer a clear decision boundary before funds leave the origin network. Every item should match the quote that the wallet is about to execute.

1. Confirm the wallet is connected to the quoted origin chain and not merely displaying the same token symbol elsewhere.
2. Match the destination chain, token contract, and recipient against the intended account or application.
3. Compare input amount, minimum output, total fees, and any route limit shown by the quote.
4. Check that the recipient can control the asset and handle any attached destination contract call.
5. Save the origin transaction hash and wait for a filled status before repeating the transfer.

This check is especially useful when moving USDC among Base, Arbitrum, Optimism, and Ethereum, where the asset name looks familiar across several distinct contracts.

Relayers convert a deposit into fast destination delivery

In that configuration, Across relayers monitor origin deposits, evaluate their economics, and submit destination fills using inventory that they already control on the receiving chain. Users therefore receive the quoted output before relayer reimbursement and pool rebalancing finish.

Under the V3 deposit model, a relayer completes one entire intent rather than making partial fills. A nominated relayer may receive temporary exclusivity through the deposit's exclusive-relayer address and exclusivity deadline. Once that period expires, another relayer can fill an outstanding order before its fill deadline. Competition concerns execution speed, while the quote fixes the output that a valid fill must deliver.

Settlement repays relayers after users receive funds

Barring an unusual setup, Across settlement separates destination delivery from reimbursement by grouping validated fills into bundles, processing them through Ethereum, and rebalancing liquidity through canonical bridges. That separation is the central mechanism behind its intent-based workflow.

SpokePools record deposits and fills

A SpokePool exists on each supported chain involved in the Across settlement system. Origin SpokePools record user deposits, while destination SpokePools accept matching fills. Validation compares the input and output tokens, amounts, chain identifiers, recipient, deadlines, message data, and deposit identifier before a relayer refund is recognized.

The HubPool and data worker aggregate activity

The HubPool on Ethereum coordinates liquidity and bundle execution. An off-chain data worker gathers fills across supported chains, validates them against deposits, and constructs Merkle trees for repayment and rebalancing. An Across root bundle contains three Merkle roots and is published at intervals of at least 1.5 hours. Aggregation changes settlement verification from an O(N) per-fill pattern to an O(1) bundle operation.

UMA verification and canonical bridges finish settlement

Bundle proposals use optimistic verification secured through UMA. A proposal carries a bond and passes through a challenge period before execution. After finalization, relayers claim refunds on their selected repayment chains, while canonical bridges move pooled assets between Ethereum and connected networks. Delivery speed and settlement speed therefore remain separate measurements.

The security model has several concrete dependencies

The Across protocol security model combines audited smart contracts, bonded optimistic verification, independent relayers, Ethereum settlement, and canonical rebalancing paths. A transfer still depends on the origin chain, destination chain, token contracts, and quoted route remaining operational.

User exposure begins with the approval and deposit transactions. An ERC-20 allowance remains active until it is consumed, replaced, or reduced, so its amount deserves the same attention as the bridge quote. A large route also depends on relayer inventory and pooled liquidity; thin inventory produces a lower limit, a longer estimate, or no executable quote. Embedded destination actions add the target application and its contracts as further dependencies. If an intent reaches its fill deadline without delivery, the deposit enters the settlement-based refund process instead of returning immediately.

Route limits are functional controls. They show where available capital, gas economics, and settlement timing support the requested transfer.

ACX governance and liquidity provision serve different roles

ACX participation and Across liquidity provision affect protocol coordination and capital supply, while the bridge itself serves users who want a quoted cross-chain outcome. Across DAO governance uses ACX for protocol decisions, and Ethereum-based pools supply capital that supports relayer repayment flexibility.

Liquidity providers accept smart-contract, utilization, and withdrawal-timing risk in exchange for market-dependent fees. Their capital does not sit on every destination chain waiting for each user; it supports reimbursement and later rebalancing through the HubPool. Reward rates, pool utilization, and withdrawal availability move with protocol activity, so they require a fresh position-level view rather than a durable headline figure.

Canonical bridges, CCTP, and liquidity networks answer different needs

For a first attempt, Across protocol competes with canonical rollup bridges, issuer-controlled transfer systems, and other liquidity networks on workflow, delivery speed, asset representation, settlement dependency, and route coverage. The right alternative follows the user's required asset and destination.

Canonical rollup bridges prioritize native settlement

The Arbitrum Bridge and Optimism's native bridge follow their respective rollup settlement paths. They are direct choices for moving assets between Ethereum and one rollup, especially when the user accepts the native withdrawal period. Across uses relayer capital to deliver sooner, then relies on canonical infrastructure later for rebalancing. The subject is unpacked Inside protocol.

Circle CCTP specializes in native USDC

Circle Cross-Chain Transfer Protocol burns USDC on the source chain and mints native USDC on the destination after attestation. That focused model avoids a liquidity-pool representation for supported USDC routes. It fits issuer-supported USDC transfers, while Across presents a broader quote interface spanning additional assets, swaps, and application actions.

Stargate, Hop, and Wormhole use different dependencies

Stargate routes through liquidity pools and LayerZero messaging, Hop Protocol uses automated market makers and Bonders for supported routes, and Wormhole Portal supports token transfers through Wormhole infrastructure. Compare the delivered token contract, supported chain pair, transaction sequence, and finality model. Brand familiarity does not substitute for an executable route to the intended asset.

Route limits decide the final user fit

Where it matters, Across protocol fits best when a live quote covers the exact chain pair, token contracts, amount, recipient, and deadline that the user needs. A missing quote is a route constraint, not an invitation to substitute an unlisted contract.

The approval response supplies minimum and maximum amounts, expected output, fees, estimated fill time, and transaction data for that moment. The tracking model then exposes four main lifecycle states: pending, filled, expired, and refunded. Large transfers, unusual token pairs, or limited relayer inventory require closer attention to maximum instant-fill capacity. The strongest fit is a supported route whose output and dependencies remain clear before the origin transaction is signed.