1inch is a Decentralized Exchange Aggregator for Token Swaps and Wallet Balances

From Amount Entry to a Completed Swap

For a self-custodied trader, one amount entry creates a reviewable swap request, while settlement adds the purchased token directly to the connected wallet address.

Choose the source token, destination token, and amount in the 1inch interface, then inspect the quoted output, minimum received amount, selected network, and estimated network fee. In Classic mode, an ERC-20 token with insufficient allowance creates two state-changing transactions: one approval and one swap. A supported EIP-2612 permit replaces the separate approval transaction with a typed signature. MetaMask, Ledger, the 1inch Wallet, and other WalletConnect-compatible wallets keep the final authorization with the account holder. Nothing leaves the wallet at the amount-entry or quote stage; state changes only after the signed request reaches the chain.

Once execution settles, the purchased asset becomes part of the address’s on-chain balance.

Cost Signals Before the Signature

Cost signals in a 1inch signing view separate the live network price from the fixed transaction mechanics the wallet will authorize. A standard ETH transfer consumes 21,000 gas units, but an ERC-20 approval or router call performs contract work and consumes more. One gwei equals 10^-9 ETH, and an EIP-1559 fee has two priced components: base fee and priority fee. Classic approval and swap each charge gas when submitted. A resolver covers execution gas in Fusion.

Network Identity and Wallet Control

Network selection determines which ledger 1inch reads, which native asset pays gas, and where the resulting token balance exists after settlement.

Ethereum Mainnet uses chain ID 1, OP Mainnet uses 10, BNB Smart Chain uses 56, Polygon PoS uses 137, Arbitrum One uses 42161, and Base uses 8453. Those identifiers enter EVM transaction signatures and distinguish networks sharing the same 0x address format. The swap screen, wallet prompt, and final receipt should all show one chain identity. A quote on Polygon PoS can’t update an Ethereum balance, even when the wallet address and ticker look identical. That separation is permanent.

The network also fixes the native gas asset. Ethereum, OP Mainnet, Arbitrum One, and Base use ETH; BNB Smart Chain uses BNB; Polygon PoS uses POL. 1inch remains non-custodial throughout: the connected wallet signs, the selected chain records the call, and smart contracts execute approved instructions. Switching from Ethereum 1 to Base 8453 changes the ledger before it changes the quote.

When Is a Wallet Balance Final After a 1inch Swap?

For routine reconciliation, a 1inch wallet balance is settled once the selected chain records a successful receipt and the output token’s contract balance reflects it.

Pending Means Submitted

Pending means the request has an identifier but hasn’t reached final execution. On EVM networks, a wallet address is 20 bytes, displayed as 42 characters: the 0x prefix plus 40 hexadecimal characters. A transaction hash is 32 bytes, displayed as 66 characters: the same prefix plus 64 hexadecimal characters. The different lengths matter when copying an identifier into Etherscan, Arbiscan, or another network explorer. A pending hash gives a lookup key; it doesn’t yet show the output balance changed.

Success Means State Changed

Success means the receipt completed without a revert, and ERC-20 Transfer events show the movement produced by the route. The wallet then reads balanceOf for the output contract. A display cache may refresh after the chain state, so the receipt and contract balance remain the authoritative pair.

Failure Preserves Pre-Swap State

A reverted Classic swap leaves the token exchange unapplied, although the network still charges for computation already performed. The input and output balances therefore stay at their pre-swap levels.

Reconcile both sides, not just the headline output. The input token balance falls by the amount sold, the output token balance rises by the amount received, and the native asset balance pays any Classic gas. Existing holdings remain part of each total, so the post-swap output balance isn’t the received amount alone. In the 1inch Wallet, Activity exposes status, token amounts, network fee, nonce, contract, and transaction hash. A connected browser wallet exposes the same chain record through its explorer, including the recorded transfer on Arbiscan.

Token Units Behind the Displayed Balance

Token decimals determine how 1inch converts integer contract balances into the human-readable amounts shown in the input, quote, and wallet balance fields.

ERC-20 defines decimals as an optional display function; arithmetic on-chain still uses whole base units. Circle’s USDC uses 6 decimals, so 1 token corresponds to 1,000,000 base units. ETH uses 18 decimal places through wei, making 1 ETH equal to 1,000,000,000,000,000,000 wei. The interface reads this precision from the selected token contract, not from the ticker alone. That distinction matters when two networks carry assets with similar symbols, because the contract address, chain ID, and decimals together determine the displayed balance. A USDC amount of 1 base unit displays as 0.000001 USDC.

