ERC-20 Token Approvals and Uniswap: Why Your First Swap Requires Two Transactions

A new user connects their wallet to Uniswap, selects two tokens, enters an amount, and clicks “swap”—then receives an unexpected prompt to approve the token before the trade can proceed. The approval appears to be a separate transaction, requires gas fees, and seems like an unnecessary step. This confusion is common, but it reflects a fundamental constraint of how ERC-20 tokens work on Ethereum and how non-custodial trading platforms must operate without holding user funds directly.

Understanding why approvals exist, what they authorize, and how to manage them safely is essential for anyone using decentralized exchanges. The approval is not a bug or a design quirk; it is a security mechanism built into the token standard itself. However, it also creates an attack surface if misconfigured or if tokens are approved to the wrong contract. On the largest decentralized exchange platform, managing approvals correctly is the difference between safe trading and exposing funds to unauthorized transfers.

How the ERC-20 standard constrains token movement

The ERC-20 standard defines a common interface for fungible tokens on Ethereum, including functions such as transfer, transferFrom, and approve. The critical distinction is that only the token owner can call transfer directly. If you hold USDC, you can move it to another address by calling USDC’s transfer function yourself. But if a smart contract wants to move USDC on your behalf—as Uniswap’s router must do to execute a swap—the contract cannot simply take those tokens. The token contract will reject any attempt to transfer your USDC without your explicit permission.

This design prevents arbitrary smart contracts from draining your wallet. If contracts could move tokens without permission, any approved dapp would have the ability to steal funds, and the security model of Ethereum would collapse. The approval mechanism solves this by requiring the token owner to sign a transaction that explicitly grants a specific contract the right to transfer up to a certain amount of tokens. The token contract enforces this limit: when the Uniswap router calls transferFrom, the USDC contract checks whether the router has been approved for at least the amount being swapped.

The approval is a transaction because it must be recorded on-chain and costs gas. The token owner (you) must pay this fee, and the transaction must be mined before the approval takes effect. Some protocols attempt to reduce this cost by using permit signatures, which bundle the approval and the token transfer into a single transaction through EIP-2612. Uniswap V3 supports permit functionality for tokens that implement it, but not all tokens do. For tokens without permit support, two separate transactions are unavoidable.

Understanding this constraint is crucial for non-custodial trading. Because Uniswap has no authority over your tokens and maintains no custody, it must ask for your permission each time a new trading pair is used. A centralized exchange avoids this step because you have already deposited your tokens into the exchange’s wallet, surrendering custody. Uniswap’s requirement for per-transaction authorization is the security cost of remaining non-custodial.

What an approval actually authorizes

An approval transaction specifies three pieces of information: the token contract being approved, the spender (the contract receiving permission), and the allowance (the maximum amount that can be transferred). When you approve USDC to Uniswap’s router, you are saying: “USDC contract, allow the Uniswap router to transfer up to X amount of USDC from my wallet.” The approval is not a single trade; it is a standing permission that remains active until you revoke it or exhaust the allowance.

The allowance limit is often the source of confusion. A common practice is to approve an unlimited allowance by setting the amount to 2^256 – 1, effectively the maximum value the contract can represent. This saves gas on future transactions with the same token because the allowance does not need to be reset. However, unlimited approvals create a critical risk: if the router contract is compromised or if a vulnerability is discovered in the Uniswap protocol, an attacker could drain your approved tokens instantly. The contract has been granted open-ended authority to transfer your funds.

Limited approvals are safer but less convenient. Approving exactly the amount you intend to swap, or slightly more to account for price changes, means that if the contract is compromised, the attacker can only take what you explicitly authorized. The trade-off is that the next time you use the same token, you may need to approve again if the allowance is exhausted. Uniswap’s interface typically defaults to either unlimited approvals or a fixed amount based on your swap; reading the approval dialog carefully before signing is essential.

The approval is also specific to the router contract address. If Uniswap deploys a new router, you must approve that router separately. Approvals do not transfer across addresses, and they do not grant authority to other protocols. This specificity is a defense: an approval to Uniswap’s router does not give any other contract permission to move your tokens. However, it also means you should verify the contract address before signing. Phishing attacks often redirect users to approval screens for attacker-controlled contracts.

Why two transactions are necessary on Ethereum mainnet

Ethereum’s transaction model processes one transaction at a time in a linear sequence. When you submit an approval transaction and then a swap transaction, the network cannot combine them into a single atomic operation. The approval must be mined first, then confirmed, before you can submit the swap. Even if both transactions are in the mempool simultaneously, miners will order them sequentially. If the approval fails or is not yet finalized, the swap transaction will revert.

