Across is an Intent-Based Crosschain Protocol with Relayer Fills

Across versus CCTP, Stargate and rollup bridges

Seven transfer approaches differ most in what crosses chains, who supplies destination liquidity and which delay or asset limit defines successful execution for the user. Across uses a complete relayer fill, while Circle CCTP burns and mints native USDC.

Circle CCTP is narrow and asset-native: it burns USDC on the origin domain and mints USDC after attestation on the destination. Stargate V2 uses LayerZero messaging with two transport modes. Taxi sends immediately, while Bus batches between 2 and 10 passengers. OP Mainnet, Base and ZKsync Era expose canonical withdrawal paths whose delay follows the rollup’s security design. Those routes make sense when the canonical mechanism or native USDC is the main requirement. Across is stronger when destination speed, crosschain swapping or a contract action matters more than using one bridge’s settlement path.

Wormhole Token Bridge and Hyperlane serve broader messaging or token-transfer architectures. They add different trust and deployment choices. A route decision should follow the asset representation, the destination action and the maximum acceptable wait. If the goal is a fast fill into Aave or another application, Across’s relayer path removes the canonical withdrawal delay from the user-facing step.

Set the route before the first transaction

Four route inputs - origin chain, destination chain, input token and output token - must be settled before a wallet signs because an Across quote binds every choice onchain.

Confirm the chain and token pair

Chain identity is numerical, not just visual. Ethereum is chain ID 1, Optimism is 10, BNB Smart Chain is 56, Base is 8453 and Arbitrum is 42161. Confirm that both selected token contracts belong to those networks and that the quote returns a route for the exact pair. USDC, USDT and ETH don’t share identical availability across every endpoint. The recipient must also be valid for the destination’s address format. A returned route connects these choices; an unsupported combination produces no executable deposit, so the next decision is whether to change the asset or destination.

Read the output and limits

Token amounts are integers in base units. Native USDC uses 6 decimals on Ethereum, Optimism, Base and Arbitrum. One USDC is encoded as 1,000,000 units. ETH uses 18 decimals and one whole ETH equals 10 ¹⁸ wei. The quote’s output amount already incorporates the selected route’s fees and any origin swap. Read the minimum output, recipient and refund address before signing, especially when the input and output tokens differ.

Approve, deposit and verify

This is set out Across walkthrough. A standard ERC-20 path uses at most two origin transactions when allowance is missing: one approval and one Across deposit. With sufficient allowance, the deposit is the only origin transaction. The Swap API also returns approval transactions when needed, which prevents guessing the spender or amount.

After confirmation, record the origin transaction hash and destination recipient. Verification means matching the destination chain, token contract, amount and FilledRelay event or deposit status - not merely seeing a wallet notification.

How do relayer fills turn an intent into destination funds?

Three phases turn an Across intent into destination funds: deposit escrows the input, a relayer completes one fill and settlement later repays that capital through bundles.

Deposit records the outcome

The V3 EVM depositV3 signature contains 12 arguments. They identify the depositor, recipient, input token, output token, input amount, output amount, destination chain, exclusive relayer, quote timestamp, fill deadline, exclusivity deadline and message. Its three time fields use uint32 encoding, whose largest unsigned value is 4,294,967,295. Amounts and the destination chain use uint256. Once accepted, the origin SpokePool escrows the input and emits the deposit data that relayers monitor. New non-EVM-compatible event formats expand address fields to bytes32 and the deposit identifier to uint256. Indexers must handle the deployed event version.

Relayer fronts destination liquidity

Relayers watch the deposit, price destination gas and decide whether the quoted output covers capital cost. The nominated relayer alone fills before an exclusivity deadline; afterward, another relayer is eligible. Across V3 accepts one complete fill per intent because partial fills were removed. A destination SpokePool records the fill once, then emits FastFill, ReplacedSlowFill or SlowFill as one of three execution types.

Settlement repays capital later

Relayer reimbursement is separate from user delivery. The dataworker groups validated fills into a Merkle bundle, the Ethereum HubPool handles repayment instructions and canonical bridges rebalance SpokePools. Bundle proposals operate on a cadence near 1.5 hours, so relayer capital stays committed beyond the user-facing fill. If the relayer requests repayment on the origin chain, the LP fee is zero because no crosschain rebalancing loan is required.

Fees follow liquidity use and destination execution

Two protocol fee components determine an Across quote: the LP fee prices rebalancing liquidity and the relayer fee covers destination execution, capital time and risk.

The displayed total equals input amount minus output amount. The LP curve follows an Aave-style two-slope model with utilization U between 0 and 1 and a kink where pricing steepens. Its annual rate is converted across 52 weekly periods before applying the transaction size. Same-chain relayer repayment makes the LP component 0 because capital doesn’t cross chains. Destination gas, relayer inventory and reimbursement timing set the other component, which is why a Base fill and an Ethereum fill don’t carry identical economics.

Fee percentages in the V3 response use 18-decimal fixed-point scaling: 10 ¹⁸ represents 100% and 10 ¹⁶ represents 1%. The fee response also returns minimum and maximum route limits, an expected fill estimate and a flag when the amount is too low. Those values shouldn’t be cached because pool utilization and gas change. Compare the output amount and execution deadline together, then decide whether the route still fits.

What verifies a fill before relayers are repaid?

Three Merkle roots plus covered block ranges let Across verify relayer refunds, pool rebalancing and slow fills before the Ethereum HubPool releases settlement instructions onchain.

Across uses optimistic verification under UMA rules. A dataworker reconstructs deposits and fills, proposes the bundle and posts an ABT bond. Independent validators reproduce the Merkle trees under UMIP-157 and UMIP-179. Across’s 1-of-N model needs one honest validator to dispute an incorrect bundle during the challenge window. A disputed proposal goes to UMA’s Data Verification Mechanism; an undisputed one finalizes after the window.

Aggregation makes bundle verification O(1) with respect to fill count rather than an O(N) settlement transaction for every fill. That efficiency moves some timing risk to relayers and keeps users focused on the destination receipt. An unfilled intent follows the slow-fill or refund path after its deadline, so the original deposit can remain escrowed for several hours while the next bundle and canonical bridge actions complete. The operational checkpoint is the destination event and balance; later settlement status concerns reimbursement, not whether the recipient already received the fast fill.

From 2021 same-asset transfers to interoperable intents

Three product stages since 2021 moved Across from same-asset transfers to destination actions and then crosschain swaps with a minimum output chosen before execution onchain. The protocol now combines V3 relayer fills with V4 settlement paths: BNB Smart Chain, chain ID 56, uses Succinct SP1 proofs while existing routes retain the established hub-and-spoke model. The ERC-7683 draft uses ERC-7930 interoperable addresses and a solver-facing resolver, extending the shared intent language beyond one protocol. Choose Across when fast delivery and outcome-based routing outweigh a preference for a specific canonical bridge. The mechanics are laid out Across rewards.