Three architectures, three different counterparties

Three ways to get filled on a decentralised exchange, and they are not three brands of the same thing. They answer one question three different ways: who is your counterparty, and who sets the price?

• AMM. You are the counterparty. Price is a function of pool state, which means your own trade is what rebalances the pool.
• CLOB. You are a queue. You name your price, price-time priority decides when you are filled.
• RFQ. You are an auction item. The protocol does not set your price; quoters do, and they compete to be first.

Everything that follows is a consequence of that one difference.

AMM: you are the trade that rebalances the pool

Uniswap's documentation is plain about what a swap is against. Swaps "are not executed against discrete orders on a first-in-first-out basis. Instead, swaps execute against a passive pool of liquidity, with liquidity providers earning fees proportional to capital committed."

Your price is not a number someone posted. It is the output of a function. Uniswap describes the mechanics as a constant product, x * y = k, where k is an invariant that "must stay constant (or increase) after every trade." The consequence: "larger trades relative to pool depth move the price more (known as price impact), while smaller trades execute closer to the current spot price."

Read that sentence twice, because it is the whole AMM case. Your execution price is not just the price before your trade. It is an average across the segment of the curve you traversed. The Uniswap docs make the inventory mechanism explicit: "In an automated market maker, the relative value of one asset in terms of the other continuously shifts during swap execution, leaving the final execution price somewhere in between where the relative price started and ended."

So the AMM does not have a bug in it that a better router fixes. The slippage is the mechanism. Your trade moves reserves; the invariant has to hold; the marginal price changes as you push through it. You are the trade that rebalances the pool.

Concentrated liquidity makes the pool deeper around the mid without removing that. Uniswap quantifies the waste it fixes: the v2 DAI/USDC pair "uses ~0.50% of total available capital for trading between $0.99 and $1.01, the price range where most volume typically occurs." Same curve, narrower band. The docs describe the execution path as crossing discrete intervals, and note that crossing an active tick "increases the cost of the transaction in which it is crossed." The word Uniswap uses is lower, not zero: concentrated liquidity "may lower swap price impact."

Your protection is a bound, not a price. amountOutMinimum defines the worst output you will accept, and if execution would return less than it, the transaction reverts. v3 enforces the limit in the contract through sqrtPriceLimitX96. That is the right shape: you cannot dictate the AMM's price, but you can refuse the trade.

Curve reduces the slope, it does not remove it

Curve's StableSwap is the clearest documentation of a curve being bent rather than deleted. The StableSwap overview states that the algorithm "integrates features of both the constant sum and constant product formulas, adjusting between these models based on the balance of assets in the pool," and is designed to "offer lower slippage in stablecoin transactions compared to other common algorithms like the constant-product invariant."

The bending is governed by one parameter, the amplification coefficient A. Curve's Cryptoswap documentation spells out the trade-off without hedging it: a "higher A (e.g., 1,000–20,000) concentrates liquidity more tightly around the peg," but "if an asset moves far from the peg, liquidity and pricing can drop off sharply." A "lower A (e.g., 50–200) distributes liquidity more evenly."

That is a depth-versus-tail choice, not a free lunch. You can buy tight-peg depth or you can buy graceful behaviour far from the peg. Curve does not let that trade be improvised: modifying A on a deployed pool "requires a vote within the Curve DAO and must reach a 15% quorum."

Curve's own impermanent-loss admission. Curve does not claim to have solved it, and it explains why solving it is impossible. On rebalancing: "rebalancing realizes impermanent loss." The docs require two conditions before a Cryptoswap pool rebalances, and the second one is the boundary that matters: "The cost of rebalancing must be less than 50% of the trading fees earned by LPs. This core safeguard ensures that impermanent loss is only realized when it is sufficiently offset by trading profits."

Note the wording. It does not prevent the loss, it decides when the loss may be realised. And Curve then publishes the cost of that protection in trader-facing terms. A Cryptoswap pool "can sometimes cause a pool to become stuck" because its last rebalance price diverged from the current price, which "can trigger a negative feedback loop: as the market price moves away from the pool's last rebalance price, the available liquidity for traders decreases. This leads to fewer swaps and, consequently, lower fee generation."

Protecting the LP from realised IL starves the trader of depth. That is the trade, stated in the protocol's own documentation. Rebalances trigger off an exponential moving average of recent prices rather than the last price, which Curve says "helps prevent manipulation of the rebalancing mechanism." The mechanism is honest engineering. The boundary is what you trade against.

The trade that pays an LP a fee is the same trade that moves the LP's inventory against them. Strip the rebalancing out and you do not get an IL-free AMM. You get a pool quoting a stale price that gets arbitraged apart. Curve states why the arbitrageur exists: an imbalance large enough to break the peg "creates an arbitrage opportunity. This incentivizes traders to rebalance the pool."

The one empirical number, with its vintage stated