This sequential requirement exists because the Uniswap router needs to verify that the approval has been granted before it attempts to transfer your tokens. If the router tried to move tokens before the approval was confirmed on-chain, the transfer would fail. The two transactions also serve separate security functions: the first authorizes the contract, and the second executes the trade. Separating them lets you review the approval separately from the swap parameters.

The time delay between transactions introduces another practical issue: price movement. If you approve USDC and then wait for the block to be mined before submitting the swap, the token prices may have changed. Uniswap addresses this through slippage protection: you specify a minimum amount of output tokens you are willing to accept, and the swap reverts if the market has moved unfavorably. The approval does not have a slippage parameter because it is not a trade; it is purely a permission.

Layer 2 networks such as Arbitrum, Optimism, Base, and Polygon can reduce the transaction cost and latency. Because these networks have lower gas prices and faster block times, the approval is quicker and cheaper to execute. Some protocols on Layer 2 have implemented flash approvals or other mechanisms to bundle approval and swap in a single step, though this introduces complexity. Uniswap’s Layer 2 implementations follow the same approval model as Ethereum mainnet but with better transaction throughput and lower fees.

Setting safe approval limits and avoiding overapproval

The most straightforward approach is to approve only the amount you intend to swap. If you are trading 100 USDC, approve 100 USDC or slightly more to account for price fluctuations. This limits the damage if the router contract is compromised or if a vulnerability is discovered. The downside is that you will need to approve again if you swap the same token pair later, incurring additional gas fees. For most users, especially on expensive networks, this trade-off is worthwhile.

If you regularly trade the same token pair, you can approve a higher amount—perhaps 10 times your typical trade size—to avoid repeated approvals without accepting unlimited risk. This balance reduces approval frequency while capping exposure. Uniswap’s interface should display the approval amount clearly; if it does not, or if the amount seems unusually high, do not sign until you understand what you are authorizing.

Revoking old approvals is a hygiene practice worth performing periodically. If you approved an unlimited allowance on an old version of Uniswap or if you have not used a particular token in months, resetting that approval to zero removes standing authorization. Services like Revoke.cash and etherscan.io’s token approval tracker let you view all active approvals and revoke specific ones. Revocation is another transaction that costs gas, so you should prioritize high-value approvals or tokens you no longer use.

The most critical practice is to verify the contract address before signing any approval. Phishing sites that mimic Uniswap’s interface may redirect your approval to attacker-controlled contracts. Always check that the approval dialog shows the correct router address, and verify it against Uniswap’s official documentation or source code. If you are unsure, do not proceed. A few seconds of verification can prevent total loss of approved funds.

Approvals across different Uniswap deployments and Layer 2 networks

Uniswap operates on multiple networks, each with its own router contract and liquidity pools. An approval on Ethereum mainnet does not grant permission on Arbitrum, Optimism, or Base. If you swap USDC on Arbitrum, you must approve Arbitrum’s Uniswap router. If you then bridge tokens to Optimism and want to swap there, you must approve Optimism’s router as well. Each network is isolated, and each router is a separate contract with a separate address.

This isolation is a security feature: a vulnerability in one deployment does not affect others. However, it also means that managing approvals across multiple networks can become complex if you actively trade on several chains. The token itself is also different on each network; USDC on Arbitrum is not the same contract as USDC on Ethereum, even though both represent the same asset. Approving USDC on Ethereum does not affect your USDC balance or approvals on Arbitrum.

Uniswap’s concentrated liquidity feature (V3) uses a separate router contract in some cases, and older V2 deployments may use different addresses. If you have approvals to both V2 and V3 routers, you are managing multiple standing authorizations. This is rarely a problem in practice, but it underscores why keeping track of your approvals and revoking unused ones is valuable. The more contracts you approve, the larger your total exposure in the event of a protocol compromise.

When bridging tokens between networks, pay attention to the approval state on each chain. If you move USDC from Ethereum to Arbitrum through a bridge, your Ethereum USDC approvals do not travel with the tokens. You start with a clean slate on Arbitrum and must approve the router there. This separation is by design and prevents an attacker from exploiting an old approval on one network to steal newly bridged tokens on another.

Smart contracts, governance, and long-term approval safety

Uniswap’s smart contracts are immutable once deployed, but the protocol can evolve through governance. The UNI governance token allows holders to vote on changes including fee structures, new deployments, and protocol upgrades. This governance model means that Uniswap’s behavior can change over time, though token approvals to existing contract addresses do not. An approval granted to the current router contract will not suddenly change to a new router without your explicit action.

However, governance could theoretically vote to deploy a new router and request users to migrate. In such a scenario, you would need to approve the new router address for tokens you intend to swap. This has not happened in Uniswap’s operational history, but it is a long-term consideration if you maintain approvals for years. For this reason, auditing your approvals annually is reasonable, especially if you do not actively trade during some periods.

