Decentralized exchanges

In brief

A DEX is a trading venue whose matching or pricing, and typically the custody of trading inventory, live in on-chain programs rather than in a single exchange’s database. Two large families exist: order books and automated market makers (AMMs). Uniswap popularized the constant-product AMM on Ethereum; it is an example, not the definition. Liquidity providers supply reserves and earn fees; they take inventory risk often called impermanent loss. Traders face slippage, price impact, smart-contract risk, token risk and MEV. A website is not the protocol. A DEX can still have centralized sequencers, admin keys, allowlists and off-chain routers.

What a DEX is — and is not

On a centralized exchange, you deposit assets. The exchange credits an internal balance, matches orders on its servers, and (if you withdraw) sends tokens back on-chain. Counterparty risk is the firm.

On a DEX, a swap is usually a blockchain transaction. You authorize a program to move tokens from an account you control into a pool or against an order, and you receive the other asset in the same transaction (or after a defined settlement). You do not hand the venue a standing deposit of everything you might trade — though you may approve a token contract to spend on the program’s behalf, which is its own permission.

“Non-custodial” here means the venue does not take your private key. The pool still holds the reserves. A buggy or admin-controlled program can lose or freeze those reserves. An ERC-20 with a blacklist can freeze the token even if the DEX is honest.

DEXs exist on Ethereum, Solana, other L1s and many L2s. They are not an Ethereum monopoly. Token models differ: an Ethereum swap moves balances in ERC-20 contracts; a Solana swap moves amounts in token accounts owned by a Token Program.

Two architectures

Order books

An order book lists bids and asks. Makers post prices; takers lift them. This is how most stock and crypto centralized exchanges work.

On-chain order books put that structure in a program. Placing, cancelling and matching orders can require on-chain transactions, so feasibility depends partly on a network’s costs and capacity. Some designs keep the book off-chain and settle trades on-chain (a hybrid). OpenBook V2, derived from earlier OpenBook and Serum code, is a current Solana central-limit-order-book program. Ethereum has had on-chain and hybrid books as well. This article does not pick a winner. The point is: AMMs are not the only DEX.

Order-book users care about maker/taker fees, spread, and whether the matcher can front-run or censor. Hybrid books reintroduce an operator who sees the book.

Pool-based automated market makers

A common pool-based AMM replaces the book with a liquidity pool and a rule that turns reserve balances into a price. This is the family discussed below, not a universal definition of every mechanism called an AMM.

Uniswap’s documentation states the design: instead of matching buyers and sellers, the protocol holds reserves of two tokens and prices them against each other. Anyone may deposit both sides and become a liquidity provider (LP). Anyone may swap against the pool.

Uniswap v2’s whitepaper (Adams, Zinsmeister, Robinson, March 2020) describes the core constant-product invariant:

[ x \cdot y = k ]

Here (x) and (y) are the reserves. A trade that takes (\Delta x) of token X must put in enough of token Y so that the product of the new reserves does not fall (fees can make (k) rise). Large trades relative to the pool move the price more. That movement is price impact. It is not a bug; it is the function.

Uniswap v1 only paired tokens with ETH. v2 allowed arbitrary ERC-20/ERC-20 pairs, added a time-weighted price accumulator intended to be harder to manipulate than the spot price, and added flash swaps: receive the asset first, use it, pay before the transaction ends. v2 charged traders 30 basis points, paid to LPs; a 5 bp protocol fee could be turned on later by a key on the factory. Later versions (v3 concentrated liquidity; v4 hooks and a singleton) change where liquidity sits and how fees work. They are still AMMs.

Other pool-based AMMs use different curves (stable-swap curves for similar-priced assets, weighted pools, concentrated ranges). Their family resemblance is inventory in a program, a pricing rule, and liquidity providers taking the other side of trades.

Liquidity providers

An LP deposits a pair (or a range, in concentrated designs) and receives a claim on the pool — in Uniswap v2, a fungible pool token; in v3, often an NFT that represents a position.

LPs earn a share of swap fees. They also hold a changing mix of the two assets. If one asset rallies, the pool sells it into the rise (that is how the invariant works). Compared with simply holding the original deposit, the LP can end the period with less value. That gap is widely called impermanent loss (the EEA guidelines also mention divergence loss and LVR). Withdrawing realizes the position at its current mix; later price reversals no longer change that exited position. Fees may or may not offset the shortfall. There is no promise that they will.

Providing liquidity is not “earning yield on cash.” It is running a market-making inventory.

Slippage, price impact and routing