In that one 2021 sample, fee income did not offset the inventory cost. The most-cited measurement is Loesch, Hindman, Richardson and Welch, "Impermanent Loss in Uniswap v3," an arXiv preprint submitted 17 November 2021. For 17 pools covering 43% of total TVL, total fees earned since inception were $199.3m; total impermanent loss suffered was USD 260.1m; in aggregate "those LPs would have been better off by USD 60.8m had they simply HODLd."

Read the date. It is a 2021 dataset covering early v3 only. It does not describe today's pools. What survives is the structural point, which does not depend on the sample: the fee and the loss come from the same trade, so a protocol can charge for the flow or insulate the inventory, but not both.

CLOB: you are a queue, and the queue has rules

A CLOB replaces the curve with your own limit price. If your order fills, it fills at the price you named. There is no residual-curve cost to walk, and that is a real advantage.

The matching rule is stated identically by both venues in this article's source set. Hyperliquid's order book documentation says orders "are matched in price-time priority," with prices at integer multiples of the tick size and sizes at integer multiples of the lot size. dYdX says block proposers build blocks with "matches generated by price-time priority."

Price-time priority is the whole mechanism, and it cuts both ways. It gives you the floor you named. It also means your position in a queue decides your fill, and thin levels are fragile. If price trades through your level while you are behind others, you get no fill and the full adverse move.

Two venue-specific facts make that concrete.

Hyperliquid re-checks margin at match time. Margin checks "happen on the opening of a new order, and again for the resting side at the matching of each order." The stated reason: it "ensures that the margining system is consistent despite oracle price fluctuations after the resting order is placed."

dYdX orders expire by block height, and cancel is not immediate. Every placement or cancellation "includes a GTB (good-til-block) field, which specifies the block height after which the instruction expires." The documented failure mode: "While rare, it is possible for a cancel instruction to be seen by the current block proposer but not by one or more subsequent proposers (if the instruction isn't gossiped to them in time through the p2p network). In such cases, the order could still match after the sender expects it to have been cancelled."

So dYdX's own advice to API traders is to set tight GTB values, for example "the current chain height + 3." The reason is that GTB expiry is the one mechanism dYdX treats as certain, and it says so in one line: "Consensus does not permit any order to fill at a height greater than its GTB."

There is a related hazard worth naming, because dYdX documents it as the reason to use replacements rather than cancel-then-place: a "place order A, cancel order A, place order B" sequence can see both orders fill at once. If a proposer "sees messages 1 and 3, but not 2, it sees both orders A and B as open," and with matching bids "both could fill simultaneously." Hence "We recommend using replacement instructions over cancelling and placing new orders."

The book is not the same object on both chains. dYdX keeps the book in node memory: each full node "maintains an in-memory order book," and because message arrival order varies, "the order book may differ across the network at any given point in time." Nodes reconcile only on seeing a new committed block. Hyperliquid inverts this: "HyperCore does not rely on the crutch of off-chain order books." Its mempool and consensus logic are "semantically aware" of order-book transactions, and within a block actions are sorted: non-order actions first, then cancels, then GTC and IOC actions.

The boundary: no curve, yes, but you now trust a book instead of an invariant. And on perps the book needs an anchor. Hyperliquid computes prices as "the weighted median of CEX spot prices for each asset, with weights depending on the liquidity of the CEX."

RFQ: you are an auction item, and quoters set your price

This is where the price-setting question inverts. In an AMM the price is a function of state. In a CLOB the price is the number you named. In an RFQ the price is set by inventory-holding counterparties competing to be first to fill you.

The UniswapX overview describes the item. Swappers "generate signed orders which specify the outputs of their swap, and fillers compete to satisfy these orders using their own filling strategies." Timing is the price mechanism: "The realized price depends on when the first successful filler settles within the auction timeline."

And the boundary the UniswapX whitepaper draws is the sharpest architectural statement in this whole piece. The UniswapX protocol "does not enforce a specific decay function. Similarly, the protocol does not prescribe a method for setting the initial Dutch order price." The decay curve bounds when the price gets worse. It does not choose who picks it. That job belongs to the quoters.

The two-phase quote. Uniswap's auction-types documentation describes what happens while you browse. Two quotes are fetched in parallel: a Classic Quote from the AMM route, and a UniswapX Quote "determined via a Request for Quote (RFQ) process with quoters. Because of the nature of the system, this set of market makers is permissioned and known to Labs." The best soft quote is compared against the Classic Quote, and if the X quote wins, "the user is shown a purple lightning bolt." When you sign, the request goes to Uniswap Labs' server, "which requests a final 'hard quote' from the group of quoters." Whichever hard quote is highest "wins exclusivity and gives the quoter a short exclusivity window to fill the order."

