Across

Across setup is the Wallet-Funding and ERC-20 Approval Stage

Across setup is the wallet-preparation stage before an EVM transfer: select the origin network, fund that account with its native gas token, hold the exact ERC-20 contract balance, and grant the quoted SpokePool enough allowance. The normal wallet-signing path requires an approval transaction when the allowance is short, followed by the Across deposit transaction. Both execute on the origin chain, so an ERC-20 balance alone won't cover gas.

Two Origin-Chain Transactions Define the Initial Cost

Origin-chain transaction cost is the sum of network gas for approval and network gas for deposit, with protocol fees shown separately in the Across quote.

Approval Gas

Approval gas pays for one state-changing ERC-20 call on the origin network; it doesn't pay for the separate Across deposit.

An underfunded wallet stops before Across can pull the token, even when the ERC-20 balance covers the transfer. MetaMask and Rabby estimate native-asset needs from the gas limit and live fee fields. An EIP-1559 type 2 transaction specifies a gas limit, a maximum fee per gas, and a maximum priority fee per gas. On Ethereum and EVM rollups, one gwei equals 10^9 wei, while one ETH equals 10^18 wei. Fixed units don't create a fixed bill: execution work, the origin fee market, and the fee cap set the charge. Reserve native asset for approval plus deposit, rather than only the first prompt.

Deposit Gas

Deposit gas funds the SpokePool call that transfers approved tokens into the origin contract and records the crosschain intent.

Quoted Network Cost

The wallet's maximum displayed charge is a ceiling, not the expected debit. For EIP-1559 transactions, the effective price per gas equals the base fee plus the priority fee, capped by the signed maximum. The Across quote also returns origin-gas data. Refreshing that quote before signing keeps the calldata, fee estimates, and amount assumptions aligned.

Protocol Fee

Across route fees reduce or shape the quoted output; they aren't paid by maintaining extra ETH beside the input token. Relayer capital, destination execution, liquidity conditions, and any origin swap contribute to the route quote. Because those inputs move, the quote owns the value. Wallet funding should cover its stated input amount and the origin-chain transaction ceiling.

Fund the Origin Account Before Connecting

Origin-account funding is a two-asset readiness check: the selected ERC-20 covers the transfer amount, while the chain's native asset pays execution gas.

Put another way, Across setup should use a fresh route quote because token addresses, route support, and required input amounts belong to a specific origin-destination pair. The connected account must be the depositor named in that quote.

Five-point funding decision. Check every condition before signing either transaction on the selected origin chain.

• The wallet shows the intended chain ID, such as 42161 for Arbitrum or 8453 for Base.
• The token contract matches the quote, not only a familiar ticker such as USDC.
• The ERC-20 balance equals or exceeds the required input or maximum input.
• The allowance spender matches the origin SpokePool returned for that route.
• The native balance covers both transaction ceilings when the allowance is insufficient.

An EVM account address is 20 bytes and appears as 42 characters: a two-character 0x prefix plus 40 hexadecimal characters. Reusing that address doesn't merge balances between chains; its Arbitrum and Base states remain separate. Funding another account on the origin chain won't help the connected depositor. Keep both the selected token and the native gas asset in the wallet that will sign.

What Does the SpokePool Approval Authorize?

A SpokePool approval is an ERC-20 allowance that lets the origin-chain contract pull no more than the value recorded for that spender.

ERC-20 exposes approve(spender, value) and allowance(owner, spender) as separate state functions. Across checks the connected depositor, the input-token contract, and the origin SpokePool. If any one differs, an allowance recorded elsewhere doesn't satisfy the quote.

Exact allowance. EIP-20 defines approve with two arguments, a 160-bit spender address and a 256-bit unsigned allowance value. Spending tokens through transferFrom reduces the remaining allowance, while another approval replaces the stored value.

Larger allowance. A broader value supports later deposits while the same token contract and SpokePool remain relevant. It also leaves more spending authority recorded until the owner changes it. Exact approval creates another approval transaction after the allowance is consumed; a broader approval exchanges that future gas step for longer-lived authorization. The wallet prompt should state which amount you're choosing.

Token Contracts and Decimal Precision Must Match

Token identity is a chain-specific contract address plus decimal precision, so a ticker match alone doesn't establish the asset that Across will spend.

