Limit orders play a crucial role in trading. However, DEX limit orders still suffer from major drawbacks — namely reliance on centralized, off-chain components, and in the case of fully onchain solutions, poor user experience.
This post gives a high-level overview of current DEX limit order mechanisms, their tradeoffs, and Carbon’s solution for limit orders that are:
fully onchain
irreversible on execution
protected from MEV sandwich attacks
Let’s first explore the two types of DEX limit order mechanisms that have existed until now: Off-Chain Orders and Concentrated Liquidity AMMs (CLAMMs).
Off-Chain Orders
These orders settle onchain but maintain users’ orders off-chain and execute them in one of two ways:
Off-chain order matching
Off-chain triggers that perform a market order (spot trade) when the desired price is reached
Such approaches have key drawbacks, including:
Orders are aggregated in off-chain nodes and permissioned mempools, making them opaque and prone to manipulation and high rent extraction by centralized order discovery services (hello TradFi).
When you submit these orders, you’re offering to take liquidity off the books (as a taker), rather than creating liquidity (as a maker). Traditional CeFi limit orders have evolved as maker orders for a reason: they add to the exchange’s liquidity, instead of squeezing it. The saturation of taker limit orders in DeFi has often led to unreliable order execution, since unlike CEXs, everyone is fighting over the same liquidity.
The limitations of existing limit order implementations highlight the need for more efficient and reliable solutions for decentralized limit orders to improve user experience and increase adoption.
CLAMMs to the Rescue (Sort of)
Uniswap V3 and other CLAMMs can currently be used to mimic limit orders by placing single-sided liquidity in the desired range. But you must withdraw your liquidity before the price retraces — otherwise your tokens get swapped back and your order gets reversed.
The self-reversing nature of CLAMM “limit orders” arises from the fact that within every AMM, the same pricing curve (or “bonding curve”) is used to execute both buys and sells. Once a buy order for one asset is traded against, a sell order for the other asset is placed at the same price. Order reversal makes automated trading hard, and also exposes spot traders to MEV sandwich attacks.
The implementation of “hooks” in Uniswap 4 seeks to automate liquidity withdrawal and mitigate MEV, however via external contracts that add complexity, attack surface and costs for both makers and takers.
Carbon’s Native OnChain Limit Orders
Carbon introduces a new form of unidirectional DEX liquidity where limit orders are both fully onchain and irreversible on execution. This functionality is offered natively by the protocol — with no reliance on off-chain components/triggers, and no need for external tooling like oracles or hooks.
The core innovation underlying Carbon is the use of two bonding curves for each liquidity position, instead of one. Once your limit order buys or sells at your desired price, your liquidity is automatically moved to its paired curve, where it sits inactive (unless told otherwise, but that’s for another post). This removes the need for users to constantly monitor their orders and manually withdraw in time, or rely on a third-party to do so.
Each liquidity position in Carbon has a buy curve and a sell curve, enabling irreversible onchain limit orders.
Carbon’s novel dual-curve design unlocks an array of benefits for users by enabling limit orders that are:
Fully onchain: trading is transparent throughout the lifecycle of an order, with no dependencies on centralized off-chain components.
Irreversible: orders are final upon execution, eliminating the need to withdraw quickly before the order is reversed.
MEV protected: spot trades on Carbon limit orders are protected against MEV sandwich attacks.
Maker liquidity: orders increase market liquidity, rather than squeezing it, improving execution quality and reliability.
Zero trading fees: makers pay zero trading fees on executed orders (takers pay).
Adjustable: order conditions can be updated without deleting and recreating the order.
Partially fillable: orders can be partially filled without requiring that the market price cross an order’s entire range.
Single limit orders in Carbon can be achieved by selecting a “Disposable” strategy in the CarbonDeFi.xyz app. “Recurring” strategies, on the other hand, allow users to combine limit orders into a “buy low, sell high” strategy that executes repeatedly.
Conclusion
Current DEX limit order solutions — which rely on off-chain systems and concentrated AMM liquidity — have several drawbacks, including opaque, permissioned data and self-reversing orders. In contrast, Carbon’s unidirectional liquidity model combines fully onchain mechanics with irreversible execution, giving users greater control and protection from MEV, while preserving the permissionless nature of blockchains.
