Uniswap on Bitsy Services Wiki

ISwapRouter — Uniswap V3 Swap Guide

Mon, 01 Jan 0001 00:00:00 +0000

ISwapRouter is the interface your contract (or off-chain script) calls to execute token swaps through Uniswap V3 pools. It lives at:

@uniswap/v3-periphery/contracts/interfaces/ISwapRouter.sol

The canonical deployment is the SwapRouter contract. On most chains the address is 0xE592427A0AEce92De3Edee1F18E0157C05861564.

Note: Uniswap has since shipped SwapRouter02 (combines V2 + V3 routing) and the UniversalRouter (V2, V3, Permit2, NFT purchases). For new integrations, evaluate those first — they offer better gas efficiency and approval flows via Permit2. This guide covers the original SwapRouter, which remains widely deployed and is the simplest to learn from.

SwapRouter vs SwapRouter02 vs UniversalRouter

Mon, 01 Jan 0001 00:00:00 +0000

Uniswap has shipped three generations of swap routers. Each builds on the last, adding protocol support and improving gas efficiency and approval UX. This page compares all three to help you choose the right one.

At a Glance#

	SwapRouter	SwapRouter02	UniversalRouter
Protocols	V3 only	V2 + V3	V2 + V3 + V4 + NFTs
Approval model	Per-token `approve`	Per-token `approve`	Permit2 signatures
Multi-call batching	No	`multicall()`	Command-based execution
ETH handling	Manual wrap/unwrap	Built-in wrap/unwrap	Built-in wrap/unwrap
Gas efficiency	Baseline	Moderate improvement	Best (single `transferFrom` per token)
Interface	`ISwapRouter`	`ISwapRouter02`	Encoded command bytes
Status	Legacy — widely deployed	Production — simpler integration	Recommended for new projects

SwapRouter (V3)#

The original V3 swap router. It exposes a clean Solidity interface (ISwapRouter) with four functions: exactInputSingle, exactInput, exactOutputSingle, and exactOutput. See the ISwapRouter guide for full details.

Ticks

Mon, 01 Jan 0001 00:00:00 +0000

A Uniswap V3 or V4 pool does not track a continuous price. It tracks an integer called the current tick, and the price is a function of that integer. Every position’s range boundary, every initialized price point, and every sqrt-price stored on chain is ultimately a tick.

Ticks exist because concentrated liquidity needs to discretize the price axis. Liquidity providers must choose a range, and the pool must be able to add or remove their liquidity efficiently as the price crosses range boundaries. Doing that with arbitrary-precision real numbers is intractable; doing it on a lattice of integer tick indices is fast and deterministic.

Single-Tick Liquidity

Mon, 01 Jan 0001 00:00:00 +0000

A single-tick liquidity position is a Uniswap V3/V4 position whose range is exactly one tick wide — the narrowest range the protocol allows. Inside that one tick the position stops behaving like a curve and starts behaving like a fixed-price block of depth: trades fill at an almost constant rate until the position is exhausted, then price jumps to the next tick. It is the building block behind on-chain limit orders (“range orders”) and behind the price corridor a par token lives in.

Fee Distribution in Concentrated Liquidity

Mon, 01 Jan 0001 00:00:00 +0000

In Uniswap V2, every liquidity provider owns a fraction of a single, full-range pool. Fees accrue to the reserves themselves, so an LP’s share grows automatically: when you burn your LP token you withdraw slightly more of each asset than you deposited, and the difference is your fees. No per-LP bookkeeping is needed because there is nothing to book — the pool is one giant homogeneous pot.

Concentrated liquidity breaks that symmetry. Each position occupies its own price range, and only positions whose range contains the current price earn fees on a given swap. The naïve implementation would keep a list of active positions and, on each swap, iterate over them paying out pro-rata. That would be catastrophic: gas per swap would scale with the number of LPs, and a single spammer could brick the pool by opening a million dust positions.