1inch requirements are a connected wallet, token approval, and gas

1inch requirements are a self-custody wallet able to sign on the selected network, enough of the sell token, any required ERC-20 allowance, and the network’s native asset for Classic Swap gas. The wallet and 1inch must use the same chain. Fusion changes the gas requirement because a resolver pays settlement gas, although the user still signs the order and authorizes the token.

25 July 2026 Last updated

What's inside

Those conditions create separate checkpoints: wallet access, chain alignment, spending permission, fee funding, and final confirmation. Missing one blocks execution even when the route and quoted token amounts look valid.

Key takeaway: They are trade prerequisites that let users execute swaps: a connected wallet, token approval, native gas, and on-chain confirmations.

Classic Swap Gas Has Two Possible Charges

Classic Swap requires the wallet to fund network gas for each on-chain action, so a first ERC-20 trade normally incurs two gas-bearing transactions: approval and execution.

Approval Gas

An approval writes an ERC-20 allowance for the router without moving the approved tokens. A wallet with no existing allowance submits this transaction first and waits for its confirmation. Once the allowance covers the intended amount, the swap becomes a separate action. Selling a native asset such as ETH skips ERC-20 approval, while a previously sufficient allowance also reduces the sequence from two transactions to one, as recorded in 1inch availability.

Swap Execution Gas

The execution transaction pays validators or sequencers to run the selected route. On Ethereum’s EIP-1559 fee market, the effective charge equals gas used multiplied by the effective price per gas, which combines the base fee and priority fee within the wallet’s maximum-fee cap. Route complexity affects gas used, while network demand changes the unit price. A reverted transaction still consumes the gas spent before execution stops, so the wallet needs enough native currency beyond the quoted sell amount.

A Signing Wallet Establishes the Transaction Sender

A 1inch swap begins with a signing-capable, self-custody wallet because the connected address must authorize permissions, orders, and transactions without transferring custody to the interface.

Connecting creates a session, not an on-chain transaction, so it consumes no gas. On EVM networks, the chosen account is a 20-byte address displayed as 40 hexadecimal characters after the 0x prefix. MetaMask, Coinbase Wallet, 1inch Wallet, and Ledger through a compatible connector all satisfy the signing requirement. WalletConnect handles mobile or remote sessions, while EIP-6963 lets injected browser wallets announce themselves to the interface. The address shown in 1inch must match the account holding both the pay token and the relevant gas asset. Switching accounts after quoting changes the sender and invalidates the previous preparation.

Matching Networks Keeps the Route Executable

Network alignment requires the wallet, selected assets, and 1inch interface to point at the same blockchain before a Classic or Fusion action can succeed.

Chain IDs provide an exact cross-check inside an EVM wallet prompt. Common supported choices include Ethereum with chain ID 1, Optimism with 10, BNB Chain with 56, Polygon with 137, Base with 8453, Arbitrum One with 42161, Avalanche C-Chain with 43114, and Linea with 59144. These identifiers distinguish networks even when several use ETH as their native gas asset.

The required gas ticker follows the selected chain: ETH funds Ethereum, Base, Arbitrum, Optimism, and Linea transactions; BNB funds BNB Chain; AVAX funds Avalanche; POL funds Polygon; and xDAI funds Gnosis. A token on Ethereum and a token carrying the same ticker on Base remain separate on-chain assets.

ERC-20 Allowances Unlock Classic Execution

An ERC-20 allowance gives a named spender permission to transfer a defined amount, and Classic Swap needs sufficient allowance before its router can move the pay token.

Exact-Amount And Maximum Allowances

The ERC-20 approve function records a spender and a 256-bit amount in token base units. An exact allowance limits the router to the approved quantity, then decreases as transferFrom consumes it. A maximum allowance uses 2 ²⁵⁶ −1 base units and avoids repeated approvals, but it leaves broader permission in place. Changing the allowance later requires another on-chain transaction and another gas payment.

Permit-Based Authorization

Permit-capable tokens replace the standalone approval transaction with signed typed data. EIP-2612 defines signed ERC-20 permits, while EIP-712 defines the structured message format a compatible wallet displays. The permit itself doesn’t consume gas because the wallet signs it off-chain; the subsequent swap carries the authorization into execution. When the 1inch interface offers its permit flow, that permit remains valid for 30 minutes to complete the swap. An expired permit requires a fresh signature.

White sports car driving on a mountain racetrack

Separate Token Balances Keep Gas Available

The wallet must hold the full pay-token amount and, for Classic Swap, a separate balance of the network’s native asset to cover approval and execution gas.