Approval State and Spending Authority

Approval state controls whether the 1inch router has authority to move the source ERC-20 amount when the user authorizes a Classic swap. The remaining detail is recorded in 1inch requirements.

On-Chain Approval

An on-chain ERC-20 approval writes an allowance for one owner, one spender, and a numeric limit. The standard’s approve call sets the value, while allowance reads what remains. With no sufficient allowance, the lifecycle contains two hashes and two gas-bearing transactions. Approval doesn’t exchange tokens; the following router transaction invokes transferFrom within the authorized limit.

Typed Permit

EIP-2612 adds three functions beyond ERC-20: permit, nonces, and DOMAIN_SEPARATOR. Its typed message contains five core values - owner, spender, value, nonce, and deadline - and a successful permit increments the owner’s nonce by 1. 1inch presents that authorization through an EIP-712 signature for supported tokens, avoiding a separate approval transaction while preserving a specific spender and amount.

Remaining Allowance

An allowance remains available until spending consumes it or another approval changes it. Selling the received asset during a reverse swap checks the opposite token’s allowance, so a prior source-token approval doesn’t cover the new direction. Exact-amount approval narrows control to the planned size; a larger allowance supports repeated adjustments. Either choice remains attached to the token contract and router on the selected chain.

Route Execution and Lifecycle Status

Route execution decides who submits the state-changing call, while lifecycle status tells the user whether the requested exchange filled, expired, or reverted.

Classic sends a router transaction assembled from aggregated liquidity, and a route can split across venues such as Uniswap, Curve, Balancer, and PancakeSwap. Fusion instead treats the user’s signed request as an intent and lets resolvers compete to fill it while covering execution gas. Fusion+ extends the intent across two chains. Its lifecycle has three main phases - announcement, deposit, and withdrawal - plus an optional fourth recovery phase. These modes produce different status records, yet each completed output still resolves to the destination wallet balance on its recorded chain.

Read the status attached to the mode. Classic exposes a transaction receipt; Fusion exposes order fulfillment; Fusion+ also shows cross-chain steps and fill progress. Pending, completed, expired, and reverted labels describe different endpoints. 1inch’s transaction history joins those interface labels with the underlying hash or order record, ending with a Classic swap or Fusion order.

Routine Position Adjustments

A routine position adjustment starts with the settled wallet balance, then creates a new quote for only the amount or asset relationship the user wants changed.

Resize the Next Trade

Changing size doesn’t edit the completed swap. Entering part of the output balance creates a second request, and 1inch recalculates route, minimum received amount, price impact, and execution cost for that amount. Keep enough of the network’s native asset outside a Classic input amount to authorize the next call. Fusion uses a signed intent, so its fill status governs how much balance is available for the following step.

Rotate the Asset Pair

Changing the destination asset also starts a new position leg. The source becomes an existing wallet token, while the output can be another ERC-20 on the same chain or a cross-chain destination offered through Fusion+. A direct pair may route through intermediate liquidity without placing those connector tokens in the wallet. For example, a USDC-to-1INCH route can use WETH internally and still settle only 1INCH to the recipient.

Reverse Swap as a New On-Chain Trade

A reverse swap on 1inch exchanges the prior output asset back toward the prior input asset through a completely new quote and authorization.

In a two-field Swap form, the direction control only rotates the token roles; it doesn’t reverse finalized chain state. After rotation, the prior output token becomes the source, its wallet balance sets the available size, and the interface calculates a new minimum received amount. Price movement, current liquidity, route choice, and fresh gas economics mean the return amount won’t equal the original input by default. If the new source lacks router allowance, the user signs an approval or supported permit before execution. Settlement then updates both balances under a second transaction hash.

A Lifecycle Suited to Self-Custodied Swaps

This 1inch lifecycle suits users who want self-custodied token swaps, visible on-chain balances, and a deliberate second action for resizing or unwinding. The workflow is especially clear for repeated EVM swaps where ERC-20 allowance state is understood and every adjustment receives a new quote. Hardware-wallet users retain the same sequence: review the 1inch request, verify the network and amount on Ledger, submit, and reconcile the resulting balance through MetaMask or WalletConnect.