Uniswap
Uniswap executes token swaps through liquidity pools and lets providers allocate capital to those pools
Uniswap lets a wallet exchange one compatible token for another through smart contracts, or supply tokens to pools that execute those exchanges. A swap changes the wallet's input and output token balances, while a liquidity position keeps capital in a pool and records ownership.
Swaps and liquidity across Uniswap protocol versions
Deployed protocol versions use different pool designs, but their basic relationship is consistent: liquidity providers fund markets, pool contracts execute swaps, and swappers authorize transactions within quoted limits. A wallet authorizes each action, and the network records it. The public interface is one access path; developers and other applications can interact with the contracts directly.
A quote previews the proposed swap
Swapping starts with an input token, an output token, an amount, and a compatible network. A routing system can evaluate available pools and paths, then return a quote. That quote describes an expected output under the present pool state, not a promise detached from execution. Confirmation asks the wallet to authorize a specific transaction.
Positions supply the pool
Providing liquidity starts with tokens, a pool design, and parameters such as the fee arrangement or price range. The pool contract receives the assets, while the provider's wallet receives the ownership record for the position. That record supports later fee collection, additions, or withdrawals under the chosen version's rules.
After the deposit settles, the ownership record tracks the provider's position. Deposited assets remain exposed to pool prices until the owner removes the liquidity.
The intended state change sets the action
Use a swap when the wallet should hold a different token after settlement. Use a pool position when assets should remain committed to market making. Direct contract use gives software another entry path when it needs protocol execution instead of manual interface use.
A swap changes wallet balances
An exact-input swap fixes how much leaves the wallet while the quote calculates output. An exact-output request fixes the desired receipt while the quote calculates required input, if the route supports it. Both depend on token compatibility, network state, liquidity, and permitted spending. A confirmed transaction proves settlement; a pending interface message doesn't.
A position records an ongoing claim
A liquidity action creates or expands a position instead of buying one token with another. Its inputs can include both pool tokens, a fee setting, and, in v3 or v4, a price range. The observable result is the position ownership record and updated liquidity. Removing liquidity returns the underlying assets in their then-current composition, which may differ from the deposit.
An integration assembles its own calls
Direct contract use suits applications that need programmable quoting, routing, or position management. It requires correct deployment addresses, version-specific interfaces, and transaction construction. An interface can package those details for manual use; integration code must handle them explicitly. This path changes who assembles the call, not the pool's underlying economics.
What determines a swap result?
Pool state determines the quote before anything else. Available liquidity along the route, trade size, fee settings, and any hook behavior can affect expected output. A larger order relative to active liquidity usually moves the pool price further. Price impact is the difference between the current market price and the estimated execution price resulting from the proposed trade.
Slippage describes movement between the quoted outcome and execution. A minimum-output limit protects an exact-input swap: if the executable amount falls below it, the transaction reverts rather than settling for less. Reversion doesn't necessarily refund the network cost because validators or sequencers still processed the attempt.
Routing may chain or split pool interactions to seek a better executable result. Before confirming the swap, review the expected output, price impact, minimum received, LP fees, and network cost together. Those values show whether the transaction stays within the wallet owner's limits.
A bounded swap with a reversible stop point
Compatibility determines whether the wallet can proceed beyond the quote. Every amount and threshold here is hypothetical: the wallet offers 136 units of an input token, and the compatible route quotes 41.8 output units with a minimum of 41.6.
Proceed when the contracts and network align
The connected wallet, selected network, and token contracts all match the quoted route. Before any onchain approval or swap confirmation, closing the request leaves the token balances unchanged. Suppose the reader approves and confirms, and the transaction records 41.7 output units. That amount exceeds the 41.6 minimum, the input balance falls by 136 units, and the confirmed transaction shows the swap settled. A separate network cost may appear in the network's fee token.
Correct mismatches before confirmation and reconcile afterward
If the wallet uses another network or the output contract doesn't match the intended token, don't authorize the swap. Align the network, reselect the intended contract, and request a fresh quote. If an approval already reached the chain, the swap balances haven't changed, but the allowance has. The owner can reduce or revoke it, although the approval's network cost can't be recovered. After swap confirmation, there is no protocol undo action, so reconcile the transaction status and final balances.
Liquidity ranges change capital use and maintenance
Uniswap v3 and v4 let providers concentrate liquidity inside a selected price range. Uniswap v2 positions use the full range.
Concentrated capital can support more trading within its active interval, but the provider must choose and monitor that interval. An in-range v3 or v4 position normally uses both pool tokens. Once the market moves outside the range, the position's principal becomes single-sided, and it stops supplying active liquidity or earning LP fees until the price returns. Changing the range requires removing liquidity and creating a new position. Relative price movement can also make a position worth less than separately holding the original assets. Full-range liquidity reduces range maintenance, though it spreads capital across prices where little trading may occur.
Fees, approvals, and network costs belong to different layers
The pool's LP fee comes from the swap input and follows the pool's configured fee logic. Active liquidity providers accrue that compensation, subject to the protocol version and any enabled protocol setting. Network cost instead pays validators or sequencers for processing approvals, swaps, and position changes. It can remain spent when execution reverts, so it belongs outside the pool fee comparison.
An ERC-20 approval doesn't exchange tokens. It authorizes a particular spender to use up to an allowance for one token. An exact allowance limits exposure but may require another onchain approval later; a larger allowance reduces repeat approvals but grants more spending authority. Some flows also use a Permit2 signature after an onchain approval. Review the spender, allowance, expiration if present, and requested action separately before signing.
Token identity, custody, and execution evidence
A token's network and contract address establish its identity; a name, logo, or ticker can't do that alone.
Permissionless pool creation means a visible market doesn't certify the token behind it. Confirm the contract identifier on the selected network, then inspect the quoted output, minimum received, route, allowance, and network cost. Onchain activity also exposes the wallet address and transaction data publicly. A self-custody wallet keeps control of the keys, but it can't reverse a confirmed transaction or recover assets sent to the wrong address.
After execution, compare the transaction status with changed token balances or the new position record. A centralized exchange typically settles on an internal account ledger under venue custody; Uniswap settles through wallet-authorized contracts and leaves an onchain record.
Practical questions about Uniswap
Does every token receive a safety review before a Uniswap pool can exist?
No. Permissionless pool creation allows markets without central listing approval, so a pool's existence doesn't validate a token's issuer, code, liquidity, or sellability. Names and tickers can be copied. Identify an asset by its contract address and network, and treat interface warnings or labels as signals rather than substitutes for that identity check.
How long can a pending Uniswap swap remain unsettled?
No single duration applies to every transaction. Timing depends on network conditions, submitted fee settings, and any deadline encoded in the swap. A deadline can make stale execution revert, but it doesn't force confirmation before that time. If a transaction remains pending, check its network status and wallet nonce before sending a replacement.
Can a failed Uniswap transaction still consume the network fee?
Yes. A validator or sequencer can spend computation processing a transaction that later reverts, so the network cost may remain charged even though the intended token transfers revert. A rejected wallet prompt or unsigned request hasn't reached that stage. Distinguish a local cancellation from an onchain failure before retrying.
Is liquidity locked for a fixed period when I provide it?
Uniswap core pool positions don't impose one universal fixed holding period. The position owner can generally remove liquidity by submitting the required onchain action, but network costs, version rules, hooks, or an external incentive program can change the practical conditions. Review the actual pool and any attached contract logic before treating liquidity as immediately available.
Do I need UNI to swap or provide liquidity?
No. Holding UNI isn't a universal requirement for a protocol swap or pool position. The wallet needs the input asset, any second asset the chosen position requires, and enough of the network's fee token for onchain steps. UNI serves governance functions rather than acting as a mandatory access pass.