USDC uses 6 decimal places on its EVM contracts, so 1 USDC is encoded as 1 000 000 base units. DAI and WETH use 18 decimal places, making 1 token equal 10^18 base units. Across quotes amounts as integer strings because Solidity doesn't store decimal fractions. At 6 decimals, 25 USDC encodes as 25 000 000 units; at 18 decimals, 25 WETH encodes as 25 × 10^18 units. The comparison concerns encoding, not market value. Reading the decimal field and contract address prevents an approval from carrying the wrong scale. That check matters whenever wallets present rounded balances, which is examined Across troubleshooting.

Native USDC issued by Circle and bridged forms don't share one universal address. Across route data specifies the input token on the origin and the output token on the destination. An Ethereum token address doesn't establish the equivalent asset on Arbitrum, Base, or Optimism. The symbol helps humans read the asset, but the contract address and decimal count govern approval. Let the quoted address drive the setup.

A zero quoted balance calls for a contract-and-chain check before additional funding.

Chain IDs Keep the Approval on the Right Network

A chain ID is the transaction's network identifier, and it keeps the approval, token balance, and SpokePool address tied to one origin ledger. Ethereum uses chain ID 1, Optimism 10, Polygon 137, Base 8453, and Arbitrum 42161. These identifiers separate otherwise identical 42-character address views. Switching MetaMask or Rabby after building a quote invalidates its network context. Refresh the route after a network change, then compare the wallet's chain label before signing.

Allowance State Determines Whether Setup Needs One Signature or Two

Allowance state is the on-chain comparison between the wallet's existing approval and the quoted input requirement, determining whether an extra signature appears.

The Swap API's allowance check exposes actual and expected values. When actual meets expected, the approval transaction array stays empty and the wallet proceeds to the main swap transaction. When actual falls short, execute the returned approval first and wait for its receipt. Submitting the deposit before that approval confirms makes the deposit revert if no adequate prior allowance exists.

An externally owned account advances its origin-chain nonce by 1 for every included transaction. A first-time transfer with insufficient allowance therefore uses two consecutive nonces: one for approval and one for deposit. A sufficient reusable allowance leaves only the deposit transaction. Smart-contract wallets may bundle calls, but the token contract still evaluates a numeric allowance for its recorded spender.

Changing the transfer amount after approval can make the required value exceed the existing allowance. Refreshing the quote after an edit reveals whether another approval is necessary.

Wallet Prompts Reveal the Contract and Amount

A wallet confirmation is the final setup surface, exposing the origin chain, token contract, spender, allowance amount, gas limit, and transaction data before signing.

MetaMask and Rabby decode standard ERC-20 approval calldata into a spender and allowance. WalletConnect transports the request between an application and a compatible signer; it doesn't alter the on-chain call. Read the network, token, spender, and amount as one tuple.

Software Wallets

Software wallets should show an approval interaction for the token contract, followed by a separate Across transaction after confirmation. Rejecting either signature changes no on-chain state. Closing the application after approval leaves the allowance recorded, so reconnecting the same account and chain resumes with a refreshed quote. A different account starts from its own balance, allowance, and nonce, even when both appear in the same browser extension.

Hardware Signers

Ledger and Trezor devices add physical confirmation, while MetaMask or Rabby supplies the request and network context. Hardware signing doesn't fund gas or convert WETH into ETH. The origin account still needs the native asset that its chain charges. Compare the device address with the connected 42-character account before approving.

Some smart-contract wallets batch approval and deposit into one user action. That interface preserves two contract-level changes: the token grants spending authority, then Across pulls input during deposit. If simulation reports an allowance or balance shortfall, correct that exact origin-chain field before signing again. A successful simulation still doesn't replace reading the amount, spender, and network because the signature commits the account to all three values.

SpokePool Architecture Explains the Setup Order

Under normal conditions, Across's SpokePool architecture is an origin-chain escrow mechanism that pulls approved tokens during deposit, emits the intent, and separates user setup from later settlement.

The standard deposit path calls depositV3 on the origin SpokePool. That contract uses transferFrom to move the approved ERC-20 amount, then emits V3FundsDeposited with the input token, output token, amounts, destination chain ID, depositor, recipient, and deadlines. Relayers watch that event and supply destination liquidity. Across later coordinates settlement through the HubPool on Ethereum, while the user's setup stays confined to the origin transaction. This separation explains why destination liquidity doesn't replace origin gas and why approval targets a chain-specific spender rather than one universal contract. One successful deposit consumes the authorized input.

After the first pass, Across's relayer, HubPool, and UMA settlement machinery doesn't require additional wallet approvals during normal transfer setup. Once the deposit receipt includes the expected event, the preparatory balance and allowance have completed their job. The transaction hash then becomes the durable identifier for status tracking, and the remaining lifecycle belongs to the deposit rather than wallet preparation.

Across setup: the short answers