Token decimals decide how wallet balances map to contract amounts. 1INCH uses 18 decimals, so one token equals 10 ¹⁸ base units; USDC uses 6 decimals, so one token equals 10 ⁶ base units. The interface performs this conversion, yet the wallet still needs the full requested input after any token-specific transfer behavior. When ETH itself is the pay asset on Ethereum, the spend amount and gas draw from the same balance. Choosing the full displayed balance therefore leaves no room for execution unless the interface reserves gas before building the transaction.

Execution Mode Decides Who Funds Settlement

Classic and Fusion impose different funding steps, so the execution mode must be chosen before deciding whether the wallet needs native gas or a prior on-chain approval.

Classic broadcasts the user’s router transaction and charges its gas to the connected account. Fusion uses a signed intent and a competitive resolver process; the resolver submits settlement and covers its network gas. That makes Fusion gasless from the user’s wallet, although the resolver’s execution cost remains part of the order economics. Token authorization still matters in both modes.

Mode Decision Checklist:

Select Classic when the interface labels the route Classic and the wallet holds native gas for every required transaction.
Select Fusion when the pair supports it and the wallet lacks native currency for settlement gas.
Expect an extra on-chain approval when the pay token has neither a sufficient allowance nor a compatible permit path.
Use the permit route only when the wallet displays typed EIP-712 data for the intended token, amount, and spender.
For Fusion+, review both the source and destination networks before signing the cross-chain order.

A Fusion label doesn’t automatically erase an earlier authorization requirement. If the interface requests a conventional approval before accepting the order, that approval still needs native gas on the source network.

Wallet Prompt Type Determines What Happens Next

Wallet prompts separate free off-chain signatures from paid on-chain transactions, and reading the action type correctly prevents an approval from being mistaken for the completed swap.

A connection request exposes the selected public address and opens a session. An EIP-712 signature authorizes structured data such as a permit or Fusion order without broadcasting a transaction. A transaction prompt contains the chain, destination contract, token value where applicable, calldata, and fee settings. Confirming that prompt submits an on-chain action and spends gas in Classic mode.

The sequence matters. Approval confirmation only establishes spending permission; the user must return to 1inch and confirm the swap afterward. Rejecting any prompt leaves the preceding state unchanged, apart from an approval already recorded by a prior transaction.

A Successful Receipt Makes Completion Verifiable

A submitted swap becomes complete only after the selected chain records a successful receipt, because a wallet popup or 1inch status message doesn’t settle assets by itself.

For an EVM Classic action, the transaction hash is 32 bytes and appears as 64 hexadecimal characters after the 0x prefix. Approval and swap transactions receive separate hashes, making their statuses independently verifiable. A successful approval receipt doesn’t prove the swap ran; the second hash must also show successful execution. If the swap reverts because its minimum return isn’t available, the tokens remain in the wallet, while the network retains the gas charged for the attempted computation. Confirmation time follows the selected chain’s block production and current queue, as covered in 1inch walkthrough.

Routing Logic Leaves User Prerequisites Intact

Pathfinder selects and may split a Classic route across liquidity sources, yet the user’s core requirements remain tied to the router transaction the wallet signs.

Classic Router Execution

A quote may draw liquidity from protocols such as Uniswap, Curve, Balancer, and PancakeSwap. Pathfinder compares routes and encodes the chosen calls into one atomic transaction from the user’s perspective. The required allowance belongs to the spender named for that route, rather than every underlying liquidity source. Route updates can change calldata and gas estimates, so an old unsigned transaction shouldn’t be treated as a standing quote.

Fusion Resolver Execution

Fusion turns the proposed exchange into a signed order with a minimum return. Resolvers compete through a Dutch-auction process, then a resolver funds and submits settlement. The user therefore needs a compatible signing wallet, sufficient pay-token balance, and valid authorization, while the resolver supplies settlement gas. An order that receives no acceptable fill expires without becoming a completed swap.

Routing improves execution choices, but it doesn’t bridge missing balances or repair a chain mismatch. The wallet remains the source of the token, authorization, and signature in either execution path.

A Final Preflight Check Stops Requirement Mismatches

A reliable preflight pass checks wallet control, chain alignment, token balance, allowance, gas funding, and the final wallet prompt before any Classic Swap reaches the network.

Start with the active address, then match the wallet’s chain ID to the network selected for both tokens. Confirm the pay-token balance covers the entered amount and inspect whether the interface requests approval, permit signing, or direct execution. Classic users must preserve native currency for each displayed transaction. Fusion users should read the minimum return and order terms because resolver-funded gas changes the payer, not the trade’s authorization or balance requirements.

Taken together, these 1inch requirements form a sequence rather than a single eligibility test. The connected address supplies authority, the allowance supplies token access, native gas funds Classic execution, and a successful receipt proves settlement.