The immutability of deployed contracts is also a security guarantee: the current Uniswap V3 router cannot be modified to add new functions or change how it handles approvals. If a vulnerability were discovered, Uniswap Labs would need to deploy a new router contract rather than patching the existing one. This has happened before; for example, the migration from V2 to V3 required users to approve the new router. The lesson is that approvals are tied to specific contract addresses and do not automatically transfer to newer versions.

For very large token amounts or long-term holdings, storing tokens in a hardware wallet and approving only when making a swap is the most secure practice. You retain full custody and only grant permission when you actively intend to trade. The approval expires in the sense that your hardware wallet will not be vulnerable to unauthorized transfers between swaps. This approach trades convenience for security and is most practical for users who do not trade frequently.

Practical steps before and after your first Uniswap swap

Before connecting your wallet to Uniswap, ensure you are on the official website or a verified URL. Check the domain in your browser’s address bar and verify it against official sources. Bookmark the legitimate Uniswap URL to avoid phishing. Once connected, review your wallet’s request: it should ask for permission to view your account and token balances, not to sign transactions. Granting view access does not give Uniswap the ability to move funds; only signed transactions can do that.

When you initiate a swap and see the approval dialog, read the details carefully. The dialog should show the token name, the router contract address, and the allowance amount. If the allowance is unlimited (or a very large number like 99999 USDC), consider reducing it in your wallet interface before signing. Some wallets let you edit the approval amount before confirming; if yours does not, you can reject this approval, wait for a new dialog with a lower amount, or proceed with caution if you trust the router address.

After the approval is mined and confirmed, submit your swap transaction. Verify the input token, output token, and minimum output amount before signing. Slippage tolerance is typically set to 0.5% or 1%, which protects you if the price moves slightly during the transaction’s execution time. If slippage is set to 100% or higher, you could receive far fewer tokens than expected; this is dangerous unless you have a specific reason to allow unlimited slippage.

Once your swap is complete, check your wallet to confirm that you received the output tokens. Use a blockchain explorer to verify the transaction and examine the smart contract interaction. You should see your approval transaction and your swap transaction as separate entries. If something went wrong, check the transaction status; a failed transaction typically indicates insufficient balance, insufficient approval, failed slippage check, or a contract error. Do not immediately retry; investigate the failure first.

Common mistakes and how to avoid them

Approving the wrong contract address is the most costly mistake. Always verify that the router address matches Uniswap’s official documentation. Copy-paste the address from Uniswap’s GitHub or official UI rather than typing it manually. If you have already approved a malicious contract, revoke the approval immediately using Revoke.cash or etherscan.io. The sooner you revoke, the less time an attacker has to exploit the approval.

Approving unlimited amounts to new or untested protocols is a common source of losses in the broader DeFi ecosystem. Uniswap is mature and widely audited, but even mature protocols can have vulnerabilities. Conservative approval amounts—especially when first using a protocol—reduce your risk exposure. You can always increase the approval later if you become a frequent trader.

Reusing the same wallet for high-value trades and risky experimental swaps increases your exposure. If you are testing new tokens or protocols, consider using a separate wallet with only a small amount of funds. This compartmentalization limits total potential loss and makes managing approvals simpler. Never approve a token to a contract you do not recognize or that has not been verified by the community.

Losing track of active approvals is a subtle mistake that accumulates over time. Each approval is another potential attack surface. Spending an hour every few months reviewing and revoking old approvals is preventive maintenance that most users skip. Setting a calendar reminder or using an approval management tool can make this easier. The investment in management is small compared to the protection gained.

The approval model as a trade-off between security and convenience

Uniswap’s two-transaction approval model reflects a fundamental tension in decentralized finance. True non-custodial trading requires the user to maintain custody at all times, which means explicit permission for each contract that handles tokens. Centralized exchanges avoid this friction by holding your tokens, but that custody model creates counterparty risk: the exchange could be hacked, freeze your account, or face regulatory shutdown. Uniswap eliminates that risk but requires you to manage approvals and understand smart contracts.

As ERC-20 token standards evolve and protocols improve, approval workflows will likely become smoother. Permit signatures reduce the number of transactions, and flash approvals on some Layer 2 networks make approval nearly instantaneous. However, the fundamental requirement for explicit authorization will remain as long as Ethereum’s execution model operates sequentially and user security depends on token owners controlling permissions.

The practical takeaway is that approvals are not a nuisance to tolerate; they are a security mechanism you should understand and manage actively. By approving conservatively, verifying contract addresses, and revoking old permissions, you reduce your exposure to theft while maintaining the ability to trade non-custodially. The two transactions are not a bug; they are a feature that separates decentralized trading from custodial services.