Price impact is the difference attributable to this trade’s size relative to available liquidity: the pre-trade reference price versus the size-adjusted execution expected from the quoted route.

Slippage, using the stricter distinction in this corpus, is how much the actual executed price differs from that size-adjusted expected price after submission because of market movement, other trades, routing or ordering. Some interfaces and sources use “slippage” more loosely for the entire pre-trade-reference-to-fill gap, which combines price impact with those later changes. Wallets let users set a slippage tolerance. In a typical exact-input AMM-router swap, a minimum-output check reverts the transaction if the fill would be worse than the limit; order-book, RFQ and other venues can behave differently, including partial fills. A very wide tolerance can give an adversary more room to worsen the execution.

On a large ecosystem, the best price is often a route: A→B via A→C→B, or a split across several pools. Aggregators compute or solicit routes across venues and submit one transaction. Jupiter’s current Solana API, for example, combines an on-chain router with other routing and request-for-quote engines. The aggregator adds its own code and operators to the trust and failure model; the underlying pools or market makers still supply the liquidity.

Fees

Three different fees get mixed in conversation:

1. Network fees — Ethereum gas, Solana signature + CU priority, Bitcoin weight. Paid to produce the transaction. See Gas fees.
2. Swap / LP fees — the 30 bp (or other) cut that stays in the pool or goes to LPs.
3. Protocol / interface fees — a share taken by governance or by the website you clicked.

Uniswap v2’s paper is explicit that the 30 bp goes to LPs unless a protocol fee is switched on. A front end can charge more without changing the core contracts.

MEV and ordering

Publicly broadcast pending transactions may be visible before execution. Builders, relays, leaders or other parties with privileged order-flow access can use that information when constructing a block. The EEA guidelines describe the usual attacks in beginner language:

• Front-running: insert a trade before yours to take the opportunity you spotted.
• Back-running: insert a trade after yours to catch the arbitrage you created.
• Sandwiching: buy before you, let your trade push the price, sell after you.

This is usually discussed as MEV: originally “miner extractable value,” now more often “maximal extractable value.” On Solana, leaders and specialized transaction-routing infrastructure create different but related ordering opportunities. Private order flow, batch auctions and slippage limits are mitigations, not magic; private routes also shift trust toward the intermediaries that can see them.

A DEX that is “decentralized” at the contract layer can still have a centralized sequencer on a rollup deciding order. That is a real central component.

Impermanent loss, again, without the slogan

Suppose a 50/50 pool holds token A and token B, each worth $1, and A later trades at $4 while B is still $1. Arbitrage will drain A from the pool until the internal price matches the outside market. The LP now holds less A and more B. Marked to market, that bag is worth less than having held the original A and B outside the pool. Fees collected in between may fill the hole. They may not.

The loss is “impermanent” only if prices revert before you withdraw. That is a nickname, not a guarantee.

Smart-contract and token risk

A pool is a program plus token contracts (or token accounts). Risks stack:

• a bug in the AMM;
• a bug or hook in the token (transfer fees, blacklists, rebase);
• an infinitely mintable or spoofed token listed because listing is permissionless;
• an upgrade or admin pause;
• an oracle module, if the venue uses one for a derivative or a lending pair.

Uniswap’s v2 paper warns that using the spot price as an on-chain oracle is unsafe: an attacker can move the price, trigger another contract, and move it back in one transaction (or with a block producer’s help). That is why v2 accumulated a time-weighted price. Other protocols that still read spot prices inherit that attack.

Permissionless listing means the existence of a pool is not an endorsement of the token.

Front end versus protocol

Uniswap’s docs describe the protocol as open-source and its core contracts as non-upgradeable. The app.uniswap.org website is a separate interface. Like any hosted interface, it can apply its own policies, choose routes, charge an interface fee or go offline without changing the deployed protocol. Anyone can host another interface to the same contracts — or a lookalike that points at a different contract.

Users who only ever click one website are trusting that website’s operators, DNS and servers, plus the contracts. A seized or compromised front end is a standard failure mode. The EEA treats UI risk as its own category (injection, spoofing, confusing copy).

The same split applies to every well-known DEX brand.

Central pieces that often remain

A venue can be a DEX and still have:

• a company that writes the contracts and the app;
• an admin key or a multisig that can pause, set fees, or upgrade;
• a token allowlist on the interface;
• off-chain limit-order services;
• a rollup sequencer;
• a router or aggregator run by one team;
• KYC at the website even if the contracts are open.

Those facts do not make the design “fake.” They make “decentralized” a property that must be checked layer by layer.