Across protocol is fast because relayers front destination capital

V4 brings universal ZK settlement to new chains

Absent anything unusual, Across V4 makes chain settlement more uniform by proving Ethereum state through Succinct SP1 instead of writing a canonical-bridge adapter for every new deployment.

V4 changes only phase 3 of the protocol’s 3-phase lifecycle, leaving the quote and relayer fill experience intact. BNB Smart Chain, chain ID 56, became the first deployment using this ZK settlement design. After Ethereum reaches finality, a process described as taking 12–15 minutes, the Finalizer prepares proof inputs. These include signatures from Ethereum’s 512-validator sync committee and a Merkle proof for the relevant HubPoolStore slot. The proof service tracks 4 states, from waiting for finality through success or error, before settlement reaches the destination chain.

Finalization then uses 2 destination transactions: one updates the SP1Helios light client, and the other lets UniversalSpokePool execute the verified message.

Relayer fills versus canonical bridges and native minting

Across delivers the quoted asset from relayer inventory, while canonical bridges and token-native systems complete crosschain movement through different settlement paths.

Arbitrum and Optimism canonical withdrawals to Ethereum pass through a 7-day challenge window, so their protocol-native route favors direct rollup settlement over immediate delivery. Circle CCTP burns USDC on the source chain and mints native USDC on the destination, making it narrower by asset but strong for that stablecoin.

Wormhole uses a Guardian-verified messaging model, while Stargate uses LayerZero messaging with liquidity-based transfer infrastructure. These systems answer different questions: token portability, arbitrary messaging, liquidity routing, or fast user outcomes. In contrast, CCTP’s burn-and-mint path avoids a shared liquidity pool, while Stargate depends on route liquidity and Wormhole focuses on verified messages.

The Across Swap API can choose among 3 mechanisms - intent fills, CCTP, and Omnichain Fungible Token routing - when the requested assets and chains allow them. A quoted outcome therefore matters more than assuming every route uses identical contracts underneath.

Five actors separate delivery from repayment

Five participant roles let Across protocol give the user a fast fill without forcing repayment and verification into the same transaction.

The user deposits into an origin SpokePool and names the destination outcome. A relayer sees the deposit event, evaluates the quote, and supplies its own tokens to the destination SpokePool. Liquidity providers place capital in the HubPool on Ethereum, supporting later rebalancing and repayment. An offchain Dataworker matches deposits with fills, builds Merkle trees, and proposes a bonded bundle. UMA’s Optimistic Oracle supplies the economic verification layer. Each role has a narrow job, so destination delivery does not wait for the entire accounting cycle. The user sees 1 quoted output while these back-office roles complete their work on different timelines.

Relaying is permissionless. Competition centers on fill speed because the current request-for-quote layer presents fixed quoted terms rather than a visible user auction.

Batched settlement reuses Ethereum liquidity

Set against that, Across settlement groups completed fills before reimbursing relayers, allowing one Ethereum liquidity hub to support many origin and destination SpokePools.

The lifecycle has 3 phases: initiation escrows the deposit, filling transfers destination funds, and settlement validates the match and repays capital. Another 3 layers divide the request for quote, competitive relaying, and settlement, letting each part evolve without changing the desired output. Across consolidates every fill in a period into 1 bundle, so settlement remains O(1) rather than growing O(N) with the fill count. Bundles are proposed on an interval described as approximately 1.5 hours at minimum. Relayers choose an eligible repayment chain, while canonical bridges or V4 proof delivery move finalized instructions where required. Aggregation prevents every fill from demanding its own Ethereum verification cycle.

How do fees reach the final quote?

An Across quote subtracts the destination output from the origin input, then allocates the difference between liquidity-provider and relayer compensation.

The relayer portion covers 3 inputs: destination gas, the opportunity cost of committed capital, and settlement risk. The liquidity-provider fee responds to utilization and rebalancing needs. It becomes 0 when the relayer accepts repayment on the origin chain because no crosschain pool rebalancing is needed. Origin-chain gas remains a separate wallet cost, while an integrator can add an app fee from 0 to 1, where 0.01 represents 1%. Across converts the annualized LP curve into a weekly rate with a 1/52 exponent before applying it to transfer size. Route utilization selects the curve inputs.

Worked example. The hypothetical changing inputs are a 1,000 USDC deposit, a quoted output of 998.20 USDC, and origin gas worth 0.30 USDC. The bridge spread equals 1,000 minus 998.20, or 1.80 USDC. Adding origin gas produces a concrete total cost of 2.10 USDC, while 998.20 USDC reaches the destination. Relative to the input, the combined cost is 0.21%. A live quote replaces all three changing inputs before signing.

A transfer from quote to destination receipt

An Across transfer starts by matching a supported origin chain, destination chain, input token, output token, recipient, and amount in a fresh quote.

Chain identity is exact. Ethereum uses chain ID 1, Optimism uses 10, and Polygon uses 137.

