1inch

1inch tutorial is an Educational Resource for ERC-20 Approvals and Fusion

1inch tutorial is a step-by-step procedure for approving an ERC-20 token, signing a Fusion order, and confirming the resolver's settlement. The maker selects a same-chain pair, reviews the allowance and minimum return, authorizes the correct spender, and signs EIP-712 typed data. Resolvers then compete through a Dutch auction and deliver the destination asset to the wallet.

This operating sequence separates the paid on-chain approval from the gasless order fill. It also shows where token permits, partial fills, expiration, and allowance cleanup change the procedure.

It is a step-by-step swap procedure that covers ERC-20 approval and Fusion order signing, where resolvers compete to fill the trade through a Dutch auction.

Executing an ERC-20 swap from quote to settlement

A complete Fusion swap moves through preparation, allowance, order signing, resolver execution, and on-chain verification.

Start by selecting one EVM network and keeping the wallet on that same chain. MetaMask, Rabby, or a WalletConnect session must expose the account holding the source token. Then select the sell and receive assets, enter the amount, and inspect the route summary. A USDC-to-WETH order on Ethereum uses Ethereum balances and contracts; a Base order uses Base state. Confirm the token contract, expected return, minimum return, and any partial-fill setting before asking the wallet to authorize anything. The selected account remains the maker throughout the order.

Five actions complete the maker's portion before resolvers take over:

1. Confirm the connected account and network before requesting the final quote.
2. Read the exact source token, destination token, input amount, and minimum return.
3. Choose a finite or unlimited ERC-20 allowance when an approval prompt appears.
4. Wait for the approval confirmation, or sign a supported token permit.
5. Read the Fusion order, sign its EIP-712 data, and monitor the order status.

The wallet presents an on-chain approval as a transaction and the Fusion order as typed data. Only the first prompt spends maker gas.

After signing, the 1inch relayer distributes the order to resolvers. A resolver accepts the auction rate, transfers the approved source asset, and delivers the destination token. This 1inch tutorial follows that sequence through the balance check; Classic Swap would instead ask the maker to broadcast the execution transaction.

Reading costs before the first signature

Fusion separates the maker's approval cost from the resolver's settlement cost, so the wallet may show only one paid transaction.

An ERC-20 approval is an on-chain contract call and consumes gas when the token lacks sufficient allowance. Ethereum wallets price it under EIP-1559 with 2 market-driven components: the base fee and priority fee. A plain ETH transfer has a fixed 21 000-gas intrinsic cost, while approval executes token-contract code and has no universal gas-use total. The approval bill equals used gas multiplied by the effective gas price. Resolvers pay 100% of the Fusion fill transaction's gas and account for that expense through the auction rate.

Worked example - every changing input is hypothetical: a maker sells 1 000 USDC, a modeled quote starts from 0.300 ETH, and the resolver's embedded execution cost equals 0.001 ETH. Subtracting 0.001 from 0.300 produces a filled output of 0.299 ETH. If the new approval costs 0.002 ETH, the wallet pays that amount separately when the chain records the approval. The maker therefore receives 0.299 ETH and pays 0.002 ETH for authorization; no second maker gas charge accompanies the Fusion settlement.

Choosing the allowance amount and spender

The allowance should match the intended token, chain, spender, and amount before the Fusion order receives a signature.

The ERC-20 approve function takes 2 inputs - spender and amount - and records a 256-bit allowance. The token contract stores that amount in base units rather than display units. USDC on Ethereum uses 6 decimals, while WETH uses 18 decimals. Wallet software performs the conversion before submitting approve. Many interfaces represent an unlimited allowance with the maximum uint256 value, 2^256 − 1. A later transferFrom call reduces a finite allowance as settlement consumes the source token.

A finite approval confines the spender to the planned quantity, although another swap requires more allowance after the remainder runs out. An unlimited approval avoids repeated approval transactions and stays active beyond the Fusion order. Setting the spender's allowance to zero revokes it through another on-chain transaction. Exact approval favors tighter maintenance; unlimited approval favors repeated use.

What does the Fusion signature authorize?

The Fusion signature authorizes a specific EIP-712 order; it does not broadcast the maker's swap transaction.

EIP-712 binds the signed data to a chain ID and verifying contract, then hashes the order terms into a wallet-readable structure. Those terms identify the maker, receiver, source asset, destination asset, amounts, auction limits, and validity conditions. The signature lets a resolver prove that the maker accepted those terms. It does not replace an ERC-20 allowance unless the interface also collects a supported permit.

