Across Across is a Bridge Route Check From Quote to Verified Fill
Across is an intent-based bridge interface where a transfer begins with a route quote, continues through an origin-chain deposit, and ends when a relayer's destination-chain fill is verified. Before confirmation, the interface shows the selected chains, token pair, input amount, expected output, fee impact, recipient, and estimated completion time. The sender needs the asset plus native gas on the source chain. Once the deposit confirms, the destination fill becomes a separate on-chain record.
Run the Route From Wallet Connection to Deposit
The Across route starts by connecting a wallet, choosing the source and destination, selecting tokens, entering an amount, reviewing the quote, and authorizing the source-chain transaction.
Preparation has three parts: a compatible wallet, the input asset, and native gas on the origin chain. MetaMask and Rabby provide EVM wallet connections, while WalletConnect links many mobile wallets. Ethereum, Arbitrum, Base, and Optimism use ETH for gas; a Solana-origin route uses SOL. Ethereum uses chain ID 1, Optimism 10, Base 8453, and Arbitrum 42161. USDC uses 6 decimal places, while WETH uses 18. An EVM address is 20 bytes, rendered as 40 hexadecimal characters plus the 2-character 0x prefix.
- Connect the wallet and read the active network before selecting a route.
- Choose the origin chain, then confirm that the input balance appears there.
- Choose the destination chain and output token, checking the recipient field.
- Enter the amount and wait for the quote to populate every output field.
- Review the output, fees, time estimate, and network fee before confirming.
Nothing moves while these controls remain unconfirmed.
The wallet should show the same origin chain as the route card. A Base-to-Arbitrum transfer therefore starts on Base, chain ID 8453.
Read the Quote Before Signing
The quote defines the transfer that the wallet is about to authorize, so read its network pair, token contracts, amounts, recipient, fee breakdown, and timing estimate together.
Route and Amount Controls
A route binds the origin network, destination network, input token, and output token. Changing any one of those fields produces a different transaction request and cost profile. The subject is unpacked Across setup.
Network Pair
The From field identifies where the deposit executes and where source gas is charged. The To field identifies where the relayer delivers funds. A route from Ethereum to Optimism therefore starts on chain ID 1 and fills on chain ID 10.
Token Pair
Token symbols need their chain context because contracts differ across networks. The USDC contract selected on Arbitrum isn't the same contract address as USDC on Base, even though both tokens use 6 decimals. Read the input and output assets as two chain-specific selections.
Output and Fee Controls
Across groups bridge economics into 2 protocol components: the liquidity-provider fee and the relayer fee. The LP portion reflects pool utilization and rebalancing, while the relayer portion covers 3 inputs - destination gas, capital opportunity cost, and fill risk. On a same-token route, input minus output expresses the combined amount retained for bridge economics. The wallet's origin-chain gas charge sits outside that output calculation because the source network collects it separately. Re-read the quote after changing an amount, network, token, or recipient; the previous display no longer describes the new route.
Why Does Across Ask Me to Switch Networks?
On the same footing, Across requests a network switch because the deposit transaction must execute on the quote's origin chain, while the connected wallet might still point at a different network.
Rejecting the switch creates 0 transactions and spends 0 gas. Reopen the wallet's network selector, choose the exact origin chain, and return to the route card. MetaMask and Rabby expose the active chain near the account control; a WalletConnect session sometimes needs reconnection after an in-wallet change. Confirm that the wallet and route show the same network, then refresh the quote before signing because gas and route inputs continue to move. An Ethereum-to-Arbitrum deposit starts on Ethereum chain ID 1, not Arbitrum chain ID 42161.
The Origin Deposit Changes On-Chain State
Confirming the route creates the origin-chain state change: an ERC-20 allowance might come first, then the SpokePool receives the tokens, records the intent, and emits its deposit event.
For an ERC-20 input such as USDC, an insufficient allowance produces an approval request before the deposit. ERC-20 approval amounts use a 256-bit unsigned integer, as does the token amount supplied to the transfer. An existing allowance that covers the input removes that separate approval step. Native assets don't use an ERC-20 allowance. Read each wallet request by its function: approval lets the designated contract transfer a stated amount, while the deposit actually moves the input into the origin SpokePool.
The deposit call records the recipient, input and output tokens, amounts, destination chain, and fill deadline. Across represents the deadline as a 32-bit Unix timestamp. The origin tokens enter escrow, and the V3FundsDeposited event exposes the intent to relayers. The lifecycle then has 3 phases: initiation, destination fill, and settlement. User delivery finishes at the second phase; background settlement later verifies fills and reimburses relayers.
Each intent accepts 1 completed fill, recorded through FilledV3Relay.
Fill Verification Without Guesswork
Under normal conditions, Across fill verification requires two related proofs: the origin deposit exists with the quoted parameters, and a destination transaction delivered the output token and amount to the recorded recipient.
The standard deposit tracker exposes 4 lifecycle labels: pending, filled, expired, and refunded. Its indexer checks relevant events on a 10-second cadence, with a documented reflection delay of 1 to 15 seconds. The filled response includes the destination fill reference. An EVM transaction hash is 32 bytes, displayed as 64 hexadecimal characters after 0x, or 66 visible characters in total. Preserve the complete hash; a shortened wallet label isn't enough for exact matching across an interface, explorer, and support record, which is examined Across troubleshooting.
| Verification View | Confirmed Fact | Standard Record Count |
|---|---|---|
| Across status record | Lifecycle state and destination fill reference | 4 lifecycle labels |
| Origin-chain explorer | Successful deposit receipt and emitted event | 1 origin transaction hash |
| Destination-chain explorer | Recipient, token, amount, and successful fill receipt | 1 fill transaction hash |
Match each hash to the relevant chain. Etherscan shows an Ethereum origin receipt, Arbiscan shows an Arbitrum receipt, and BaseScan shows a Base receipt. For an Arbitrum-to-Base route, confirm the deposit on Arbiscan and the fill on BaseScan. A filled status means the recipient-side transfer completed; the relayer's later reimbursement belongs to protocol settlement. Those are separate events, so the user doesn't wait for the settlement bundle after 1 successful fill.
Keep a Route Record After Completion
A completed Across route remains auditable when its record retains the origin hash, chain IDs, deposit identifier, fill hash, recipient, token contracts, and delivered output amount.
Minimal Transfer Record
Keep 3 core references together: the origin transaction hash, the Across deposit identifier, and the destination fill hash. Add the two chain IDs because the same address format appears across many EVM networks. The quoted output and recipient provide the comparison values for the destination receipt. This compact record supports later accounting without relying on a wallet's activity feed, which might group approvals, deposits, and incoming transfers differently.
Keep the quote only as context; the two receipts carry the final on-chain facts.
Balance and Receipt Reconciliation
After a verified fill, switch the wallet to the destination network and inspect the exact output token. A token balance might remain hidden until its chain-specific contract is added to the wallet, while a portfolio screen can lag behind the block explorer. Compare the destination receipt's recipient, token contract, and amount with the quote instead of judging completion from one dashboard number. This operating pattern suits transfers that need a clean handoff between treasury, accounting, and technical review. For Arbitrum-to-Base USDC, the final reference is the Base fill receipt on chain ID 8453.
Across - common questions
What happens if I close the page after the origin deposit confirms?
Closing the page doesn't stop an Across transfer after the origin deposit has confirmed on-chain. Relayers discover the emitted deposit event and continue the fill independently of the browser session or wallet connection. Save the origin transaction hash before leaving. Returning to the history or status view should recover the record, and the same hash identifies the deposit if the interface session no longer shows it.
Does the recipient address need to equal the depositing wallet?
The Across protocol records the depositor and recipient as separate fields, so the destination address doesn't have to match the sending wallet. The route review must show the intended recipient before confirmation. For an EVM destination, the recipient is a 20-byte address rendered in that network's accepted format. Control of the source wallet authorizes the deposit; the destination address receives the relayer's fill.
When will an expired deposit return to the wallet?
An expired Across deposit returns through the protocol's refund process rather than through the original relayer fill. The deposit first reaches its fill deadline, then enters the settlement workflow, and the status changes from expired to refunded when the return completes. Refunds therefore take longer than a normal fill and are measured in hours, not seconds. The configured refund address and refund chain determine where the balance appears.
Why does a filled transfer still look missing in a wallet?
A filled Across transfer can look missing when the wallet is displaying the origin network, hiding the destination token, or serving a stale balance. Switch to the destination chain and compare the fill transaction's recipient, token contract, and amount. If the destination receipt succeeded, add the exact token contract to the wallet or refresh its network connection. The on-chain fill record settles the question even when the portfolio view lags.
