Uniswap
Uniswap works for a swap when active liquidity and total costs support the quoted outcome.
An onchain Uniswap swap works when available liquidity can absorb the order without unacceptable price impact, the quoted minimum output is acceptable, and pool fees, any token charges, and network costs do not make the trade uneconomic. A shallow route, an uncertain token contract, or a cost that overwhelms the amount makes another path preferable.
Updated ·Immediate exchange against active liquidity
A well-matched swap uses Uniswap to exchange assets already held on one supported network without depositing them with a centralized venue. The route must exist, its expected and minimum outputs must be acceptable for the intended exchange, and the separate displayed costs must not make the swap uneconomic.
Immediate pool execution fits when the live quote is acceptable now. One or more pools supply the output, and their available liquidity determines how far the trade moves the execution price. If the objective is to wait for a specified price rather than accept a current quote, a supported limit order that can remain open is a closer match.
Prerequisites visible before authorization
Readiness begins with the input asset, output asset, and network-fee balance on the intended network. Token symbols and names can be copied, so each contract address must identify the intended asset. A balance on another network does not make that asset available to a same-network pool route.
The quote should identify the expected output, minimum output, route, price impact, pool fees, and estimated network cost. Any token warning also belongs in this review. A transfer fee set by a token contract can reduce the amount that reaches the pool or wallet, while unusual token behavior can make some protocol routes unsuitable.
Authorization comes later. An ERC-20 input may need a separate approval before the swap can move the permitted amount, adding another wallet request and possibly another network cost.
Five stages from selection to settlement
A viable swap passes five distinct stages, each with evidence that supports continuing. If a larger input pushes price impact above the accepted limit or leaves an unacceptable minimum output, return to the quote, reduce the amount, or compare another route before granting permission.
| Stage | Evidence before moving on | Relevant scope or limit |
|---|---|---|
| Identify the trade | The wallet uses the intended network, and both token contracts match the intended assets. | The input balance, output asset, and network-fee balance must be available on that network. |
| Build the quote | The interface shows the input, expected output, proposed route, and current cost estimates. | A same-network route may use one pool or several pools within the selected network. |
| Set the boundary | The minimum output, price impact, pool fees, known token charges, and network cost are acceptable. | Pool state and network demand can change before submission. |
| Authorize execution | Any approval request matches the intended token, amount, and spender, and the swap request uses the network reviewed in the quote. | An ERC-20 input may require an approval, depending on existing permissions. |
| Confirm settlement | The chain receipt succeeds, and the final balances show the completed exchange. | A pending interface message is not final confirmation, and a failed transaction can still consume network fees. |
| Decision | The swap fits only when every stage preserves the intended asset, acceptable output, and affordable execution. | |
Review each wallet request before committing. Any approval must match the intended token, amount, and spender, while the swap must use the network reviewed in the quote. After submission, the transaction receipt and resulting balances establish completion; a quote or pending notification alone does not.
How much pool depth is enough for this trade?
Sufficient pool depth is relative to the proposed input and the active liquidity along its price path. There is no universal balance that makes every pool suitable. The useful evidence is the quoted output, price impact, minimum output, and how those values change when the input changes.
A smaller pool can produce greater price impact for the same trade size than a deeper pool.
Compare quotes for the same token pair at smaller and larger input amounts. A sharp drop in output per input unit indicates that the available route gives the larger trade worse execution. Splitting the desired amount over time may expose the swaps to different market conditions, so it does not guarantee a better combined outcome.
A pool’s total assets do not show how much liquidity is active along the price path a swap will cross. In concentrated-liquidity designs, capital outside the price range crossed by the trade does not support that portion of execution. A pool can therefore hold substantial assets while still offering weak depth along the route that the swap needs.
Routes that improve effective output
Routing matters because a direct pool is not always the strongest path. A router can compare direct, multihop, and split routes across available protocol liquidity. The useful comparison is the output after pool fees and estimated network costs, since an extra hop may improve the exchange rate while adding execution work.
Split routing can draw from several pools when one pool would move too far along its pricing curve. Multihop routing can pass through an intermediate asset when that path produces a better effective output. Both remain subject to the minimum-output boundary and the live state of every pool involved.
A more complex route is useful only when its quoted benefit exceeds its added costs. A simpler route is preferable when extra pools improve gross output but leave less value after fees and network execution.
Conditions that rule out the swap
Stop before authorization when the quote reveals any unresolved mismatch between the intended exchange and the available route:
- Active liquidity is too shallow for the requested input.
- Price impact pushes the minimum output below the accepted amount.
- Network costs consume too much of the value being exchanged.
- The token contract is uncertain or imposes incompatible transfer behavior.
- The task requires execution at a future target price rather than an immediate swap.
Increasing maximum slippage does not deepen a pool, remove a token fee, or lower the network cost. It widens the range of outputs that the transaction may accept. When the original boundary fails, requoting a smaller input, waiting for different conditions, or comparing another venue addresses the actual constraint more directly.
Choosing a limit order, another venue, or a later trade
The better alternative depends on which condition the pool swap could not meet. Where the chosen venue and network support it, a limit order fits a price-specific objective because it waits for matching execution at the specified terms. It may remain unfilled if no participant can satisfy those terms, so it is not a substitute for immediate liquidity.
Another onchain venue may offer a route with deeper usable liquidity or lower total execution cost for the same assets and network. Compare the actual output, permissions, and settlement evidence on equal terms. Moving assets to a different network introduces a separate transfer operation rather than improving the original pool.
A centralized order-book venue may suit an asset pair with stronger quoted depth there, provided its account and custody model are acceptable. Waiting can also be rational when network costs dominate a small exchange. Choose the immediate Uniswap swap when its live minimum output meets the objective; otherwise use the alternative that resolves the failed condition.
Good to know
Does a low price impact quote include every cost?
No. Price impact measures the change in pool price caused by the trade; it does not include every cost. Review the pool fee, network cost, any separate approval transaction, and any fee imposed by the token contract. Compare the expected and minimum outputs with the input because a low-impact trade can still be uneconomic when network costs dominate a small exchange.
When does an ERC-20 approval change the go-or-stop decision?
An ERC-20 approval changes the decision when the wallet has not granted the required permission or the existing allowance is insufficient. A new onchain approval can add a network cost before the swap itself. The request should name the intended token, spender, and amount. Rejecting an unexpected or overly broad request stops the process without authorizing the swap.
Why can the same swap fit on one network but not another?
Each network has its own pool liquidity, token identifiers, route availability, and transaction costs. Tokens with the same symbol on two networks remain separate assets, and depth on one network does not transfer to the other. Compare the exact token identifiers, effective output, minimum output, and required fee balance on the network where the assets already reside.
Which token behavior can make an otherwise usable route unsuitable?
Transfer fees and nonstandard balance changes can make the quoted route unsuitable. A fee-on-transfer token deducts an issuer-controlled charge during a transfer, which can alter the amount reaching the pool or wallet. Uniswap v3 and v4 routers do not support rebasing, reflection, or debasing tokens. Such behavior can cause execution to fail even when an ordinary ERC-20 route appears available.
Does a faster transaction setting solve a poor quote?
No. A higher-priority transaction setting may affect inclusion speed and network cost, but it does not add pool liquidity or reduce price impact. It also cannot remove a pool fee, token charge, or incompatible contract behavior. Use it only to address transaction timing after the quote already meets the minimum-output and cost boundaries.