EIP-2612 permits form a separate authorization layer with a value, deadline, and one-time nonce. In the 1inch interface, a signed permit remains valid for 30 minutes. Treat the permit and Fusion order as distinct signatures even when the interface groups their prompts. The permit authorizes token spending; the order defines the swap that a resolver may fill. The next part of this is set out in 1inch 101.

Following the Dutch auction and resolver fill

The Fusion Dutch auction lowers the exchange rate toward the signed minimum until a resolver accepts the order.

Resolver competition begins after the relayer distributes the signed order. The auction has 3 terminal conditions: a resolver fills it, the rate reaches the permitted boundary, or the validity window expires. Gas costs, available liquidity, trade size, and the chosen auction preset shape the fill timing. The maker does not raise a transaction fee to accelerate this off-chain order.

Partial filling lets several resolver transactions consume portions of one order while preserving proportional maker and taker amounts. Each fill reduces the unfilled balance, and their combined source amount cannot exceed 100% of the signed order. The history may therefore show an initial partial fill before final completion or expiration. Confirm the total destination balance rather than judging execution from the first settlement hash. Classic Swap provides one atomic maker transaction, while Fusion trades that immediacy for resolver competition.

Verifying balances, hashes, and order status

Verification matches the order record with token balances and the resolver's settlement transaction on the selected chain.

Ethereum uses chain ID 1, Optimism uses 10, BNB Chain uses 56, Gnosis uses 100, Polygon uses 137, Base uses 8453, and Arbitrum uses 42161. These identifiers separate contract state and EIP-712 signatures between networks. A signature prepared for Ethereum does not become a Base order merely because both networks use ETH for gas.

Next, compare the complete token addresses rather than tickers alone. An EVM address contains 20 bytes, while an EVM transaction hash contains 32 bytes. Etherscan, Arbiscan, and Blockscan decode transfer logs and approval events for their supported networks. The approval hash proves that the token contract recorded an allowance; the order hash identifies the signed intent; the settlement hash records a resolver's on-chain fill.

Finally, reconcile 3 records: the order status, the source-token debit, and the destination-token credit. A completed Fusion fill should not show a maker-paid settlement gas debit on an EVM chain. Partial fills require summing every settlement transfer. This three-way reconciliation carries more evidence than a wallet notification alone.

What happens when a Fusion order expires?

An expired Fusion order stops accepting fills after its validity window and requires a newly quoted, newly signed submission. Expiration does not charge the maker settlement gas, and a completely unfilled order leaves both token balances unchanged. A partial fill remains final for the portion already settled. Any unused ERC-20 allowance survives the order, so review that permission before resubmitting or moving to Classic Swap.

Maintaining allowances after settlement

Post-settlement maintenance compares the remaining allowance with expected future use, then reduces or revokes permission when appropriate.

An approval belongs to one owner, one token contract, one spender, and one chain. Changing any member of that 4-part relationship creates a separate allowance record. Etherscan Token Approval Checker and Blockscan expose these records for supported EVM networks. A zero-value approval closes an existing allowance but consumes network gas because the token contract must update its state.

Frequent Fusion users may retain an exact remainder or an unlimited allowance for the established settlement contract. A one-off swap supports a simpler rule: set unused permission to zero after confirming every fill. Permit-based authorization reduces approval transactions for compatible tokens, although any allowance created by an executed permit still follows the token contract's rules.

Drawing the boundary between Classic Swap, Fusion, and Fusion+

Classic Swap, Fusion, and Fusion+ use different settlement paths despite sharing the same token-selection interface.

Classic Swap asks the maker to approve an ERC-20 token and broadcast the swap transaction, so the maker pays execution gas. Single-chain Fusion uses an allowance plus an EIP-712 order, and a resolver broadcasts settlement. Fusion+ extends intent execution across 2 chains with paired source and destination escrows. Its normal lifecycle has 3 phases - announcement, deposit, and withdrawal - with an optional 4th recovery phase when completion needs unwinding.

Use Fusion for a same-chain order when resolver execution and an auctioned rate match the objective. Classic Swap fits an immediate, maker-broadcast transaction with direct gas control. Fusion+ belongs to cross-chain transfers and introduces escrow timing that this single-chain approval procedure does not require. The correct path follows the settlement boundary, not the shared swap form.