Across protocol is a crosschain bridge protocol for intent-based asset transfers

Across protocol is a crosschain delivery workflow in which the Swap API selects a route, returns executable transaction data, and tracks the destination fill. A user chooses origin and destination assets, connects the wallet holding the input, reviews the quoted outcome, confirms the deposit, and receives tokens at the recipient address.

Updated on 2026-08-11

A five-step route from wallet to destination balance

Five steps carry an Across protocol transfer from a connected origin wallet to a confirmed destination-chain token balance.

First, open the bridge-and-swap interface or an application powered by the Across Swap API. Connect the wallet that already holds the source asset, then select the origin chain, input token, destination chain, output token, and amount. Direction matters because identical tickers sit at different contract addresses on different networks.

Next, the application requests a route. A fully explicit request combines 7 values: origin chain ID, destination chain ID, input-token address, output-token address, amount, depositor address, and trade type. The API classifies the path as 1 of 5 routing shapes, covering direct bridgeable assets, indirect bridgeable paths, origin swaps, destination swaps, or swaps on both sides. It then returns the balance and allowance checks, any approval transactions, the executable swap transaction, a delivery estimate, and the quote’s expiry timestamp.

After any requested approval confirms, sign the 1 main deposit transaction on the origin chain. The transaction records the desired destination outcome. A relayer then supplies its own destination-chain liquidity and completes the fill for the named recipient while settlement continues behind the interface.

Finally, track the deposit until the destination fill appears, then confirm the output-token balance in the recipient wallet. This route-led sequence is shorter than coordinating a source swap, separate bridge, and destination swap as independent operations.

Two route fields that prevent a chain mismatch

Two chain selections anchor an Across route: the network holding the asset and the network receiving it, as covered Across protocol security.

Ethereum uses chain ID 1, Optimism 10, Polygon 137, Arbitrum 42161, and Base 8453. These identifiers tell a wallet and contract which ledger should process the origin transaction; they don’t describe token availability. An EVM address represents 20 bytes and normally appears as 40 hexadecimal characters after the 0x prefix, yet the same address can hold different balances on each chain. Select the network first, then choose the token contract returned for that network. The live route menu is more dependable than a remembered list of supported pairs.

Wallet readiness before requesting the route

Three prerequisites prepare an Across wallet: the input asset, origin-chain gas, and authority to sign transactions.

The standard EVM path works with a self-custody wallet connection such as MetaMask, Coinbase Wallet, or WalletConnect. The wallet needs the input token and enough of the origin network’s native asset for approval and deposit gas. The signer must also control the depositor address used in the quote. A destination gas balance isn’t required merely to receive an ERC-20 fill, because the relayer submits the destination transaction.

Direct use of the Across interface doesn’t require an API credential. A production application calling the Swap API uses a Bearer key and a 2-byte integrator ID, while its user still signs with a wallet. Keep the API identity and wallet identity separate: one authenticates the integration, and the other authorizes the token movement.

Exact input, minimum output, or exact output?

Three trade modes tell the Across Swap API whether input, minimum output, or exact output governs the quote. exactInput, the API default, fixes the amount spent and lets the quoted output move. minOutput asks for at least a chosen destination amount and calculates the required input. exactOutput targets one precise destination amount; strict execution stops when that exact outcome can’t be delivered. Choose the mode by deciding which side of the transfer must stay fixed.

Reading the quote before signing

One fresh Across quote should expose the route, delivery condition, recipient, required approvals, transaction simulation, and expiry.

Start with the chain names, token symbols, contract addresses, amount condition, and recipient. Then read the balance and allowance checks, because they determine whether the returned transaction sequence is executable from the connected account. The simulationSuccess value reports whether the origin transaction simulation passed, while expectedFillTime is an estimate rather than a deadline. The quoteExpiryTimestamp is the hard boundary for that response, so a stale browser view needs a fresh quote before signing.

Use this 5-point decision checklist immediately before the wallet prompt.

• The connected wallet is on the quoted origin chain.
• The input and output contracts match the selected networks.
• The recipient address is usable on the destination chain.
• The output condition matches exactInput, minOutput, or exactOutput.
• The quote remains inside its displayed validity window.

If the route, recipient, or amount changes, discard the prior transaction data and request another response. Treat a failed simulation as a stop condition. A readable route summary gives stronger confirmation than the hexadecimal calldata displayed by a wallet prompt.

Approval transactions before the deposit

Two transaction stages appear for many ERC-20 routes: an allowance approval followed by the main Across deposit transaction.

An ERC-20 approval authorizes the returned spender to use the quoted input token from the depositor account. The response contains 0 approval transactions when the existing allowance already covers the route; otherwise, it supplies 1 or more approval calls to execute first. Wait for each approval receipt before sending swapTx. Native-token routes skip ERC-20 allowance logic, although the wallet still signs the deposit transaction and pays origin-chain gas for the ordinary path.

The main transaction must preserve the returned target, calldata, and value. Its confirmation creates the origin deposit reference used for tracking. If the quote expires while an approval is confirming, request new transaction data instead of submitting the old deposit. A route with sufficient allowance therefore has a shorter wallet sequence than a first-time token approval.

Tracking the relayer fill

Four deposit statuses describe the Across relayer fill from origin confirmation through destination delivery or a returned transfer.

pending means the deposit exists but hasn’t received a destination fill. filled means the relayer delivered the destination tokens. expired means the fill deadline passed and the transfer is eligible for return processing, while refunded records that return. Three of these values describe terminal workflow decisions: accept the filled balance, wait for the return path after expiry, or confirm the refund. The quote’s delivery estimate guides the interface, but the on-chain status resolves the outcome.

The status index polls relevant chain events every 10 seconds, and updates normally appear 1 to 15 seconds after the deposit enters its index. Polling more frequently doesn’t accelerate the fill or the indexer. A brief gap between wallet confirmation and a visible pending status therefore reflects indexing cadence, not a second user action.

For definitive confirmation, read the destination chain ID and fill transaction reference returned with filled. The relayer’s destination record is a stronger completion signal than an interface spinner or the origin receipt alone.

Confirming the destination balance

Two on-chain records confirm delivery: the origin deposit transaction and the destination fill transaction for the recipient. The deposit proves the instruction entered the origin SpokePool; the fill proves the output reached the destination ledger. USDC uses 6 decimal places on Arbitrum and Base, while WETH uses 18 decimal places on those EVM networks. Decimal precision explains why raw explorer amounts look larger than wallet units. Match the contract, decimals, recipient, and filled amount before treating a ticker display as confirmation.

A clean handoff after delivery

One filled status completes the Across workflow, leaving the destination tokens under the recipient address’s ordinary wallet control.

There are 0 additional Across withdrawal steps after a normal filled route. Switch the wallet view to the destination network, reveal the received ERC-20 token if the interface hides it, and decide whether to hold or use it in a separate transaction. Any later transfer, swap, or application deposit starts from the recipient’s destination balance and follows that application’s own approval and transaction rules.

This workflow fits someone who already knows the desired origin asset, destination asset, and receiving address. It also fits applications that want one quoted crosschain outcome and one trackable deposit reference. Users seeking an open-ended market search should decide their destination token first; Across delivery works best when the intended endpoint is explicit. This is explained again Across protocol overview.