DEX vs CEX Market Making: What's Different?

An order book is a list of resting buy and sell orders. Market makers post those orders, cancel them, and repost as conditions change. Price is discovered by matching. Depth is whatever the participants choose to show, and it can disappear in seconds if quoting is withdrawn.

An automated market maker is a pool of two assets governed by a pricing curve. Anyone can deposit, and the pool quotes every price along that curve automatically. Depth is a function of pool size and, on concentrated liquidity designs, of the ranges providers have chosen. Nothing can be cancelled: the pool trades whether or not the provider is paying attention.

The practical consequence is that the two architectures fail differently. An order book can go quiet because nobody is quoting it; a pool cannot go quiet, but it can be drained or pushed to one side of its curve until it stops offering a usable price on either asset. Founders comparing the two should ask which failure mode they are more able to detect and repair quickly.

Order-book makers carry inventory risk. If your token falls while they hold it, they lose, so they widen spreads and reduce size in volatile conditions. That is rational behaviour, not abandonment, though it looks alarming on a chart.

Pool providers carry divergence loss, often called impermanent loss: when the token moves sharply in either direction, the pool rebalances against the mover and the provider ends up with more of the weaker asset than they deposited. Fees can offset this in high-volume pools; in low-volume pools they usually do not.

Take a $20,000 market buy. On a healthy order book with $150,000 of depth within 2% of mid, that order walks a handful of price levels and the buyer's average fill sits close to the quoted price, perhaps 0.3% above it. The book absorbs it and other participants barely notice.

Run the same $20,000 buy through a $200,000 constant-product pool and the price impact is mechanical and much larger, often 5–8% depending on the curve, because the pool must move along its pricing formula rather than simply match against resting size. The buyer pays for that impact directly, and the pool is now imbalanced until an arbitrageur or the next trader corrects it.

This is why pool size needs to be set with expected trade size in mind rather than as a round number. A pool sized for retail curiosity will produce headline-grabbing slippage the first time anyone tries to buy a meaningful position, regardless of how healthy the token's fundamentals are.

Modern AMM designs let providers deposit within a chosen price range, multiplying effective depth inside that band. This is powerful and dangerous in equal measure: a tight range around the current price produces excellent depth until the price leaves the range, at which point the position is entirely in one asset and quoting nothing on the other side.

That is why active management matters even on a DEX. Ranges need rebalancing, and the decision of how wide to set them is a real strategy question tied to your token's volatility, not a set-and-forget deposit.

Almost always the DEX pool. It is permissionless, it establishes an on-chain reference price, and it lets a community trade from day one without a listing approval. Size it deliberately: a pool too small to absorb a normal buy produces exactly the volatile chart you are trying to avoid, and it becomes a target for sandwiching.

Centralised listings follow when there is enough float, distribution, and demonstrable volume to justify them. At that point an order-book mandate becomes necessary, because a CEX book left unquoted is worse for perception than no CEX listing at all.

A thin pool is not just a slippage problem; it is a target. Bots watch the mempool for pending swaps large enough to move price, then front-run the trade with a buy, let it execute, and sell immediately after — extracting the difference from the original trader. This is more profitable, and more likely to be automated against your token, the shallower the pool is relative to typical trade size.

Deeper pools and, on chains that support it, private transaction routing both reduce the opportunity. Neither eliminates it entirely, so it is worth telling holders plainly that using a swap aggregator with slippage protection is safer than trading directly against a thin pool during volatile periods, rather than leaving them to discover the cost themselves.

Once a token trades on a pool and a book simultaneously, the two will drift apart unless somebody arbitrages them. Independent arbitrageurs will do this for free, but they extract the difference, and during volatility the gap can be wide enough to embarrass a project on aggregator sites showing divergent prices.

A competent market maker treats the pool as part of the venue set and arbitrages it deliberately, keeping the on-chain price tethered to the deepest book. Ask any prospective provider explicitly whether on-chain venues are in scope — many quote only centralised venues by default.

There is no universal ratio, but the logic is stable: put enough in the pool to make on-chain trading non-punitive for retail size, and concentrate the remainder where price discovery genuinely happens. For most tokens with a centralised listing, that means the deeper book carries the majority of committed depth while the pool is sized for accessibility rather than institutional size.

Review the split quarterly against actual volume by venue. Liquidity parked where nobody trades is dead capital with a monthly cost attached.

Bridging or deploying the same token natively on several chains multiplies the venue problem: each chain now needs its own pool, its own depth, and its own arbitrage link back to wherever price discovery actually happens. Liquidity split six ways across three chains and two exchanges tends to leave every single venue thin, which is worse for holders than one or two deep venues.

If a multi-chain footprint is a genuine product requirement, treat it as a liquidity budgeting exercise before launch, not an afterthought once complaints start about a particular chain's pool being unusable. Decide which chain carries primary price discovery and size the others as secondary, arbitraged venues rather than as equals.

Total trading cost is never just the spread. On a CEX, a taker pays the quoted spread plus an exchange fee, typically a handful of basis points, and settlement is instant with no separate network cost. On a DEX, a taker pays the pool's slippage for their trade size, a pool fee tier baked into the swap, and a network gas fee that is independent of trade size and can dominate the total cost of a small trade on a congested chain.

This matters for how you talk to holders about where to trade. A $50 swap on an expensive chain can carry a gas fee larger than the trade itself, which is not a liquidity failure on your part but it will look like one to a first-time buyer. Publishing simple guidance on typical costs by venue and chain heads off a predictable category of support complaints.