Market Orders, Limit Orders and Routing
Now that you understand how AMM pools set prices, it's worth knowing what kinds of trade "orders" DeFi actually supports, because the vocabulary carries over from traditional finance but the mechanics underneath are different. The default and most common order type in DeFi is a market swap: you specify what you're trading from and to, the interface quotes you the current price from the relevant pool, and if you accept, the trade executes immediately at (approximately) that price, subject to the slippage covered in the next two lessons. There is no waiting for a match — the pool is always there, ready to trade against, as long as it has sufficient depth.
Limit orders — where you specify a price you're willing to accept and the order only executes if the market reaches that price — are less universal in DeFi than in traditional exchanges, because pure AMM pools don't have a native concept of a resting order. Some DEXs and dedicated protocols layer limit-order functionality on top of AMMs or use separate order-book-style mechanisms to offer this feature, but it's not guaranteed to be available everywhere the way it is on a centralized exchange.
A third and increasingly important concept is routing through an aggregator. Because liquidity for any given token pair is often spread across many different pools — sometimes on different DEXs entirely — a single pool may not have enough depth to fill your trade at a good price without significant slippage. Aggregators (such as 1inch, or routing features built directly into many wallets) scan multiple pools and split your trade across them, filling part of your order from each pool in the combination that produces the best overall price, something a direct swap on a single DEX cannot do.
Worked Example
Suppose you want to swap $50,000 worth of a mid-cap token for USDC. If the largest single pool for that token only holds $200,000 in total liquidity, swapping the full $50,000 directly into that one pool would represent a quarter of its total depth — moving the price substantially and producing significant slippage, potentially costing you several percent compared to the pre-trade price. An aggregator, however, might find that the same token also has smaller pools of $80,000 and $60,000 on two other DEXs. By splitting your $50,000 trade proportionally across all three pools — rather than dumping it all into the single largest one — the aggregator can produce a meaningfully better blended price, because each individual pool only absorbs a smaller fraction of your total trade, and each therefore moves its own price ratio less.
This is a direct, practical consequence of the AMM mechanics from the previous lesson: since the price impact of a trade scales with trade size relative to pool depth, splitting a large trade across multiple pools of adequate combined depth is almost always better than concentrating it in one, as long as the aggregator's own routing and gas costs don't outweigh the savings — which for very small trades, they sometimes do.
There's one more wrinkle worth understanding before you rely on an aggregator by default: routing isn't free. Splitting a trade across three pools instead of one typically means three separate on-chain interactions bundled into a single transaction, which usually costs more gas than a single-pool swap would. For a large trade where the price-impact savings are substantial, this extra gas cost is trivial by comparison. But for a small trade — say, $50 — the gas overhead of a complex multi-pool route can actually exceed the small price improvement it buys you, which is why many aggregators automatically fall back to simpler, single-pool routes below a certain trade size, and why checking the final quoted amount (which already nets out estimated gas) rather than the "best price" label alone is the safer habit.
Common Pitfalls
- Assuming an aggregator is always cheaper. For small trades, gas overhead from multi-pool routing can erase the price-impact savings — always compare the final net amount, not just the advertised route.
- Confusing a "limit order" feature on a DEX aggregator with a true resting order on a traditional exchange. Some DeFi limit-order implementations rely on off-chain relayers or keeper networks to execute once a price is hit, introducing execution risk that doesn't exist with an AMM market swap.
- Ignoring which specific pools a route touches. An aggregator might route part of your trade through a pool with a token you don't fully trust (for a multi-hop route); review the full route, not just the summary price.
Exercise
Using live DEX and aggregator interfaces (or cached examples if live access is unavailable), compare the quoted output for swapping the same token pair and the same trade amount on a single DEX directly versus through an aggregator that routes across multiple pools. Record both quoted amounts.
Calculate the percentage difference between the two outcomes, and write one sentence explaining, in your own words, why routing across multiple pools produced a better (or in some cases, equal) price — tying your explanation back to the relationship between trade size, pool depth, and price impact from the previous lesson. Note at what trade size you'd expect the aggregator's advantage to shrink or disappear (hint: very small trades relative to any single pool's depth rarely show much difference).
Recap
- Market swaps execute immediately against an AMM pool's current price; true limit orders are less universal in DeFi and depend on protocol-specific features.
- Aggregators split a single trade across multiple pools to reduce price impact, directly exploiting the trade-size-versus-depth relationship from AMM mechanics.
- The aggregator advantage grows with trade size relative to any single pool's depth, and shrinks toward zero for small trades.