TL;DR
Traditional AMMs aggregate liquidity into shared pools, where a common curve determines how, and at what price, every position buys and sells.
Traditional orderbooks give makers more control, but usually express liquidity through separate fixed-price orders and may rely on offchain matching or execution systems.
Carbon DeFi introduces a different model: an onchain orderbook-style DEX where makers publish executable curves instead of being limited to fixed-price orders.
Each maker defines their own prices, ranges, budgets, and spread. Buy and sell liquidity can operate independently or be linked into a recurring strategy.
This architecture supports native Limit Orders, Range Orders, Recurring Orders, Concentrated Liquidity, Full Range Liquidity, and spot trading from the same protocol.
Carbon DeFi orders are adjustable onchain. Limit, Range, and Recurring Orders are irreversible on execution and provide makers with price certainty and MEV sandwich attack immunity.
A built-in solver system helps orders get discovered and filled using liquidity from major DEXs across the chain.
Automated market makers changed what an exchange could be.
Instead of waiting for professional market makers to maintain an orderbook, a project could create an onchain pool, deposit two tokens, and make a market available to anyone. Pricing, execution, and settlement could all happen through smart contracts.
That model became so dominant that the AMM is often treated as the natural shape of a decentralized exchange. In reality, it’s only one way to organize onchain liquidity, with strengths and constraints that follow directly from its architecture, including slippage (price uncertainty) and MEV sandwich attacks.
Traditional orderbooks offer another model. Makers publish bids and asks that specify how much they are willing to buy or sell and at what price. Each order represents one price level in the orderbook.
An AMM is a very specific subsect of an order book that relies on explicit instructions to maintain itself. — Dr. Mark Richardson, Bancor Project Lead
Many DEX products described as “limit orders” work differently. The user communicates the price they want, but also defines the minimum amount they are willing to receive if the trade executes. The requested price and the minimum acceptable result are therefore not necessarily the same.
In practice, the order behaves more like an offer or execution instruction. An external solver, or a taker in general, attempts to execute it within the user’s acceptable boundaries. Settlement may happen onchain, but the user is not necessarily publishing native maker liquidity that guarantees execution at one exact quoted price.
Carbon DeFi takes a different approach. A Carbon Limit Order is an executable onchain offer at the maker’s exact price. Full and partial fills execute at that price, providing the maker with 100% price certainty and 100% of that amount. The price they set is the amount they receive when the order is filled.
From ‘Market Makers– The Most Misunderstood Role in Crypto?’
Carbon DeFi also allows the maker to publish an executable pricing curve across a range. If a maker is placing three separate orders to sell 100 tokens at $1.00, 100 at $1.05, and 100 at $1.10, then those orders create three distinct price levels.
A Carbon Range Order can instead offer 300 tokens progressively between $1.00 and $1.10. The curve defines the precise amount available at every price throughout that range. As the market moves through it, Carbon DeFi’s built-in solver system helps fill the order progressively against the maker’s predefined pricing.
“Executable pricing curve” therefore means a standing onchain order containing the complete pricing instructions for the maker’s liquidity. It can define one exact price or every price across a continuous range, and trades execute directly according to those instructions.
How an AMM Organizes Liquidity
In a conventional AMM, liquidity providers deposit tokens into a shared pool. A mathematical invariant determines the prices available to traders as the pool’s balances change. In other words, the execution price changes at the time a trade is made.
In a constant-product AMM, every liquidity provider accepts the same pool-level pricing function. Concentrated liquidity gives each provider more control over where their capital is active, but the position still participates in a shared AMM architecture. Its buy and sell behavior remains coupled through the same underlying curve.
This creates a very specific form of liquidity:
Pricing is derived from the state of the pool.
A trade changes the pool’s token balances and therefore its next available price.
A position that sells one token as the market rises becomes available to buy it back if the market retraces.
Liquidity providers select from the parameters supported by that AMM, including its tick structure and available fee tiers.
Traders execute against the depth available within that pool and the routes an aggregator can assemble from other pools.
None of this makes AMMs inherently deficient. They remain an effective way to create passive, continuously available markets. But the model standardizes liquidity around the pool. It does not begin with the individual maker, or taker’s intent.
How an Orderbook Organizes Liquidity
An orderbook begins with makers.
Each maker publishes a standing offer to buy or sell an asset at a defined price. Those offers collectively form the market. A taker accepts the available liquidity when their desired price and quantity align with an existing order.
This gives makers direct control over their quoted prices, but conventional orderbooks usually express that control through discrete orders:
Buy 100 tokens at $1.00
Buy 100 tokens at $0.95
Buy 100 tokens at $0.90
If a maker wants to quote continuously across a range, they need to maintain many separate orders.
Onchain orderbooks face another constraint. Publishing, updating, matching, and clearing large numbers of individual orders directly on a blockchain can consume substantial blockspace. Some DEXs therefore keep settlement onchain while moving parts of order discovery, storage, matching, or triggering to external systems.
The result is usually a tradeoff: the standardized liquidity of an AMM or the discrete pricing of an orderbook, often with third-party dependent infrastructure around both creation and execution.
Carbon DeFi: An Orderbook of Executable Curves
Each token balance in a Carbon strategy has its own implicit pricing curve. Rather than placing both tokens on one shared invariant curve, Carbon DeFi separates them.
Every strategy contains two connected orders:
One order can sell Token A for Token B.
The other can sell Token B for Token A.
Each order specifies:
The token available for sale
The maker’s budget
An exact price or custom price range
The direction in which the liquidity can execute
The maker can activate one order, both orders, or configure the relationship between them.
This is why “orderbook-style DEX” is more accurate than simply calling Carbon DeFi another AMM. Makers publish standing offers, but those offers can be curves. One curve can express an entire continuum of prices without requiring the maker to post a separate fixed order at every level.
What an Executable Curve Allows a Maker to Define
The curve can be narrowed to one price, extended across a range, linked to another curve, or configured to reproduce familiar liquidity positions.
Limit Orders: One Price, One Direction
A Limit Order is the simplest expression.
A maker defines:
The token they are willing to sell
The token they want to receive
The exact exchange rate
The available budget
The order remains onchain until it is filled, adjusted, paused, or withdrawn by the maker. Full and partial fills execute at the maker’s quoted price.
Once the order buys or sells, the acquired tokens do not automatically become available in the opposite direction. The completed portion cannot be reversed by a subsequent market retracement.
This differs from using a concentrated-liquidity position to approximate a limit order. In a conventional AMM position, the same liquidity becomes available for the reciprocal trade if the market moves back through its range.
Range Orders: A Continuous Offer Across a Custom Zone
A Range Order distributes the maker’s liquidity between two prices.
Instead of creating several separate orders such as:
Buy at $1.25
Buy at $1.20
Buy at $1.15
Buy at $1.10
Buy at $1.05
the maker can publish one curve that buys progressively from $1.25 down to $1.05.
The curve determines how much liquidity is available at every point in the range. Execution can occur partially as the market moves through it, while every completed fill remains filled.
Range Orders give makers a native way to scale into or out of a position without relying on a bot to maintain a ladder of individual orders.
Recurring Orders: Separate Buy and Sell Logic
Recurring Orders connect one buy order and one sell order into a continuous strategy.
A maker may choose to:
Buy within one price range
Sell within a separate, higher price range
Define the spread between them
Initially fund one order or both
When the buy order fills, the tokens acquired automatically become available in the sell order. When the sell order fills, the proceeds rotate back to the buy order. Partial fills rotate proportionally, allowing both sides to remain active at the same time.
The cycle can continue for as long as the maker leaves the strategy active and the token pair continues trading within the maker’s predefined parameters.
This is not an AMM position repeatedly buying and selling around one shared curve. The maker defines two distinct expressions of intent. The buy and sell sides can use different prices, different ranges, and an arbitrary spread.
Concentrated Liquidity: A Familiar Strategy With Individual Parameters
Carbon can also configure the two curves to behave like a concentrated-liquidity position.
The maker defines:
The active price range
The position’s budget
The spread, functioning as the maker’s fee
Unlike an AMM that places liquidity providers into preset fee tiers, Carbon DeFi allows the spread to be defined at the position level. Trading fees and proceeds are added natively to the strategy balances, creating auto-compounding without a separate vault or automation service.
This preserves the familiar objective of concentrated liquidity, providing two-sided liquidity within a selected range, while giving each maker independent control over the position’s pricing.
Full Range Liquidity and Spot Trading
Not every market or participant needs an advanced strategy.
Makers can deploy Full Range Liquidity across the complete price curve, while traders can perform ordinary spot swaps against the liquidity available through Carbon DeFi.
The protocol therefore supports both familiar AMM-style participation and more directional, order-driven strategies. These are configurations of maker-defined curves, not separate products built around, or on top of unrelated execution systems.
One Architecture, Several Different Forms of Intent
What the underlying architecture allows a maker to express:
All are produced from the same underlying idea: each maker publishes their own executable pricing instructions.
What Changes for Execution
Separating maker liquidity into independent curves produces several practical results.
Makers receive price certainty
For Carbon DeFi Limit, Range, and Recurring Orders, the maker defines the exchange rates in advance, with full price certainty. A fill executes according to the curve the maker published, rather than applying a user-selected slippage tolerance to a market order.
The maker may receive a full fill, a partial fill, or no fill if the market never reaches an executable price. Price certainty does not guarantee that an order will execute. It guarantees the terms when it does.
Completed orders do not reverse
Limit and Range Orders are unidirectional. Once liquidity executes, the acquired tokens are not automatically offered back to the market.
This allows a maker to buy or sell progressively, accumulating or distributing without racing to withdraw after execution.
Orders remain adjustable onchain
Makers can edit prices, ranges, order types, and other order parameters without deleting the strategy and rebuilding it from the beginning. This also includes adding or removing funds, pausing the strategy, or reactivating it.
Immunity to MEV sandwich attacks
Carbon’s asymmetric, unidirectional liquidity removes the AMM behavior that makes a conventional sandwich profitable. A taker trading against a Carbon DeFi order receives the amount quoted by the maker, with zero slippage and no opportunity for an attacker to manipulate the order’s price around the transaction.
The relevant distinction is the actor:
Makers receive execution at the prices encoded in their curves.
Takers receive the quoted amount when trading against those curves.
For more on sandwich attacks, see:
Understanding MEV Sandwich Attacks- Frequently Asked Questions
The Forbidden Sandwich: A Theory of MEV-resistant CFMM Transactions
Order execution does not require external triggers
Carbon orders exist and execute onchain. Their prices do not depend on an oracle, and a keeper does not need to monitor the market and submit a market order when a target is reached.
This removes external services from the order’s basic execution path. Interfaces, indexers, arbitrageurs, solvers and other infrastructure may still help users discover and interact with the protocol, but the order itself remains an executable onchain offer.
The Role of Carbon’s Built-In Solver System
Publishing a maker order is only one side of an active market. That liquidity must also be discovered and traded against.
Carbon DeFi is integrated with Bancor’s solver system, an arbitrage and routing framework that searches for price discrepancies between Carbon curves and other DEX liquidity across the chain. When a Carbon order becomes executable relative to an external market, the solver can route a transaction that trades against the maker’s curve and available liquidity elsewhere.
This gives Carbon DeFi orders reach beyond the capital deposited on Carbon itself. They can be discovered and filled using liquidity from all major DEXs chainwide.
The solver does not change the maker’s price or guarantee that every order will fill. It works within the maker’s published conditions. If an executable opportunity exists after gas and other transaction costs, the framework can identify and submit it.
Bancor’s research on Marginal Price Optimization reduces high-dimensional arbitrage and routing problems to a lower-dimensional root-finding problem. The published framework reports improvements of up to 200 times over the referenced convex-optimization solver, particularly for complex or levered curves.
For Carbon DeFi, the practical result is coordination: individual maker curves can remain independently defined while the solver works to connect them with prices and liquidity elsewhere on the chain.
AMMs Are Still Useful But They Are No Longer the Only Serious DEX Model.
AMMs solved an essential early DeFi problem. They made permissionless markets practical when maintaining a conventional orderbook onchain was expensive and difficult.
Their success turned one architecture into the default architecture. The pool decides the curve, liquidity providers accept the pool’s rules, and traders receive the execution that the available depth can support.
Carbon DeFi follows its own set of rules.
The maker decides the price, range, budget, direction, and relationship between the buy and sell sides. The protocol turns those decisions into executable curves. The solver then works to connect that liquidity with the wider market.
Carbon DeFi isn’t categorized an AMM, nor is it a conventional orderbook moved onto a blockchain. It is an onchain orderbook-style DEX built from the ground up with programmable curves.
This allows Carbon DeFi to support passive liquidity, exact-price orders, range-based execution, recurring trading cycles, custom spreads, and permissionless market creation without forcing every participant into the same pool-level strategy.
