1inch

1inch is a Swap Preview, ERC-20 Approval, and Verification Workflow

Last updated: 2026-08-08

1inch is a DEX aggregator interface that turns a proposed token exchange into a reviewable sequence: select the chain and tokens, inspect the quoted output and route, authorize ERC-20 router spending when required, sign the swap, and verify the resulting transaction on-chain. The preview is a proposal, the approval is permission, and the final wallet confirmation is the instruction that changes balances.

Those three moments look similar in a wallet, yet they perform different jobs. Reading them separately prevents the most common false finish: completing an approval and assuming the trade has already executed.

The short version: It is a DEX aggregator interface that previews swap routes, requests ERC-20 approval for router spending, builds a trade for wallet signature, and enables on-chain verification.

An ERC-20 approval is only the first transaction

The ERC-20 approval shown by 1inch grants a router permission to spend a token; it doesn’t exchange that token for the selected output.

A first-time Classic swap of USDC follows a two-transaction sequence when the relevant router allowance is zero. Transaction 1 calls the token’s approval function and records an allowance. After that approval confirms, transaction 2 calls the swap router with the chosen amount, route constraints, and recipient. The source token stays in the wallet after the first confirmation because no exchange has occurred. Treat the interface’s return to an enabled Swap button as the handoff between permission and execution, then read the second wallet request as a separate decision.

One approval confirmation doesn’t imply one swap confirmation. They produce different transaction hashes and different event logs.

If the approval shows Success in the chain’s explorer but 1inch still asks for permission, keep the wallet on the same network, reconnect it, and refresh the quote. The interface must read the confirmed allowance from that network before it builds the swap. Don’t submit another approval merely because the token balance hasn’t changed; an approval isn’t supposed to change it.

The sequence ends only after the swap transaction, not the approval, reaches a confirmed on-chain state.

Wallet and network alignment comes before the quote

Wallet and network alignment gives 1inch the correct balances, allowance state, chain identifier, and native asset needed to construct a valid Classic swap, which is examined in 1inch app.

Ethereum uses chain ID 1, Arbitrum uses 42161, Base uses 8453, Polygon uses 137, BNB Chain uses 56, and Optimism uses 10. The wallet and the interface must describe the same chain before signing. An EVM address is 20 bytes, displayed as 40 hexadecimal digits after its prefix, but an identical-looking address across networks doesn’t merge balances or approvals. MetaMask, Coinbase Wallet, WalletConnect, Ledger, and Trezor expose the selected chain in their confirmation flow, making that field a prerequisite rather than a cosmetic label.

A network mismatch is the setup error worth fixing before any quote review. If the connected wallet rejects a chain switch or shows zero despite known funds, select the intended network in the wallet, reconnect, and rebuild the quote. Fresh calldata then reflects the active chain rather than the network selected in an earlier request.

Token contracts and base units define the requested trade

The token selection in 1inch resolves to contract addresses and integer base units, so ticker symbols alone don’t define the source or destination asset. Ethereum USDC uses 6 decimal places, while WETH and DAI use 18, meaning the displayed "1" maps to different integer amounts inside transaction data. Check the selected network, contract, wallet balance, and spend amount together. This keeps the quote tied to the intended token contract and prevents a decimal conversion from being mistaken for a price difference.

Expected output and minimum receive serve different decisions

The 1inch preview uses expected output for the live quote and minimum receive for the lowest acceptable execution under the selected slippage setting.

Trade Mode’s Market flow offers Auto slippage at 0.5%, presets of 0.1% and 1%, and a custom value. A tighter tolerance protects a narrower output boundary, while a wider value gives the transaction more room to execute as pool prices move. The expected amount refreshes with the quote; minimum receive becomes a constraint encoded into the built trade. Price impact describes the route’s effect on available liquidity, whereas the network-fee estimate prices the computation. Those numbers answer separate questions and shouldn’t be combined into one rate.

In one worked example, every changing input is hypothetical: 1 WETH in, a 2 000 USDC quote, 0.5% slippage, a 0.002 ETH fee estimate, and 1 995 USDC actually returned. The minimum receive is 2 000 × (1 − 0.005) = 1 990 USDC. Since 1 995 exceeds 1 990, the output constraint passes, and the wallet receives 1 995 USDC. The ETH fee remains a separate balance change, so it isn’t subtracted from the USDC result.

A quote refresh resets the decision. Re-read both output fields whenever the route, amount, or network-fee estimate changes.

Route details explain the transaction 1inch plans to build

The route view explains which liquidity sources, connector tokens, and percentage splits 1inch proposes before the wallet receives executable transaction data.

A path might move through Uniswap V3, Curve, or Balancer, with WETH serving as an intermediate ERC-20 asset for native ETH liquidity. Split percentages across parallel branches total 100% of the source amount, but the longest diagram isn’t automatically the best choice. Each extra pool interaction adds computation, while deeper liquidity can improve output enough to justify that work. Compare the quoted receive amount, minimum receive, estimated network fee, and path complexity as one proposed execution package.

