Across is an Intents-Based Cross-Chain Bridge With Destination-Chain Verification

Fee preview turns the input into a destination promise

The Across fee preview converts one input amount into a precise output amount for the selected route. Origin-chain gas sits outside that token difference, so both figures matter when comparing the wallet debit with the destination credit.

Across defines the quoted bridge fee as input amount minus output amount, with liquidity, relayer capital and destination gas inside the bridge breakdown. A cross-token route may also show swap impact from the venue used before or after the bridge. Uniswap and 0x are real routing components that may appear when the chosen input and output assets differ.

The following worked example labels every changing input as hypothetical: route from Arbitrum to Base, input of 1,000.000000 USDC, output of 998.700000 USDC and quoted total origin gas of 0.000080 ETH. Subtracting output from input gives 1.300000 USDC inside the quoted spread. The wallet spends 1,000.000000 USDC plus 0.000080 ETH, while the destination recipient receives 998.700000 USDC. Because USDC uses 6 decimals, 1 token equals 1,000,000 base units; the amount field therefore encodes 1,000 USDC as 1,000,000,000 units. Don’t convert the separate ETH gas line into USDC without a live ETH price. The destination result remains 998.700000 USDC.

Refresh the preview after changing a chain, token, amount or recipient. Each edit creates a different execution request and a newly calculated output.

Wallet preparation fixes the origin-chain prerequisites

Wallet preparation starts with the origin network, spendable token balance and native gas balance. The recipient must also be valid for the selected destination ecosystem.

For an EVM route, MetaMask and Rabby use the chain’s EIP-155 identifier to select the signing network. Ethereum is chain ID 1, Optimism 10, Polygon 137, Arbitrum 42161 and Base 8453. The token must exist at the contract address that the route specifies on that chain; matching symbols aren’t sufficient. USDC uses 6 decimals while WETH uses 18, so equal displayed amounts have different integer encodings. A standard EVM address is 20 bytes, displayed as 40 hexadecimal characters after the 0x prefix.

For a standard ERC-20 flow without enough allowance, the wallet presents 2 origin transactions: 1 approval and 1 deposit. A native ETH route or an adequate existing allowance reduces the sequence to 1 deposit transaction.

Set the recipient before requesting the final quote. Changing it after the wallet opens makes the signed calldata disagree with the route that was reviewed. A sibling page explains it Across rewards.

What should the transfer preview show before confirmation?

The Across transfer preview should identify the entire route, final output and every wallet action before confirmation. An EVM-to-EVM preview binds 2 chain identities, 2 token contracts and 1 recipient address. A mismatch means the wallet will sign something other than the reviewed route.

Read the preview as one execution record. It should establish the input chain and token, destination chain and token, input amount, quoted output, recipient, fee breakdown, origin gas estimate and delivery estimate. The output amount is the token quantity promised by the intent; the time is an estimate of relayer delivery rather than a confirmation rule. If the route changes assets through Uniswap or 0x, inspect the swap-impact component separately from the bridge components. A minimum-output field matters on swap routes because it defines the accepted execution boundary. Those values form the route’s signing boundary.

Confirmation creates an origin-chain deposit

The confirmation transaction deposits the input asset into the origin SpokePool and publishes the transfer terms on-chain. An ERC-20 approval alone moves no bridge principal.

The V3FundsDeposited event records the depositor, recipient, input token, output token, both amounts, destination chain ID and time limits. Its input and output amounts are 256-bit unsigned integers. The deposit ID, quote timestamp, fill deadline and exclusivity deadline are 32-bit unsigned integers. Relayers use that event to discover the request and compare its terms with a possible destination fill. The contract lifecycle has 3 phases: initiation on the origin chain, fill on the destination chain and settlement for relayer repayment.

Save the confirmed origin transaction hash. The deposit exists only after the origin receipt succeeds and includes the Across deposit event, regardless of what the wallet’s pending screen says.

Destination verification proves the relayer fill

Destination verification requires the fill transaction reference, received token contract and recipient balance change. A success message without those details is incomplete evidence.

Realistically, Across exposes 4 principal transfer states: pending, filled, expired and refunded. Pending means the deposit has been indexed but no qualifying fill is recorded. Filled means a relayer completed the destination action. Expired means the fill deadline passed and refund processing becomes relevant, while refunded confirms the return transaction.

The status indexer checks relevant events on a 10-second cadence and normally reflects a submitted deposit within 1 to 15 seconds. That indexing interval isn’t the same as chain finality. Recheck after the origin receipt confirms, then follow the returned destination reference rather than resubmitting the deposit.

An EVM transaction hash is 32 bytes and appears as 64 hexadecimal characters after 0x. The destination SpokePool emits FilledV3Relay, and Across V3 permits 1 complete fill rather than partial fills. Etherscan, Arbiscan and BaseScan let a reader compare the recipient, token contract and transferred amount against the preview. The destination hash proves delivery; later protocol settlement repays the relayer without changing the recipient’s completed transfer.

A network mismatch is fixed before signing

The common setup error is a connected wallet network that differs from the preview’s selected origin chain. Resolve the mismatch before approving or depositing.

Switch MetaMask or Rabby to the preview’s origin network, wait for the wallet to report the corresponding chain ID and request a fresh quote. Don’t solve the prompt by changing the route unless that is the transfer you actually want. Allowance belongs to one token contract, spender and chain, so an approval on Ethereum doesn’t authorize the analogous USDC contract on Arbitrum. If the destination is Solana, its public key is 32 bytes and uses Base58 encoding; an EVM recipient is a different address format and requires a separate compatibility check.

Deadline, allowance and precision edge cases

Deadline, allowance and token precision define the edge cases that follow an otherwise valid preview. Each is encoded into a particular chain or transaction context.

A fill deadline is a Unix timestamp in seconds, not a countdown guaranteed by the wallet. Once it passes without a fill, the deposit moves toward the expired and refund states instead of accepting a late fast fill. An ERC-20 allowance remains scoped to its chain, token and spender until it’s used or changed. Exact approvals limit the authorized amount; broader approvals reduce repeated signatures but leave a larger allowance active. The sensible choice changes with the user’s intended reuse of that exact Across spender.

Precision also changes route arithmetic. Six-decimal USDC amounts divide by 1,000,000, while 18-decimal WETH amounts divide by 1,000,000,000,000,000,000. Compare human-readable output only after confirming both token contracts and decimal counts. If a preview becomes stale, rebuild it from the same recipient and route, then sign the new transaction data rather than relying on an older screenshot.