Base uses chain ID 8453, while Arbitrum uses 42161. Token contracts are also chain-specific, even when the symbol stays USDC. The interface or Swap API resolves those details and returns the expected output, minimum output, approvals, transaction data, and estimated fill time.

• Read the origin and destination selections as a pair.
• Confirm the output token and full recipient address.
• Compare the input, quoted output, and separate origin gas.
• Keep the deposit transaction hash until the status reports filled.

ERC-20 transfers need an allowance for the quoted spender; native-token transfers do not use an ERC-20 approval. The user then signs the origin transaction, and a relayer delivers the destination asset after the deposit appears.

Embedded actions turn a bridge into one transaction

As a rule, Across embedded actions attach destination instructions to a crosschain transfer, allowing delivery and a contract interaction to complete as one user-initiated flow.

A nonempty message directs the destination SpokePool to the MulticallHandler, which executes encoded calls after the relayer supplies funds. One established pattern moves USDC from Arbitrum, swaps it to ETH on Ethereum, and deposits the ETH into Aave, leaving the recipient with an aWETH position. The user signs on the origin chain rather than separately bridging, swapping, and depositing on the destination. Direct wallet transfers, native stablecoin movement, liquidity deposits, and application onboarding use the same outcome-led model. Atomic destination execution keeps delivery and the attached action inside one coordinated flow. The same ground is retraced in practice.

Deadlines, liquidity limits, and refunds define the edges

Under normal conditions, Across transfers remain bounded by a quoted fill deadline, route liquidity, token support, and the exact recipient data committed in the deposit.

Each V3 intent receives only 1 fill, and partial fills are not supported. The status service exposes 4 central outcomes: pending, filled, expired, and refunded.

If no relayer fills before the deadline, the origin funds remain escrowed while the Dataworker includes the expired deposit in a later bundle. Refund processing then includes the approximately 1.5-hour bundle interval, the oracle challenge period, and any canonical delivery delay, so completion takes hours rather than seconds.

Quote limits matter most for very small amounts, where destination gas dominates, and large amounts, where relayer inventory becomes the constraint. A fresh quote supplies route-specific minimum and maximum values. The recipient, refund address, token contract, and chain must all match the intended outcome because a completed onchain fill has no general reversal step. The standard refund target is the depositor, and origin-chain refunding is the default configuration. This is set out About Protocol.

ERC-7683 opens a builder-level path

In that configuration, Across implements ERC-7683 through AcrossOriginSettler, giving contracts a standard way to open crosschain intent orders without constructing a custom route.

The open function accepts 3 parameters: a fill deadline, a 32-byte EIP-712 order-data type, and ABI-encoded order data. Across order data carries 7 destination details: output token, output amount, destination chain ID, recipient, exclusive relayer, exclusivity deadline, and message. The settler validates the package and creates the underlying SpokePool deposit. This path suits onchain composition, while the Swap API handles quote construction, approvals, gas estimation, and executable transaction data for most interfaces. Amounts use token base units: USDC on Ethereum, Base, and Arbitrum has 6 decimals, so 1 USDC is encoded as 1,000,000 units; ACX and ETH use 18 decimals.

ACX governs changes rather than paying bridge gas

ACX is the Ethereum ERC-20 governance token for Across, while transfer fees remain denominated through the assets and gas costs in each route.

The token launched with an initial supply of 1,000,000,000 ACX and uses 18 decimal places. ACX voting power covers protocol parameters, upgrades, and DAO treasury decisions. Snapshot supports offchain voting, while oSnap provides an optimistic path for executing approved decisions onchain. Holding ACX is not a prerequisite for requesting a bridge quote, running a basic transfer, or receiving a relayer fill.

At that point, Across began as a bridge before the ACX launch in 2022, then expanded toward a broader interoperability layer. ERC-7683, embedded actions, and V4 settlement reflect that shift from one transfer interface toward reusable crosschain infrastructure. The protocol’s history explains why a governance token, an intent standard, and an oracle-backed settlement system appear in one stack.

The capital-efficiency trade-off behind fast fills

During normal operation, Across gains speed by making relayers carry the temporary capital burden, while users receive destination funds before repayment accounting reaches final settlement.

This design links user cost to destination gas, relayer inventory, capital lockup, and pool utilization. It also concentrates accounting in the Ethereum HubPool and relies on bonded optimistic verification, with V4 adding ZK proof delivery for universal deployments. Relayers recover capital after bundling, so unified liquidity serves more routes without duplicating a fully funded pool for every chain pair. That arrangement rewards treasury discipline: a relayer with capital on the right chains can quote more efficiently. Circle CCTP fits a native-USDC burn-and-mint path, canonical Arbitrum or Optimism bridges preserve rollup-native settlement, and Wormhole supports broader messaging. Across protocol fits a quoted crosschain outcome where fast delivery, relayer competition, and composable destination actions outweigh waiting for underlying settlement.