Desk note · 2026-11-06 · Sources: Uniswap developer docs, Uniswap v2 whitepaper, DefiLlama, dYdX terms
Trace a single swap of USDC for a volatile token on a decentralized exchange and the moving parts show up in order. The wallet grants a token approval. A router contract receives the order, splits it across one or more pools, checks the output against a minimum the user signed, and either completes the whole thing or reverts. No account is opened, no exchange holds the user’s balance between trades, and settlement happens in the same transaction as execution.
That last point is the defining feature. A centralized exchange keeps an internal ledger and settles on-chain only for deposits and withdrawals. A DEX settles every trade on-chain, so the exchange never takes custody. DefiLlama’s DEX dashboard recorded about $11.68 billion of volume across tracked DEXs on 2026-11-05.
Three ways to match a trade
Automated market makers
Most DEX volume runs through pools: contracts holding two or more tokens, priced by a formula. Uniswap v2 uses the constant product rule described in its whitepaper, where the product of the two reserves cannot decrease after a trade. Anyone can deposit into the pool and earn the swap fee. The formula and a worked example are in automated market makers explained; the depositor’s side is in liquidity pools and impermanent loss.
Later designs changed the shape of liquidity rather than the principle. Uniswap’s concentrated liquidity docs note that the v2 DAI/USDC pair used only about 0.50% of its capital for trading between $0.99 and $1.01. In v3 and v4, liquidity providers pick a price range, so the same capital provides deeper liquidity near the current price, and positions outside the range earn nothing.
On-chain order books
An order book DEX records bids and asks and matches them, like a traditional exchange, but the matching engine runs inside a blockchain’s state machine. This needs very high throughput and cheap transactions, so order book venues tend to live on application-specific chains or high-throughput layer 1s. Most perpetual futures venues use this model. See perpetual futures.
Intents and request-for-quote
The third design separates the user’s order from its execution. The user signs an intent (“sell X for at least Y before time T”), and third-party fillers compete to execute it from whatever liquidity they can find, including their own inventory or centralized venues. Uniswap’s developer docs describe UniswapX fillers settling orders through Dutch auctions on some chains and priority-fee auctions on others. The user gets price competition and avoids paying gas for a failed trade; the trade-off is reliance on an off-chain filler network for execution quality.
Fees, as published
Uniswap’s fee documentation gives a clean view of how DEX fees have evolved:
| Version | Swap fee | How LP fees are paid |
|---|---|---|
| v2 | Flat 0.30% on every pool | Added to reserves, compounds automatically |
| v3 | Standard tiers 0.05%, 0.30%, 1% (more enabled by governance) | Claimable balance per position |
| v4 | Any fee from 0% to 100%, or dynamic via hooks | Claimable balance per position |
Uniswap’s docs also state that after the UNIfication governance proposal passed in December 2025, protocol fees are active on all v2 pools and select v3 pools, set at about one-sixth of the swap fee at launch. On a v2 pool that means a 0.25% LP fee plus a 0.05% protocol fee. Fee settings are governance parameters and can change.
Gas is the other cost. On Ethereum mainnet it can exceed the swap fee for small trades, which is why most retail-sized DEX activity has migrated to rollups.
What actually determines the price you get
Four variables set execution quality on an AMM:
- Pool depth. A trade that is large relative to reserves moves the price along the curve. This is price impact, and it is deterministic.
- Fee tier. The fee is taken from the input before the formula runs.
- Slippage tolerance. The minimum output the user signs. If the pool moves between signing and inclusion, the trade reverts rather than filling worse than that limit.
- Transaction ordering. Block builders decide the order of transactions in a block. A searcher who sees a pending swap with a loose slippage limit can buy before it and sell after it (a sandwich), capturing the gap up to the user’s tolerance. This is one form of maximal extractable value (MEV). Tight slippage limits, private transaction submission and intent-based routing are the usual mitigations.
DEX vs centralized exchange, side by side
| Dimension | DEX (AMM or on-chain book) | Centralized exchange |
|---|---|---|
| Custody between trades | User’s wallet | Exchange’s wallets, internal ledger |
| Settlement | On-chain, per trade | Internal; on-chain only for deposits and withdrawals |
| Listing | Permissionless; anyone can create a pool | Exchange decides |
| Counterparty failure mode | Contract bug, oracle or admin-key failure | Insolvency, hack, withdrawal freeze |
| Execution visibility | Pending transactions visible to searchers unless sent privately | Order book visible; matching internal |
| Identity checks | None at contract level; front ends may screen | KYC required by regulated venues |
Neither column is risk-free. The DEX column swaps counterparty risk on a company for technical risk on code and on whoever controls the code’s upgrade path. Which risk is easier to assess depends on how much of the code, its audits and its admin permissions a user can actually check. Admin permissions can be read directly from the contracts on a block explorer.
Risk notes specific to DEX use
- Token approvals. Approving a router for an unlimited amount means a later compromise of that router or a malicious contract posing as one can move the approved balance. Revoking stale approvals is routine hygiene.
- Look-alike tokens. Anyone can deploy a token with any name and create a pool for it. The contract address, not the ticker, identifies the asset.
- Hooks and custom pools. Uniswap v4’s hooks let external contracts run custom logic around swaps and liquidity changes, including custom fees. A pool’s hook is code with its own risk profile.
- Front-end risk. The website is a separate piece of software. A compromised domain or injected script can request a malicious signature while the contracts stay untouched.
- Thin liquidity. Small pools are easy to move, which matters for anyone else relying on that pool as a price source. See the oracle section of the DeFi risk checklist.
Access and jurisdiction
The contracts are permissionless, but interfaces are run by companies with terms of service, and many restrict users by location, especially for derivatives. dYdX’s software terms (last updated 2026-03-12), for instance, list persons located in the United States, Canada or the United Kingdom as restricted persons for its perpetuals trading software. Swap front ends for spot tokens are generally less restricted, but token lists and available assets can differ by region.
Nothing here is a recommendation to trade on any venue; it describes how the venues work.
A short checklist before a first swap on an unfamiliar DEX
- Confirm the contract addresses of both tokens from the issuer’s own docs.
- Check pool depth relative to trade size and look at the quoted price impact.
- Set a slippage limit that reflects the pool, not a default left at a high value.
- Read what the approval request covers before signing.
- Check whether the route touches pools with hooks or unaudited contracts.