1inch is a Decentralized Exchange Aggregator for Routed Swaps and Onchain Verification
1inch is an interface that turns a live swap quote into a wallet request, then leaves the blockchain to decide the final state. The preview names the pay token, receive token, route, estimated output, price impact, and network cost available at that moment. Before signing, confirm the chain, token contract, amount, recipient, approval scope, minimum return, and execution mode. A Classic Swap becomes a user-broadcast transaction, while Instant Swap uses a signed Fusion order. After execution, the decisive evidence is the transaction receipt and the destination address’s onchain token balance, not a cached interface total. The workflow therefore runs from quote freshness and network identity through permission, signing, receipt status, and final balance evidence.
In short: It is a swap interface that previews routes and token amounts before wallet approval, but final balances depend on gas and onchain confirmation.
A route preview can expire before settlement
A 1inch route preview is a time-sensitive calculation, so its estimated output is not the settled balance.
Pathfinder builds the quote from pool states, split routes, token decimals, and estimated network cost at one block context. Between preview and inclusion, reserves move, a pool changes its active price range, or the gas estimate changes. The interface applies automatic slippage from the pair profile, while Pro Interface accepts a custom tolerance up to 49%. In the Classic Swap API, a slippage value of 1 means accepting as much as 1% less than the expected destination amount. An explicit minimum return instead fixes the smallest acceptable output in token base units.
If the route cannot deliver that minimum, the Classic call reverts atomically and still consumes gas. Refreshing the preview produces fresh calldata, so signing an older wallet request preserves its older limits rather than the newly displayed route. Final balances therefore follow the limits encoded in the mined request.
Which swap mode determines the wallet request?
The selected 1inch swap mode determines whether the wallet signs an onchain transaction or an offchain order. Simple Swap presents 3 paths: Classic Swap, Instant Swap through Fusion, and Cross-Chain Swap through Fusion+. Classic sends a router call from the wallet and requires native gas. Fusion uses an EIP-712 order that a resolver settles, although a first permission transaction may still require gas. Fusion+ adds a second chain and separate delivery state. Read the wallet request type before treating a signature as execution.
Network identity fixes the asset and transaction context
Network identity fixes the token contracts, gas asset, balances, and ledger that every 1inch preview reads.
Ethereum uses chain ID 1, Optimism uses 10, BNB Chain uses 56, Polygon uses 137, Base uses 8453, and Arbitrum One uses 42161.
| Network | Fixed chain ID | Main failure mode |
|---|---|---|
| Ethereum | 1 | Wallet remains connected to another EVM chain |
| Optimism | 10 | ETH is held on Ethereum rather than Optimism |
| BNB Chain | 56 | BNB is absent for a Classic Swap |
| Polygon | 137 | Selected balance belongs to another network |
| Base | 8453 | Token contract comes from Ethereum |
| Arbitrum One | 42161 | Wallet provider keeps a different active chain |
MetaMask, Coinbase Wallet, and WalletConnect expose the active chain to the interface. The token picker then queries balances and contracts on that ledger. An ETH balance on Ethereum does not fund a Classic Swap on Base, despite both chains using ETH as gas. Likewise, an ERC-20 contract address copied from Ethereum does not identify the Base deployment. Chain selection therefore precedes token selection, amount entry, and approval.
Approval creates a separate spending permission
An ERC-20 approval changes allowance state; it does not execute the swap or transfer destination tokens.
The allowance record
The token contract records 3 relevant coordinates: owner, spender, and source token. Its allowance function returns a uint256, a 256-bit unsigned value. The 1inch router reads that permission before calling transferFrom. Approval calldata itself carries 0 native-token value, although the approval transaction still pays network gas. If allowance already covers the source amount, Classic Swap proceeds with 1 state-changing router transaction; otherwise, approval plus swap requires 2.
Exact allowance
An exact allowance matches the chosen source amount and leaves little reusable permission after execution. Increasing the trade later requires another approval. Tokens supporting EIP-2612 may express permission through a signed permit that the router consumes with the swap, which changes the wallet flow without changing the allowance concept.
Unlimited allowance
An unlimited allowance appears as 2 256 − 1, the maximum uint256 value. It avoids repeated approvals for the same token and spender, and it remains available until another transaction changes it. The interface may summarize this as unlimited rather than printing the 78-digit integer. Treat approval scope as its own decision because the previewed output, route, and minimum return do not define how much source token the router may spend later.
After the permission receipt succeeds, refresh the swap request. A newly built route should use the confirmed allowance and the latest pool state before the second signature.
The wallet prompt is the real confirmation screen
The wallet prompt carries the transaction that will be signed, making it the final review surface for a Classic Swap.
The interface does not insert a separate confirmation page. It sends a compact summary into the signing modal and then opens MetaMask, Coinbase Wallet, Ledger, or another connected provider. On EVM networks, the destination is a 20-byte address, rendered as 40 hexadecimal digits after the 0x prefix. The value field is 0 for an ERC-20 approval, while a native-asset swap carries the source amount as transaction value. One ETH equals 10 18 wei. The gas limit caps computation; it is not the final network fee. A plain ETH transfer starts at 21 000 gas, but router execution requires a larger estimate.
Compare the connected account, network, source amount, receiver, contract destination, and maximum fee with the form. A wallet that decodes calldata may also show the minimum output. After signature, the network creates a 32-byte transaction hash, displayed as 64 hexadecimal digits plus the 0x prefix; preserve that identifier for verification.
What changes onchain after a Classic Swap?
A successful Classic Swap atomically debits the source balance, executes the route, and credits the configured receiver.
Atomic router execution
The wallet calls the 1inch router with encoded source token, destination token, amount, receiver, minimum return, and route data. The router uses transferFrom for an approved ERC-20, then passes value through liquidity such as Uniswap or Curve when Pathfinder selected those sources. Every internal call belongs to one top-level transaction. Status 1 commits all successful state changes; status 0 rolls back the router path while preserving the network fee.
Destination balances and logs
An ERC-20 output finishes in the destination token contract’s balanceOf mapping for the receiver. The function returns a 256-bit unsigned balance, and Transfer events describe movements that occurred during execution. A native-asset output may appear as a contract-generated internal transfer rather than a normal top-level transfer. The balance still changes onchain. For tokens with transfer rules, the contract’s final balance remains the decisive amount.
Receipt status anchors balance verification
The transaction receipt and contract balance provide the shortest reliable proof that a 1inch Classic Swap settled.
Start with the 32-byte hash from the wallet and open the matching chain’s block explorer. A pending transaction has no receipt. After inclusion, the receipt records a block number, sender, destination, gas used, effective gas price, logs, and a binary status. Status 1 means the top-level call succeeded; status 0 means it failed. One confirmation proves inclusion in one block, so a confirmed Classic Swap can no longer be cancelled or sped up. Then read the destination token’s balance for the receiver and compare the change with the executed output.
Ethereum sets 12-second slots and 32-slot epochs, making its nominal two-epoch finality interval 768 seconds.
Inclusion, confirmation, and finality answer different questions. The first receipt proves that a block executed the call; later chain finality strengthens permanence. Wallet totals and 1inch activity views may refresh on separate schedules, so a temporary display gap does not change the contract state recorded at the receipt’s block (covered in 1inch comparison ).
Pending swaps follow the account nonce
A pending Classic Swap follows the sending account’s nonce order, not the visual order of interface notifications. Each EVM transaction uses 1 sequential nonce, and later transactions from the same account wait behind an earlier unresolved nonce. Speed-up and cancellation both broadcast a replacement with that same nonce and a higher fee setting. Once either version gains 1 confirmation, replacement ends. Record both hashes when the wallet exposes them, then use the receipt attached to the mined nonce as the authoritative outcome.
Recovering from a wallet and dApp network mismatch
A wallet and dApp network mismatch blocks accurate balances, token selection, approvals, and Classic Swap construction before signature.
Read the network shown in the 1inch token picker, then switch the connected wallet to the same chain ID. If the desired chain is missing from MetaMask, add its network configuration and reconnect; EIP-6963-compatible injected wallets should appear in the provider selector. Reopen the token picker, select both assets on that chain, and let balances reload. An earlier approval on Ethereum does not grant allowance on Base because each token contract stores separate state. Rebuild the quote only after the network and balances agree.
1inch: questions and answers
Does the previewed receive amount include the Classic Swap gas fee?
The previewed receive amount describes destination tokens, while the Classic Swap gas fee is paid separately in the network’s native asset. On Ethereum, Base, Arbitrum One, and Optimism, that asset is ETH; BNB Chain uses BNB. The wallet estimates a gas limit and fee before signature, then the receipt records gas used and effective gas price. A reverted router call still pays for the computation that validators processed.
Where will output tokens arrive when Send to another wallet is enabled?
The destination tokens arrive at the receiver address selected in the Simple Swap form. That address, rather than the connected signing account, becomes the recipient encoded in the router call. The signing wallet still supplies the source tokens and, for Classic Swap, the native gas. After confirmation, query the output token’s ERC-20 balance for the receiver address and inspect its Transfer event; checking only the signer’s portfolio will miss the intended delivery.
Why can an onchain balance appear before the 1inch activity panel updates?
An onchain balance can appear first because the token contract and the interface cache update through different data paths. Once a successful receipt applies the state change, an RPC call to balanceOf returns the new ERC-20 balance. The activity panel still has to index the transaction, decode its route, and refresh the account view. Use the transaction hash, receipt status, block number, and destination balance as the execution record while the interface catches up.
When should I add the output token manually to my wallet?
Add the output token manually when the swap receipt succeeds and balanceOf shows tokens, yet the wallet does not list that asset. Use the token contract on the same chain as the completed swap; identical symbols on Ethereum, Base, and BNB Chain represent separate contracts. Adding a token only changes wallet display and does not move funds. The contract’s decimals determine how the raw uint256 balance becomes the human-readable amount shown in the wallet.
Does editing slippage require another ERC-20 approval?
Editing slippage does not create another ERC-20 approval when the existing allowance still covers the source amount and spender. Slippage changes the minimum acceptable output encoded for the swap; allowance controls how many source tokens the router may transfer. Raising the source amount above the remaining allowance creates a new permission step. Changing the destination token alone leaves the source-token allowance record unchanged, although a different execution contract or network creates a different allowance context.
Are identical token tickers interchangeable across supported networks?
Identical token tickers are not interchangeable across networks because each chain maintains its own contracts and balances. USDC on Ethereum and USDC on Base occupy different contract addresses, even though both use the same familiar symbol. The token picker’s network label and contract address identify the asset that 1inch will route. A chain switch changes the ledger being queried, so confirm the network-specific balance before entering an amount or interpreting a zero balance.
Why did a reverted Classic Swap still reduce my native-token balance?
A reverted Classic Swap still consumes native tokens because validators executed the transaction before the router rejected its state changes. The source ERC-20 transfer and destination output roll back, but the network fee remains paid. The receipt shows status 0, gas used, and effective gas price. Compare those fields with the native balance change; do not expect the output token to appear, and refresh the quote before submitting a replacement transaction.
What happens to the preview when the token charges a transfer fee?
A token-level transfer fee reduces the amount that reaches the routing path, so the ordinary preview requires compatible handling. The Classic Swap API marks fee-on-transfer tokens and can re-estimate the route before applying slippage to the actual input. Without that compatibility, gas estimation or minimum-return checks may reject the transaction. The wallet’s final balance follows the token contract’s transfer rules, while the receipt and Transfer events show the amounts that moved onchain.