The timing, as documented. On Ethereum the exclusivity window "is currently about 24 seconds (2 blocks)." After exclusivity ends, the price "decays for about one minute, and the order then expires." Decay begins at the end of exclusivity, with the starting price "at or slightly below the quote the exclusive filler committed to," and bottoms out "at the minimum the swapper signed for, which is their slippage tolerance."

The curve is not a straight line. The price moves "block by block along a multi-point curve, not a single straight line." Cosigners set the window per order "while never exceeding the user's slippage tolerance," and they do it to compensate for "the delay between quoting and signing (which can be up to 30 seconds)." The window is not a protocol constant, because "the cosigner sets the window per order."

One more documented case, because it inverts the usual reading of exclusivity. If the winning quoter declines because "price moved against them," that is defined as "fading." The system "can penalize quoters who fade too frequently by ignoring their quotes for a period of time." If no quoter delivers the signed amount, "the order is sent out without exclusivity, meaning anyone can fill the order."

The trust boundary is stated in the documentation, not inferred. UniswapX is described as "a permissionless, open source, auction-based swapping protocol." That describes the fill. The docs draw the other half explicitly: quoters "are permissioned, while fillers are permissionless." The current cosigner is Uniswap Labs. Do not read "permissionless" as open access to the quote side. It is not.

RFQ does not remove the other two architectures. It hides them. The overview is explicit that "Fillers provide their own liquidity or route through external sources to satisfy order outputs," and the routing documentation confirms solvers "can use proprietary routing strategies and token inventories to fill intents." Fillers hold inventory or borrow it from AMMs and other venues. RFQ changes who holds it and how competition is structured. It relocates price formation into a small set of quote-bearing firms rather than removing price formation. You are still filled by someone's inventory or some curve.

When a CLOB is worse than an AMM

Three cases, each grounded in the sources above.

A thin book. Price-time priority means your fill depends on being ahead of others at your level. The fewer orders rest there, the more likely a fast move trades through the level without reaching you. An AMM has no queue. It quotes against reserves and returns an average across the curve. Thin liquidity is where the CLOB's advantage inverts.

The long tail, proven by the RFQ layer. This is the strongest available evidence, because it comes from a permissionless auction network with professional market makers declining work. Uniswap's routing documentation states that "UniswapX quotes may be unavailable when solvers cannot or choose not to fill a swap," and separately that "On some chains, UniswapX quotes are subject to minimum notional thresholds, and solver participation may vary by trade size and market conditions." The API adds its own line item: UniswapX routing is included "when the order is worth more than 300 USDC equivalent, or when the UniswapX quote improves on the AMM route by at least 0.2%."

Read that backwards. Firms running competitive auctions with professional inventory pass on small or illiquid flow, because it is not worth their hedging cost. A passive CLOB requires an independently motivated maker to post at all. It degrades earlier and harder.

Below the notional threshold. At a size where nobody is obliged to quote you, the RFQ has no quote, and a book thin enough to hold that price has no depth either. The AMM is the only venue still quoting, because its liquidity does not need anyone to decide to show up.

What Uniswap v4 changes, and what it does not

v4 alters the cost and settlement path of a fill. It does not change the price mechanism.

The v4 architecture documentation is explicit on the first: all pool state and operations run through "a single contract, PoolManager.sol." The singleton "provides major gas savings," because "creating a pool is now a state update instead of deploying a new contract," and "Swapping through multiple pools no longer requires transferring tokens for intermediate pools." Settlement changed with it, via flash accounting on EIP-1153 transient storage, where balance changes "are efficiently recorded in transient storage and netted against each other," so users "only pay the final balance change, without resolving intermediate balance changes."

The price mechanism is untouched. v4 "inherits all of the capital efficiency gains of Uniswap v3," and the default fill path is still the concentrated-liquidity curve. What v4 adds on top is configurability: pools can "use dynamic fees that adjust in real time through hooks," and Custom Accounting allows "custom curves, opting out of the concentrated liquidity curve in favor of an independent pricing mechanism."

Read that last clause precisely. A hook can substitute a pricing mechanism, which makes v4 capable of something that is not AMM pricing at all. The default is still the curve.

Choosing

CLOB for size you want to fill now in a liquid market. The price you name is the price you get, and the option not to fill is worth real money. This is where perps and majors live.

AMM for size you want to fill eventually in a thin one. It always quotes something. You pay the curve for it, and you can bound that cost with amountOutMinimum, but you will fill.

RFQ when you want a firm signed floor and accept that nobody is obliged to quote you. The floor is signed and gas is not at risk on failure, but the quote comes from a permissioned set of firms, and below their notional threshold there is no quote at all.

None of these is a ranking. They are answers to the same question with different counterparties.

Risk note: cryptocurrency trading, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely. AMM slippage, order-book queue risk, and RFQ non-quotation are execution risks that can occur independently of your price view, and a filled order is not a good fill. Nothing in this article is investment advice, a recommendation, or an offer to sell any product.