Across protocol is a cross-chain bridge protocol for intent-based asset transfers

Quoted output and origin cost before signing

Three amount modes - exactInput, minOutput, and exactOutput - determine whether an Across protocol route fixes the sent amount, a minimum receipt, or an exact receipt.

The quote presents inputAmount beside outputAmount, so the transfer decision rests on two visible quantities rather than a percentage in isolation. Their difference contains the liquidity-provider and relayer components used for the route. Origin network gas remains a separate wallet cost. Review the token symbols, raw amounts, and decimal precision together: 1 USDC equals 1,000,000 base units because USDC uses 6 decimals, while WETH uses 18 decimals. A quote is a transaction proposal for one defined route, not a standing promise for a later wallet action.

A numerical slippage setting uses a range from 0 to 1. For example, 0.005 represents 0.5%. When a route contains both an origin swap and a destination swap, the Swap API divides a manually supplied tolerance between the two legs. The quoted output, wallet balance check, allowance check, and executable transaction data belong to the same response, which keeps route selection tied to the action awaiting signature.

What must match before you approve a route?

Four route fields must agree before approval: the origin chain, destination chain, input token, and output token shown by the Across transfer interface.

Origin chain and spend asset

The origin network is where the wallet signs and where the balance must exist. Ethereum uses chain ID 1, Optimism uses 10, Base uses 8453, and Arbitrum uses 42161. A token symbol alone does not identify the asset; the token contract and selected chain form the pair.

Destination chain and receive asset

The destination selection defines both the network and the asset delivered to the recipient. Polygon uses chain ID 137, ZKsync Era uses 324, Linea uses 59144, and Avalanche uses 43114. The route quote should display a supported output token for that exact destination.

Recipient and amount mode

The recipient may equal the connected wallet or another valid destination address. Read it character by character before signing. Then confirm whether the amount field means spend exactly, receive at least, or receive exactly; those meanings correspond to the three trade types, and they are not interchangeable.

Six route-entry options and their signing boundaries

Six Across route-entry options cover interactive transfers, prefilled routes, API execution, embedded actions, signed gasless requests, and deposit-address funding with different confirmation handles.

The option changes how a route reaches the protocol, not the meaning of destination confirmation. A wallet user will normally start in the bridge interface. An integrator can use the Swap API, while a direct route link preselects fields without submitting a transaction. Gasless execution replaces an origin gas payment with a signed authorization. Deposit addresses serve automated sending flows. The table keeps these choices within Across protocol, so it does not turn route selection into a comparison of unrelated bridges.

Reading the wallet request before the deposit

Two wallet operations appear on many ERC-20 routes: an allowance transaction authorizes token use, and a second transaction submits the Across deposit on the origin chain.

ERC-20 allowance

An allowance targets a token contract and names a spender. MetaMask and other EVM wallets show this request separately from the bridge deposit. Match the token, chain, spender, and amount to the route response. If the existing allowance already covers the input amount, the response omits the preliminary approval transaction.

Deposit transaction

The deposit call carries the recipient, input and output assets, amounts, destination chain ID, and deadlines into the origin SpokePool. An EVM address contains 20 bytes and displays 40 hexadecimal characters after its prefix, while a transaction hash contains 32 bytes and displays 64 hexadecimal characters. Those fixed lengths help distinguish an address from the hash saved after submission.

Native asset path

A native-token route does not use an ERC-20 allowance for the native asset, so the wallet presents one origin transaction rather than an approval followed by a deposit. The value field carries the native amount. The network selector still must match the quote before the signature is useful.

How do you confirm the origin deposit?

One successful origin receipt confirms the Across deposit only when the transaction reached the quoted SpokePool and emitted the protocol deposit event for the route.

Start with the transaction hash returned by the wallet, then open the explorer for the origin chain. Etherscan covers Ethereum, Arbiscan covers Arbitrum, and Basescan covers Base. A successful receipt supplies the block number, sender, destination contract, and event logs. The deposit event connects the on-chain action to a deposit identifier, recipient, destination chain ID, input amount, and output amount. A wallet notification without a successful receipt does not establish this checkpoint, because submission and block inclusion describe two different states.

The tracking interface accepts either the origin transaction reference or the origin chain ID paired with the deposit ID. Store both forms when available. They identify the same intent through different lookups and remain more useful than a screenshot of a wallet activity label, as set out About Protocol.

From pending intent to destination fill

Three protocol phases move an Across transfer from initiation to fill and settlement, although the recipient confirmation arrives during the second phase rather than the third.

