Cover photo

CLOB vs AMM: Why Dango Chose the Harder Path

The Default Choice and Why It Exists

Every DeFi protocol launched in the last five years has started with an AMM. Not because the AMM is the best trading mechanism for every use case, but because it is the most practical one for a chain where you have no control over block times, no protocol-level automation, and no guarantee that your contract will execute at the end of every block.

AMMs are the rational response to the EVM's constraints. You cannot run a real-time matching engine on a chain with 12-second block times and unpredictable gas costs. You cannot guarantee that orders will be matched at specific prices when MEV bots can reorder transactions in a mempool. The constant product formula, x times y equals k, is not elegant because it is mathematically beautiful. It is dominant because it works within the limits of the environment it was built for.

Dango chose not to build in that environment. It built its own chain with its own execution environment specifically so it could make a different choice: a fully on-chain Central Limit Order Book with periodic batch auctions. Understanding why that choice is significant requires understanding what is actually wrong with AMMs, what a CLOB offers, and what it takes to run one on-chain.


What AMMs Get Right and What They Get Fundamentally Wrong

The AMM innovation deserves genuine credit. Before Uniswap, on-chain trading on Ethereum was essentially unusable. Order books on EVM chains required gas fees for every order placement and cancellation, making market making economically irrational. The constant product formula solved this by eliminating the order book entirely: liquidity is deposited into a pool, prices are determined algorithmically, and trades execute against the pool rather than against other traders. No order management. No matching engine. No gas cost for passive liquidity.

This worked well enough that Uniswap became one of the most used protocols in crypto. But the same architecture that made AMMs viable on EVM creates three problems that are structural, not incidental.

Impermanent Loss is a Tax on Liquidity Providers

When a liquidity provider deposits tokens into an AMM pool, they receive a proportional share of the pool. If the price of one token changes relative to the other, the pool's constant product formula automatically rebalances. This rebalancing means that when a token's price rises, the pool sells some of it to maintain the formula. When prices fall, the pool buys more.

The result is that liquidity providers systematically end up holding more of the underperforming token and less of the outperforming one. This divergence between the value of the LP position and the value of simply holding the tokens is impermanent loss. It is called impermanent because if prices return to their original ratio the loss disappears, but in practice prices rarely return exactly, and LPs who exit after significant price movement often find their fees earned were more than offset by the structural loss.

Research published in 2022 found that more than 50% of Uniswap v3 LPs were losing money after accounting for impermanent loss. The concentrated liquidity mechanism in v3 improved capital efficiency but made impermanent loss more severe for LPs caught outside their range. Curve's stablecoin AMM reduced impermanent loss by focusing on assets that should trade at parity, but this trades off the flexibility to handle volatile asset pairs.

No version of the constant product formula eliminates impermanent loss. It is a mathematical consequence of how AMMs price assets. The only way to eliminate it is to not use an AMM.

Slippage Increases Nonlinearly with Trade Size

AMMs price assets based on the ratio of tokens in the pool. Every trade moves the ratio and therefore moves the price. The larger the trade relative to pool depth, the more the price moves per unit of asset traded. This slippage is not a quirk that better implementation can fix. It is the mechanism by which the AMM prices liquidity provision: if large trades were costless, there would be no incentive for LPs to provide deep liquidity.

For small retail trades, slippage on well-capitalized pools is negligible. For large traders, institutional users, or protocols routing significant volume, slippage becomes a meaningful cost. A $10 million swap on a $50 million Uniswap pool will move the price by approximately 16.7% before fees. No professional trading desk would accept that execution quality.

This is why most serious trading volume in DeFi does not happen on AMMs directly. It happens through aggregators that route across multiple pools, split orders, and find the path of least slippage resistance. The aggregator layer exists precisely because individual AMMs cannot handle large orders efficiently.

MEV Attacks Are Enabled by Design

The AMM's predictable pricing formula, combined with the EVM's public mempool, creates a systematic extraction mechanism for MEV bots. Because every AMM trade's price impact is calculable from the pool state, bots can observe pending transactions in the mempool and execute sandwich attacks: place a buy order before a large pending buy to push the price up, let the victim trade at the inflated price, then sell immediately after for a profit.

The victim pays more than they should. The MEV bot extracts the difference. The liquidity provider receives fees but also absorbs some of the adverse selection. Every participant in the AMM system except the MEV bot is made worse off by this dynamic.

MEV extraction on Ethereum alone has exceeded $1 billion in cumulative value since 2020. Various solutions have been proposed: private mempools, MEV auctions, intent-based trading. None of them eliminate the fundamental issue, which is that AMM pricing is deterministic and observable before execution.


What a CLOB Actually Provides

A Central Limit Order Book is how every major financial exchange in the world operates. The New York Stock Exchange, Nasdaq, Binance, Coinbase: all of them use CLOBs. The mechanism is straightforward: buyers submit bids at specific prices, sellers submit asks at specific prices, and the matching engine pairs overlapping orders on a price-time priority basis.

The key properties that make a CLOB preferable for serious trading:

Traders set their own prices. In an AMM, the price you receive is determined by the pool formula and the size of your trade. In a CLOB, you submit a limit order at the exact price you want. If the market moves to your price, you get it. If it does not, your order sits in the book. You have explicit price control, not statistical exposure to slippage.

Market makers earn the spread without impermanent loss. In an AMM, providing liquidity exposes you to the constant product formula's rebalancing. In a CLOB, a market maker places buy orders slightly below the market price and sell orders slightly above it, earning the spread on matched trades. There is no automatic rebalancing, no impermanent loss, and no algorithmic selling of appreciating assets.

