Follow how an AMM, an order book and an aggregator each assemble a trade. Identify where orders, prices and settlement live before assuming two DEXs behave alike.
Three mechanisms, several separate responsibilities
A decentralized exchange can use a pool, an order book or a combination of mechanisms. An aggregator helps find and execute a route through liquidity sources. These categories are not mutually exclusive. A product may show an order-like interface while routing to pools, and an aggregator may include quotes from professional market makers.
To understand a venue, separate custody, order distribution, matching, settlement and the website used to submit a trade. Moving one component onchain does not establish that every component is decentralized or always available.
AMMs: trade against a pool
In a pool-based AMM, a contract calculates an exchange using its balances and pricing rules. Uniswap v2 provides a constant-product example. A trader does not have to wait for another person to place the opposite order at that moment, but execution still needs usable liquidity and a valid transaction.
A large swap can move the pool's price substantially. Its quote should include the effect of the trade size, with fees identified separately. Liquidity providers bear changing asset exposure and contract risk; fees are potential revenue, not a fixed yield. For the arithmetic, see the worked AMM example.
Order books: where orders live matters
An order book collects bids and offers. A limit order specifies a price constraint; it does not guarantee a fill. Orders may be maintained by an operator, distributed among nodes, committed to chain state, or handled differently according to their lifetime. Matching and final settlement can happen at different stages.
The current dYdX Chain documentation describes an in-memory order book at each full node. Block proposers use their local book to construct matches, and nodes reconcile with committed blocks. Local views can differ before consensus.
Its order documentation further distinguishes short-term orders held in validator memory from stateful orders recorded onchain. Describing v4 as a transition to a system where every order is written onchain was inaccurate. Neither “offchain” nor “onchain” alone tells a reader who can censor orders, how cancellation works or when a fill is final.
The old table also listed Serum as an offchain example without a dated architecture source. That example has been removed. It is not being certified as a current operating venue. Performance depends on the actual chain and implementation; the earlier blanket claim that onchain order books are necessarily impractical has also been withdrawn.
Aggregators: optimize within available sources
An aggregator compares routes and can split an order. 0x's Swap API documentation describes access to public and private liquidity, including request-for-quote sources. Aggregation therefore should not be defined as searching only public AMM pools.
A route is conditional on the sources supported, the chain, trade size, quote time, costs and execution constraints. It cannot establish the best possible result across every market. A higher displayed output may become a worse net result after gas or other fees. A quote can also expire or fail before settlement.
A practical comparison exercise
Imagine two hypothetical routes for the same trade: one quotes 1,000 units with 8 units of separately charged costs, while another quotes 998 with 3 in costs. On those assumptions the net amounts are 992 and 995. If a displayed quote already includes a fee, subtracting it again would be an error. Compare like-for-like units, timing and cost conventions.
For each venue, record who holds the assets, who can change the contracts, how orders expire or cancel, how settlement is verified and what happens during an outage. Token approvals, bridges, admin controls and oracle dependencies may matter as much as the matching mechanism. This is a framework for understanding a system, not a recommendation to trade on a named platform.
Optional calculation lab: Compare Uniswap v2 and Curve StableSwap with the same model inputs. Follow both calculations and see how transaction costs can reverse the result.
Revision history and scope
Reviewed 19 October 2026. Updated the dYdX description and removed universal best-price, availability and decentralization claims.
24 October 2026: Moved the earlier correction note below the lesson and added a reader-focused introduction. This is a presentation edit; the earlier factual review date is unchanged.