Across setup is connecting Your Wallet and Funding Origin-Chain Gas

Spending the full token balance leaves the origin transaction unfunded

The most common Across setup mistake is entering a wallet’s full native-asset balance, leaving nothing to pay the origin chain’s execution fee.

On Ethereum and ETH-based rollups, 1 ETH equals 10^18 wei and 1 gwei equals 1,000,000,000 wei. A wallet calculates the network charge as gas used multiplied by the effective gas price. The familiar 21,000-gas figure applies to a plain ETH transfer, not an Across contract call, so it isn’t a usable bridge budget. EIP-1559 limits the Ethereum base fee change between adjacent blocks to 12.5%. A reserve above the wallet’s estimate absorbs that movement and keeps the amount field from consuming the full fee balance before submission. This is set out Across walkthrough.

Native ETH shares the gas balance

When ETH is both the input asset and gas coin, the spendable balance is smaller than the displayed balance. Entering the maximum without a reserve can leave the wallet unable to submit. The quote and wallet estimate provide the live inputs; a fixed ETH reserve would become stale as network demand changes.

ERC-20 inputs use a separate gas coin

USDC, WETH and other ERC-20 balances don’t pay EVM execution gas. A wallet with ample USDC and zero ETH on Base still lacks the ETH required for a normal origin transaction. Keep the native gas coin in the same account on the same origin chain.

Only an executable origin transaction makes the route usable.

Origin gas and quoted fees pay for different work

Origin gas pays validators for the user’s source-chain transaction, while the Across quote pays the protocol participants that deliver and settle the crosschain result.

Across expresses its transfer charge as the difference between inputAmount and outputAmount. That spread contains 2 core components: the LP fee for liquidity use and the relayer fee for destination gas, capital time and execution. The quote also estimates origin gas separately because the wallet pays it in the source chain’s native coin. Across API percentage fields use 10^18 to represent 100% and 10^16 to represent 1%, a fixed encoding convention rather than a quoted rate. Prices, utilization and gas conditions still set the live amount.

Read the output amount and the wallet’s network fee together. A route involving an origin swap may also include swap impact from 0x, Uniswap or another quoted source. Across gasless integrations cover eligible authorization flows, while a normal wallet-originated transfer needs the displayed gas asset.

Wallet identity includes both account and chain

Wallet identity in Across setup combines an account address with a chain ID, so matching the visible ticker alone doesn’t establish the correct origin balance.

An EVM account is 20 bytes, displayed as 40 hexadecimal digits after the 2-character 0x prefix. MetaMask, Rabby and Coinbase Wallet expose that address on Ethereum, Optimism, Arbitrum and Base, yet every network keeps a separate balance. Ethereum uses chain ID 1, Optimism uses 10, Arbitrum One uses 42161 and Base uses 8453. WalletConnect carries the session between an app and wallet; it doesn’t merge those ledgers or move assets between them.

Before requesting the final quote, switch the signer to the selected origin chain and confirm that the token balance appears there. The destination can share the same 0x address, but its balance remains separate until the relayer fills it. Matching the account and chain gives the quote an executable origin.

ERC-20 allowance decides whether an extra signature appears

ERC-20 allowance determines whether Across setup needs an approval submission before the origin swap or deposit transaction can move the selected token.

The ERC-20 standard separates ownership from contract spending. The wallet owns the token, while the quoted spender must have enough allowance to call transferFrom for the chosen amount. Across checks actual allowance against expected allowance and returns an approval when the first value is lower.

Approval authorizes ERC-20 spending

USDC uses 6 decimal places, so 1 USDC is 1,000,000 base units. WETH uses 18 decimal places, so 1 WETH is 10^18 base units. Across builds those integers from the token metadata; users read the human amount and spender shown by the wallet. For a standard ERC-20 allowance starting at zero, the flow has 2 onchain submissions: 1 approval and 1 execution. If the allowance already covers the amount, only the execution submission remains.

Native ETH skips the allowance step

Native ETH travels as transaction value and has no ERC-20 allowance. WETH is different because wrapping ETH creates an ERC-20 token. That distinction decides whether the wallet shows one origin execution or an approval followed by execution.

Only the execution transaction creates the Across intent.

Cross-family routes require a destination-capable wallet

Destination wallet preparation depends on the chain family, because EVM addresses and Solana public keys use different formats and signing systems.

EVM routes reuse the 0x account format

At the other end, Across delivers to the same 0x account across EVM networks. Base and Arbitrum both use ETH for gas, while Polygon uses POL. The relayer pays for the destination fill, so the recipient doesn’t prepay that fill transaction. After receipt, any separate swap, deposit or transfer on the destination needs the network’s native gas coin.

Solana routes add a second address format

An EVM-to-Solana route needs an EVM wallet such as MetaMask and a Solana wallet such as Phantom or Solflare, giving Across 2 distinct connections. A Solana public key represents 32 bytes and uses base58, so an EVM 0x address isn’t interchangeable. When Solana is the origin, the fee payer holds SOL. One SOL equals 1,000,000,000 lamports, while the base fee is 5,000 lamports per signature before any optional prioritization fee. A Solana transaction has a 1,232-byte maximum size.

Fixed network parameters expose setup mismatches

Fixed network parameters let Across reject mismatched setup data before value moves, while the quote supplies the live fee and route information.

Polygon identifies mainnet with chain ID 137, zkSync Era uses 324 and Linea uses 59144. Those identifiers don’t describe token value; they select the ledger and contract deployment the wallet will call. Token precision performs a separate job by converting displayed amounts into contract integers. The following parameters should agree across the wallet, quote and confirmation screen.

The interface handles these encodings automatically. Their diagnostic value is concrete: a different chain ID or address format calls for a corrected wallet connection before signature.

The origin transaction creates the intent relayers fill

The Across origin transaction records a complete intent, giving relayers the deposit, destination and output conditions they need to fill.

Absent anything unusual, Across defines each crosschain intent through 3 phases: initiation on the origin chain, fill on the destination chain and settlement for relayer repayment. During initiation, the origin SpokePool escrows the input and emits V3FundsDeposited. A relayer then calls fillV3Relay on the destination SpokePool with its own tokens. Each intent can be filled only once. The user’s native coin paid for initiation; the quoted relayer fee covers destination execution and capital costs.

The order also carries a 32-bit fillDeadline, while token amounts and chain IDs use 256-bit unsigned integers. Those fields explain why a saved confirmation can’t be treated as permanent. If the wallet prompt remains open past quote expiry, return to Across for fresh calldata and a new fee estimate before signing.

A funded signer marks the end of setup

Across most deployments, Across setup is complete when the connected signer controls the quoted origin account, the selected token balance exists on that chain and the native gas balance covers the wallet’s estimate. The destination address must match its chain family, and any required ERC-20 approval must confirm before execution. Submitting the origin transaction then moves the task from preparation into the protocol’s fill lifecycle, where relayers act on a recorded intent.