1inch

1inch is a Decentralized Exchange Aggregator for Two-Checkpoint Classic Swaps

Updated

1inch is an interface where a Classic Swap moves through an ERC-20 spending permission and a routed on-chain transaction. When the pay token lacks enough allowance, the wallet first signs an approval; after that transaction confirms, it signs the swap itself. The form shows the input, estimated output, route, minimum received, and network cost before execution. A transaction hash then connects the interface record to the chain’s receipt, token transfers, and final status.

From approval to settlement in two wallet actions

A Classic Swap on 1inch requires 2 on-chain wallet actions when the pay token has no usable allowance.

The first signature authorizes an ERC-20 token contract call to approve a spender. It changes an allowance and moves no tokens. The second signature authorizes the Aggregation Protocol call that pulls the approved input, follows the quoted route, and sends output to the chosen recipient. Those are separate transactions with separate nonces and receipts. Native ETH skips ERC-20 approval because ETH isn’t a token contract balance; the wallet passes value with the swap transaction and still pays network gas. If an allowance already covers the input, the sequence begins at the second action.

The approval transaction

The approval request names 3 pieces of state: the token contract, the spender, and a uint256 allowance value. ERC-20 defines approve and allowance alongside the Approval event. After 1 successful approval receipt, the interface rechecks that value before enabling the swap. A pending approval isn’t a completed trade, and the pay-token balance should remain unchanged, which is discussed in 1inch rewards.

The swap transaction

The swap request has its own contract destination, calldata, gas limit, and nonce. Signing authorizes that exact payload on the selected chain. Validators include it and execute the full route, or they record a reverted call. A route through Uniswap V3, Curve, or Balancer V2 still settles as 1 top-level wallet transaction, even when several pool calls appear beneath it.

Two confirmed receipts therefore represent two state transitions: permission first, then asset exchange.

Preparing the wallet and matching the network

The decisive prerequisite is chain alignment: 1inch and the connected wallet must point to the same network.

EIP-155 binds an EVM transaction signature to a chain identifier, so a valid request belongs to one network. Ethereum uses chain ID 1, Optimism uses 10, BNB Chain uses 56, Polygon uses 137, Base uses 8453, and Arbitrum uses 42161. MetaMask, 1inch Wallet, and WalletConnect display the active network before signing. A token balance on one chain doesn’t supply the matching token or gas balance on another chain, even when both networks use ETH as their native asset.

Use this decision checklist before requesting a quote:

Simple Swap offers 25%, 50%, and Max amount controls. The Pro amount slider adds 0%, 75%, and 100% endpoints around the same balance decision. When the pay asset is native, Max must leave room for gas; an ERC-20 input uses a separate native balance for that cost.

What should you inspect before signing a 1inch swap?

Before signing, inspect the token contracts, spend amount, recipient, minimum output, route, and network fee shown for the request.

Quote fields

The quote pairs human-readable amounts with contract-level units. On Ethereum, USDC and USDT use 6 decimals, while WETH and DAI use 18; confusing those scales changes an amount by orders of magnitude. An EVM address contains 20 bytes, rendered as 40 hexadecimal characters or 42 characters with the 0x prefix. The token picker, ticker, and contract address should describe the same asset. The minimum received deserves equal attention because the contract enforces that boundary, not the headline estimate.

Wallet request

The approval modal should describe a token allowance, while the swap modal should describe a contract interaction with a gas estimate. Simple Swap places its brief summary in the signing modal rather than on a separate confirmation page. Compare its pay amount, receive estimate, recipient, and chain with the wallet’s decoded view. Ledger and Trezor add a device-confirmation layer, yet the payload remains the same transaction.

A mismatch in any field calls for closing the request and generating a fresh quote.

Allowance choices and permit signatures

Allowance scope decides whether the permission ends with one trade or remains available for later swaps.

An exact allowance matches the intended input. After transferFrom spends it, the remaining value normally falls, and a fully consumed allowance reaches 0. A persistent allowance commonly uses the uint256 maximum, 2^256−1, and stays available until it is overwritten or revoked. The allowance caps what the spender may pull; it doesn’t reserve tokens or exceed the wallet’s actual balance. Some token implementations require setting an existing allowance to 0 before replacing it with another nonzero value.

On 1inch, a signed permit remains valid for 30 minutes, giving the wallet a defined window to submit the accompanying swap. Permit-capable tokens replace the separate approval transaction with EIP-712 typed data. ERC-2612 supplies a common permit interface, while some tokens use earlier variants. The signature itself creates no transaction receipt; the submitted swap carries the authorization on-chain.

Wallet wording matters here. "Sign message" denotes typed data and consumes no transaction nonce, whereas "Confirm transaction" broadcasts an on-chain action that needs gas. A Classic Swap following a permit still has an execution transaction, even though the approval step no longer has its own gas charge. If the 30-minute window expires, the interface requests fresh typed data rather than relying on the old signature.