Every Across intent passes through three defined phases: origin initiation, destination fill, and protocol settlement. During initiation, the origin SpokePool records the deposit. A relayer then supplies its own destination-side capital and completes the specified output. Settlement later verifies bundled activity and repays relayers. The user does not wait for that reimbursement cycle to treat the received asset as delivered. This separation explains why a destination fill appears before the underlying cross-chain accounting has finished.

The status interface exposes four user-facing outcomes: pending, filled, expired, and refunded. Pending means the deposit exists without a completed fill. Filled points to destination delivery. Expired means the fill deadline passed, while refunded records the return path on the origin chain.

When is a transfer actually complete?

Two independent checks establish completion: the Across status reads filled, and the destination transaction shows the quoted output reaching the intended recipient on the selected chain.

The first check links the deposit to a relayer fill. The second checks what the destination chain actually recorded. Read the destination transaction hash, network, recipient, token contract, and amount rather than relying on a combined portfolio balance. An Ethereum receipt belongs to chain ID 1; an Arbitrum receipt belongs to 42161. Solana uses a transaction signature rather than an EVM-style hash, so the explorer format changes while the confirmation question stays identical: did the selected destination ledger credit the specified recipient? That ledger record closes the route-level check.

Contract wallets and exchange deposit systems may update their own interfaces after the chain records the transfer. That later display is an account-service checkpoint, separate from the Across fill. Preserve the chain record while the receiving interface catches up.

Recipient checks for same-token and swapped-output routes

Two token identities matter at confirmation: the input token deposited on the origin chain and the output token delivered on the destination chain by the route.

Same-symbol routes

A USDC-to-USDC route still uses different contract deployments across chains. USDC uses 6 decimal places, so 1 USDC is represented as 1,000,000 base units in an on-chain amount field. Confirm the destination contract associated with the quoted route instead of matching the symbol alone.

Cross-token routes

A route may accept one asset and deliver another because the Swap API includes an origin or destination swap around the bridgeable leg. WETH uses 18 decimals, making 1 WETH equal to 1,000,000,000,000,000,000 base units. Compare human-readable amounts only after applying each token’s own precision.

Contract recipients

A smart-contract recipient needs logic compatible with the output token or the embedded destination call. Plain transfers and embedded actions produce different evidence: the latter includes execution logs beyond the token movement. The destination transaction remains the shared record for both cases.

Expired deposits and the clean refund path

Four terminal tracking states define the exit path, and only an expired deposit moves toward refunded instead of a destination-side filled record.

The fill deadline belongs to the signed intent. If no relayer completes the transfer before that timestamp, the protocol marks the deposit eligible for refund through settlement. Do not create a second transfer merely because the first still reads pending; two valid deposits create two separate intents. Track the original transaction until its status becomes filled, expired, or refunded. Across does not split a single intent across partial fills, so the destination outcome corresponds to the full quoted output.

A refund returns through the origin side and therefore has its own transaction record. Confirm the refund token, amount, and recipient against the original deposit rather than looking for a destination receipt. The clean exit ends with the origin balance restored and the tracker reading refunded.

A reusable confirmation record

Five saved facts let a user or integrator reconstruct an Across route without relying on wallet labels: route, amounts, recipient, deposit reference, and fill reference.

• Origin chain, destination chain, and both chain identifiers
• Input token, output token, and their contract or mint identifiers
• Quoted input amount, quoted output amount, and selected trade type
• Recipient plus the origin transaction hash or signature
• Deposit ID, final status, and destination fill reference

Save the quote before signing, then append the origin receipt and destination fill as they appear. This record separates intent from execution and makes a route easy to verify across devices. For a Base-to-Arbitrum transfer, it preserves chain IDs 8453 and 42161 beside the exact token deployments and two transaction references.

The routes this workflow suits best

One straightforward workflow fits transfers where the user chooses a supported origin, destination, token pair, amount mode, and recipient before confirming one destination outcome.

The route-first process works especially well for USDC movement between Ethereum, Optimism, Base, Arbitrum, Polygon, and other supported networks because the expected output is explicit before the deposit. It also handles cross-token routes when the quote clearly names both assets. Developers embedding Across into a wallet or application gain the same checkpoints through the Swap API: approval data, origin transaction, deposit status, and fill reference. Users keep their decision anchored to the route rather than to a generic cross-chain balance change.

Choose the route, read the wallet request, save the deposit reference, and finish on the destination record. Those four actions cover the first-position transfer workflow from selection through a clean fill or origin-side refund.