Transparent price discovery. The order book shows you the full depth of supply and demand at every price level. You can see exactly where liquidity exists, how large orders are, and what the market believes the fair price is. This information is not available in an AMM, where you can only calculate the effective price from the pool ratio and your trade size.

Precise execution for large orders. A large limit order in a CLOB sits at a specific price until it is filled. It does not create slippage by moving through the price curve. It waits for matching supply or demand at the stated price. This is how institutional trading works in every other market.


Why On-Chain CLOBs Were Previously Impossible

If CLOBs are superior for trading, why did DeFi default to AMMs? Because building a CLOB on Ethereum or most other general-purpose chains is impractical.

A real-time CLOB requires the ability to place, cancel, and modify orders continuously at near-zero cost. On Ethereum, every state change costs gas. Placing an order costs gas. Cancelling it costs gas. Matching it costs gas. A market maker actively managing a book of hundreds of orders would spend more on gas fees than they could ever earn from spreads.

A CLOB also requires fast, predictable execution. Traders need to know their orders will be matched within a defined time window. Ethereum's 12-second block times and variable gas pricing make this impossible. An order submitted at a specific price might sit in the mempool for minutes, during which the market has moved and the order is now at a disadvantaged price.

Finally, a CLOB is vulnerable to MEV on chains with public mempools. Front-running order book trades is simpler than sandwich attacking AMM swaps: observe a large buy order in the mempool and insert a buy ahead of it. This problem does not exist on chains with instant finality and no mempool in the traditional sense.


How Dango Solves Each of These Problems

Dango's CLOB is built on its own sovereign chain specifically to address each limitation:

Batch Auctions Eliminate MEV

Rather than matching orders continuously and individually, Dango's CLOB processes orders in periodic batch auctions every 0.2 to 0.5 seconds. All orders submitted within a batch are collected, and the matching engine finds the single clearing price that maximizes the volume of trades executed.

This design eliminates front-running and sandwich attacks entirely. Since all orders in a batch execute at the same price, there is nothing to front-run. An MEV bot that observes orders in a batch cannot profit by inserting its own order to move the price ahead of them: all orders in the same batch clear at the same clearing price. The batch mechanism means that submitting an order slightly ahead of another does not give any price advantage.

Dango's on-chain CLOB with periodic batch auctions eliminates both slippage and MEV.

Protocol-Native Cronjobs Enable Real-Time Matching

Dango's Grug execution environment includes BeginBlock and EndBlock hooks. The order matching engine runs at the end of every block, automatically, without any external trigger. There are no bot networks, no off-chain relayers, no infrastructure that needs to stay online for the matching to work. The chain itself runs the matching engine as part of consensus.

This is only possible on a chain that was designed for it. On EVM, there is no mechanism for a contract to trigger its own execution at end of block. On Dango, this is a core feature of the execution environment.

Unified Margin Across All Products

Dango's CLOB is not just a spot order book. It is integrated with perpetuals trading and lending under a single unified margin account. A trader can use the same collateral to simultaneously hold a spot position, an open perp, and a lending position. When a spot order fills, the collateral accounting updates instantly across all positions.

This is impossible to build cleanly on EVM without coordinating state across multiple separate protocols, each with their own risk models and liquidation logic. On Dango, the unified margin account is a protocol-level primitive, not a complex integration built on top of independently deployed contracts.

Passive Vaults for Non-Traders

Recognizing that not every user wants to actively manage a CLOB order book, Dango also offers passive market-making vaults. Users who prefer the AMM experience of depositing and earning fees can do so through vaults that algorithmically place and manage CLOB orders on their behalf. The vault earns trading fees and shares them with depositors.

This gives retail users the simplicity of AMM liquidity provision while the underlying mechanism is still a CLOB. The slippage, impermanent loss, and MEV problems are handled at the protocol level rather than being passed to passive users.


The Honest Trade-offs

Dango's CLOB is significantly more complex to build and maintain than an AMM. Smart contract order books require careful gas optimization, complex matching logic, and robust handling of edge cases around partial fills, order expiry, and liquidations. The unified margin system adds substantial additional complexity around collateral accounting.

The CLOB also depends on market makers. AMMs work without any active participation beyond initial liquidity deposits. A CLOB with no market makers is just a list of unmatched orders with wide spreads. Dango needs to attract professional market makers to provide competitive two-sided liquidity, which requires both the tooling for them to operate efficiently and economic incentives sufficient to attract them over existing venues.

Dango's fully on-chain CLOB launched in Testnet 2 on July 28, 2025, inviting daily trades with a $1M daily trading volume goal and with trades settling via periodic auctions every 0.2 to 0.5 seconds.

The passive vaults partially address the market maker dependency by algorithmically providing liquidity, but a deep and efficient CLOB ultimately depends on professional participation.


Why This Matters for Dango's Thesis

Dango's core product claim is that it can deliver a trading experience comparable to a centralized exchange while remaining fully on-chain. That claim is impossible to fulfill with an AMM. Centralized exchanges use CLOBs. Professional traders use CLOBs. Price discovery happens on CLOBs.

The AMM was DeFi's workaround for the EVM's limitations. Dango removed those limitations by building its own chain. Having done so, defaulting to an AMM would be the equivalent of building a custom racetrack and then running a bus on it.

The CLOB is not the harder choice for Dango. Given what they built, it is the only choice that makes the rest of their product thesis coherent.

post image

Part 4 of a research series on Dango's technical architecture. Part 1 covered Hyperlane vs LayerZero, Wormhole, and Axelar. Part 2 covered ERC-4337 vs Dango Smart Accounts. Part 3 covered Grug vs EVM vs SVM. Part 5 will cover why modular stacks still leak sovereignty.