What changes on-chain after execution

A successful Classic Swap changes balances atomically and leaves one receipt for the routed execution.

A successful receipt

On an EVM explorer, receipt status 1 means the call succeeded. The pay-token balance falls, the chosen recipient’s output balance rises, and Transfer logs record ERC-20 movements. A finite allowance also falls by the amount consumed when the token follows standard allowance accounting. The native balance decreases by the gas paid. If "Send to another wallet" names a different recipient, that address receives the output while the connected wallet supplies the input.

A reverted receipt

Receipt status 0 means the EVM rolled back the swap’s token and allowance changes. The network still charges gas for work already performed. A route that can’t satisfy the encoded minimum output therefore leaves the input and output balances as they were before execution, apart from the native gas balance. Approval remains a separate earlier state change if its transaction had already succeeded.

The transaction hash gives the cleanest verification path. An EVM hash contains 32 bytes, displayed as 64 hexadecimal characters, or 66 with its 0x prefix. Open the record from the 1inch Account Box or Your Trades view, then inspect it with Etherscan, Arbiscan, BaseScan, or BscScan for the matching chain. One confirmation proves inclusion in a block; later confirmations strengthen practical finality. The top-level call identifies the router, while logs and internal calls explain the balance movements.

Balance changes and receipt status, not the success banner alone, close the verification loop.

Reading the route without overreading the quote

The route explains planned liquidity calls, while the minimum output decides whether the signed 1inch transaction may settle. A path can split input across pools or use WETH as a connector, then combine the output inside one atomic call. Uniswap, Curve, and Balancer labels describe venues, not separate wallet transactions. Pool balances can change before block inclusion, so the displayed estimate remains a quote. The contract either delivers at least the encoded minimum or reverts the route, giving the reader a concrete execution boundary.

Recovering from an insufficient-gas setup error

An insufficient-gas error clears after the wallet holds the selected chain’s native asset and recalculates the request.

Classic Swap uses ETH on Ethereum, Arbitrum, Base, and Optimism; BNB Chain uses BNB, Polygon uses POL, and Avalanche uses AVAX. An ERC-20 balance can’t pay these network charges. Fund the same wallet on the same chain, refresh the quote, and let the wallet estimate both the approval and swap when two transactions remain. Don’t approve again merely because the first approval still shows pending; check its hash and nonce before creating another request.

A simple EVM value transfer has a 21 000-gas intrinsic baseline, but a routed swap contract call requires more execution gas. On Ethereum, the EIP-1559 base fee moves by at most 12.5% per block, so an old estimate can fall behind network conditions. A pending transaction may be replaced only before inclusion, using the same nonce with a suitable fee. Once it has 1 confirmation, the chain has included it, and the next workflow step should use that confirmed state.

After the approval receipt lands, refresh 1inch and sign only the newly calculated swap request.

Who benefits from the extra transaction checks

The 1inch approval-and-signing workflow fits self-custody users who want a visible boundary between permission and execution. It is especially useful when a wallet spans several EVM chains, a hardware device separates review from signing, or a route sends output to another address. Someone using Coinbase Wallet, Ledger, or Trezor can follow the same sequence: match the network, identify the request type, inspect the quote, and confirm the receipt. That discipline leaves a searchable record for every state change.

Questions worth asking

Does rejecting the swap signature undo a completed 1inch approval?

No. A confirmed approval remains in the token contract’s allowance state even when the wallet rejects the later swap request. Because the rejected swap never reaches the network, it creates no transaction hash, receipt, or balance movement. The allowance stays available for that owner, token, spender, and chain until it is spent, overwritten with another amount, or changed to zero through a separate transaction.

When must the same pay token receive another approval?

Another approval is required when the existing allowance doesn’t cover the new input under the same token, spender, wallet, and chain combination. Changing from Ethereum to Arbitrum creates a different on-chain state, while changing wallets creates a different owner. A new router deployment also means a different spender. If the earlier allowance was exact and the swap consumed it, the next Classic Swap starts with approval again after the fresh allowance transaction confirms in that wallet.

Are Ledger and Trezor compatible with the 1inch approval sequence?

Ledger and Trezor can participate through supported wallet connections that present the approval and swap requests for device confirmation. The connected software wallet, such as MetaMask or a WalletConnect client, handles the session and network selection; the hardware device signs. Contract data visibility differs by device and connection method, so compare the selected chain, token amount, spender, recipient, and fee on every available screen before confirming each of the two transactions in the intended order for settlement.

Where do the output tokens arrive after a send-to-another-wallet swap?

The output goes to the recipient address selected in the 1inch swap form, not automatically to the connected signer. The connected wallet still provides the input assets, approval, swap signature, and gas. After confirmation, inspect the recipient’s token balance and the receipt’s transfer logs on the chain. Native output may appear as an internal value transfer, while ERC-20 output appears through the token contract’s Transfer event.

White sports car driving on a racetrack