The diagram is explanatory; the signed calldata is authoritative. Route labels summarize contract calls, yet the wallet submits one top-level transaction to the router. Its internal calls can touch several pools and tokens before the final transfer reaches the recipient. A refreshed quote may produce a different path without changing the user’s chosen input and output assets.

Approval scope controls the router’s future spending limit

Approval scope determines how much of one ERC-20 token a named router may transfer from the connected wallet, independent of the wallet’s other assets.

The ERC-20 approve function accepts 2 arguments - a spender address and a 256-bit amount - and records the resulting allowance under the token contract. The related Approval event carries 3 values: owner, spender, and amount. A limited approval caps spending at a chosen integer; a maximum allowance minimizes repeated approval transactions but stays live until the holder changes it or the token’s logic reduces it.

Read the spender and amount in the wallet request before signing. Etherscan Token Approval Checker and Blockscan provide separate views for reviewing allowances, while chain explorers show the approval transaction itself. Changing or revoking an allowance is another on-chain transaction. It affects future router calls and doesn’t undo a swap already finalized.

Native ETH follows a different mechanism because it isn’t an ERC-20 token. A Classic router call carries ETH as transaction value, so no ERC-20 approval precedes that spend. WETH is an ERC-20 contract and does use allowances. Distinguishing ETH from WETH explains why two superficially similar routes present different wallet steps.

The wallet signature is the final decision boundary

The wallet confirmation turns the 1inch proposal into either a signed transaction for Classic execution or a signed intent for a Fusion order.

For a Classic EVM swap, the request includes the destination contract, chain ID, value, gas fields, and calldata. The first 4 bytes of calldata identify the called function, while subsequent arguments use 32-byte Application Binary Interface words. Connected wallets display decoded fields when available, and hardware-backed sessions add a device confirmation after the browser request. Match the amount, network, and contract interaction to the preview before authorizing the signature.

Signing proves authorization from the wallet address; it doesn’t freeze pool state or guarantee inclusion. The wallet broadcasts a Classic transaction after signing, and the network decides ordering and execution. Fusion follows an order path instead: the signature expresses constraints a resolver must satisfy. The confirmation type therefore determines what should appear next in history.

Classic execution changes balances, allowance, and network state

A successful Classic swap spends the authorized source token, routes value through the selected contracts, credits the destination asset, and charges network gas.

The source ERC-20 balance decreases by the amount transferred, and the destination balance increases by the output produced. Pool balances update along the route, Transfer events record token movements, and a limited allowance normally falls as transferFrom consumes it. On Ethereum, EIP-1559 separates the gas price into a base fee and a priority fee. One Gwei equals 0.000000001 ETH, and a plain ETH transfer starts at 21 000 gas units; router calls consume more because they execute contract logic.

The transaction also increments the sender’s nonce by 1. Network gas leaves the native-asset balance even when neither the source nor destination token is native. For an exact approval, the remaining allowance reflects the token contract’s transferFrom behavior; a maximum allowance may remain unchanged under widely used implementations. The explorer’s state and logs settle those details after execution.

A transaction hash turns the result into verifiable evidence

The transaction hash lets a user verify status, sender, destination contract, gas used, input data, and token-transfer logs outside the 1inch interface.

An EVM transaction hash is 32 bytes, conventionally displayed as 64 hexadecimal digits after the prefix. Paste it into the explorer matching the signed chain: Etherscan for Ethereum, Arbiscan for Arbitrum, Basescan for Base, or Blockscout where supported. A Success status confirms EVM execution, while logs reveal the actual token movements. ERC-20 Transfer events expose 3 values - sender, recipient, and amount - with the first 2 addresses indexed for efficient lookup.

Internal router calls explain why a swap has more movements than the two wallet balance changes the user cares about. Follow the source token from the wallet into the route, then locate the destination token’s final Transfer event to the recipient. The logged integer converts through that token’s decimals, providing a direct check on the displayed receive amount.

Verify the output through logs and the wallet’s final balance, not through the interface banner alone.

Pending, reverted, and successful states require different responses

Transaction status determines the next action: pending remains replaceable before inclusion, reverted has executed unsuccessfully, and successful has changed the chain’s state.

A pending EVM transaction occupies one account nonce and can delay later transactions from the same address. Speeding it up or replacing it uses the same nonce with a fee the network will prioritize. After at least 1 confirmation, the transaction has entered a block and can’t be replaced. A reverted Classic swap leaves the source trade amount in place, although gas was consumed. A successful approval with no balance change means the workflow is waiting for the separate swap signature.

No explorer record means the wallet request wasn’t broadcast, so there’s no pending on-chain transaction to accelerate. Reconnect the wallet and build a fresh quote rather than searching for a nonexistent hash. When a real pending transaction exists, act on its nonce first; later transactions from the same account remain ordered behind it.

The verified workflow fits deliberate self-custody execution

The 1inch preview-to-verification workflow fits users who want visible route choices, explicit ERC-20 permissions, wallet-level signing, and an independent on-chain record. It rewards a fixed reading order: network, token contracts, input, expected output, minimum receive, route, allowance, wallet request, and transaction hash. That order works with MetaMask, hardware wallets, and WalletConnect sessions because each decision is checked at the layer where it becomes authoritative.

Common questions about 1inch