DEX development with an order book: where the architecture breaks
An on-chain order book is not about moving exchange matching into smart contracts. Limit orders, price-time priority, partial fills, and cancellation must be reproducible where transaction ordering is set by a validator, not by an exchange engine.
The first source of failures is state desynchronization. While a transaction is stuck in the queue for inclusion, the price has already moved, and two opposing orders in the same block see different order trees.
A contract that matches against an outdated snapshot closes a trade at a price that no longer exists on the market.
The second class is stuck orders. If a cancellation does not fit into a block, liquidity formally remains in the order book, although the owner can no longer manage it.
DEX development here requires forced removal mechanics and an explicit order lifecycle, otherwise phantom volumes accumulate in the order book and market depth calculation deteriorates.
The third problem is unpredictable execution cost. The network fee changes between signing and inclusion, and the taker gets a price different from what was shown on screen.
DEX architecture must limit slippage and reject execution that goes beyond specified bounds, rather than force the trade through at any cost.
All three failures are not implementation bugs, but a consequence of the trade-off between settlement transparency and response speed. Below we break down how this is addressed at the DEX architecture level.
What an on-chain order book provides: speed, liquidity, failures
An on-chain order book is a dedicated order book where limit orders from buyers and sellers meet. Order matching happens off-chain, while the settlement result is recorded on-chain: the network stores the trade result, not every quote change.
Trade execution time is determined not by waiting for the next block, but by the moment orders match — an opposing limit order is filled immediately. This removes the main delay: there is no need to wait for the pool state to change for the price to become acceptable.
Liquidity depth is gathered in one place: liquidity providers keep quotes in a shared order book, not in fragmented pools. The spread narrows, and slippage on large volume is visible in advance — from the order book, not after execution.
Fault tolerance here is a consequence of predictability. A whole class of failures disappears: there is no price jump between check and trade, no race for pool state, and partial execution replaces complete order failure.
The share of failed operations drops: an order either executes or remains in the order book, and the order book snapshot is restored after a node failure.
We move settlement to Ethereum, where the final state is verifiable by any participant, not just the exchange operator. This also keeps the effects measurable: time to settlement, spread, and failure rate are visible in logs and order book statistics, not just claimed.
Exchange formats: order book, liquidity pool, hybrid
The trading format determines everything else: where liquidity physically resides, who bears the non-execution risk, and how the trade price is calculated. This choice determines the contracts, settlement requirements, and whether limit order execution can be predictable at all.
The three exchange formats differ not by "better or worse," but by the type of market they are designed for. Below are the limitations of each, and they appear under load, not in a test environment.
| Option | When it fits | Limitations |
|---|---|---|
| Order book | Frequent trades on stable pairs, need exact limit order execution price | The book needs to be filled with something: without an incentive for market makers, slippage grows |
| Liquidity pool | Launch with few participants, long tail of pairs | Price depends on pool size, a limit order does not guarantee execution, and there is impermanent loss risk |
| Hybrid model | Need order book precision, but few own market makers so far | More complex contracts: two price sources, priority rules, and arbitrage between them |
In practice, the hybrid model provides the best start: the liquidity pool covers pairs that market makers do not enter, while the order book handles large instruments.
The price for this is more complex contracts — the priority order between price sources is described before development begins, otherwise trade settlement diverges between participants.
DEX development: stages from task analysis to code handover
The engineering sequence for an order book differs from a simple token swap: part of the logic lives off-chain, and trade settlement must either complete fully or not happen at all.
Therefore, scenario analysis and contract review are not a formality, but what keeps the project from rewriting the core after launch.
- Trading scenario analysis. We fix order types, partial execution rules, cancellation and queue priority, behavior under insufficient liquidity, and price divergence between the book and the chain.
- Schema design. We determine what goes on-chain and what stays in order matching, how the book state is stored, who signs what during settlement, and how deposits and withdrawals are structured.
- Contract implementation. We write modules for trade settlement, holding funds until execution, fees, and access rights; we separate upgradeable parts from immutable ones so upgrades do not affect user balances.
- Contract review. Unit and end-to-end tests, separate suites for partial execution, cancellation, repeated calls, and fee calculation; role-based access rights review.
- Testnet verification. Full cycle of deposits, trading, settlement, and withdrawals. We look at behavior during failures and when returning funds from a canceled order.
- Load runs. We assess how the book handles the order flow, where response latency grows, and how much state goes on-chain per unit of time.
- Code handover. Repository, deployed environments, schemas, contract descriptions and upgrade procedures, list of known limitations, and a roadmap.
Describe which trading scenarios you need specifically — we will return with an estimate of timelines and the scope of work by stage.
Contracts, flow diagrams, and release procedures
After DEX development is completed, your team is left not with a "black box," but with a set of artifacts by which the system can be developed and maintained without us.
Everything goes into your repository and internal documents — with notes on where changes can be made independently and where mandatory review is required.
- Smart contract source code with an analysis of parameters set during deployment: fees, limits, list of traded pairs — so changing conditions does not require rewriting the logic.
- Flow diagrams for each scenario: order placement, cancellation, matching opposing orders, settlement, and withdrawal — from user signature to final trade settlement.
- Access policies and role map: who can change parameters, who manages the treasury, which operations require multiple signatures, and what to do if a key is lost.
- Upgrade procedure: approval process, set of checks before release, rollback window to the previous version, and the person responsible for each step.
- Audit report with a list of findings and priorities: some are closed before release, some remain as controlled debt with clear timelines.
- Monitoring instructions: which contract events and order book metrics signal a problem before users notice it.
- Tests and deployment scripts — re-releasing and verifying changes takes minutes, not days of manual work.
Case study: order book under peak load and what changed
The client is an exchange team with a hybrid model: matching in an off-chain order book, settlement in smart contracts on an Ethereum-compatible network.
During the listing of a popular pair and at moments of sharp market moves, the book could not keep up: the matching queue lagged behind the order flow, balance debits diverged from the book state, and at peak up to 14% of orders were rejected due to waiting time. The client's engineers closed discrepancies manually — several times a week.
What we did
Matching was moved to a separate service with a queue and batch processing: orders are grouped, and one settlement per group goes on-chain instead of a separate transaction for each trade.
Contracts were rewritten for minimal storage operations: fields were packed into shared slots, trade history was replaced with events, fees were calculated outside the matching loop, and reprocessing was protected by a key that cuts off duplicates. Order book cache and periodic snapshots eliminated full book recalculation on every update.
What became
The share of rejected orders at peak went from 14% to 0.3%, trade confirmation time decreased from 6-8 seconds to 1-2 at the 99th percentile. Manual interventions in exchange operations: there were 3-4 per week, and in the quarter after launch — none.
Peak throughput tripled on the same server fleet, and the divergence between balances and the book no longer reproduced in load runs.
Additionally, we added a shadow mode: the new contract computes in parallel with the live one, and divergence is visible before switching. Plus alerts on order book depth and queue lag — the bottleneck is now noticeable within minutes, not after trader complaints.
How an order book differs from a liquidity pool
An order book builds price from limit orders: makers place orders, takers take them, and the matching engine matches opposing volumes by price-time priority.
A Uniswap liquidity pool works differently — price is determined by a formula from the reserve ratio, and a trade executes against the entire pool, not against a specific counterparty.
Slippage in the book depends on order book depth at the chosen price: in a calm market, a large order goes through with almost no loss; on a thin pair, it tears through several levels.
In a pool, slippage grows nonlinearly with trade size relative to reserves, and the liquidity provider additionally bears impermanent loss risk when the price moves.
Requirements for liquidity providers also differ. The book needs professional market makers, reward programs, and spread control — otherwise the order book empties and the spread widens.
A pool needs only passive providers: the contract maintains the quote itself, but it fundamentally cannot handle limit orders, stop-losses, or leverage without a separate logic layer.
Maintenance complexity shifts differently. The book is order matching, a risk engine, cancellations, partial fills, audit, and fault tolerance; the pool is a compact and predictable set of contracts that is easier to review and upgrade.
Therefore, in practice, a hybrid is increasingly chosen: the book provides price precision and control, the pool provides fast launch and liquidity from day one.
Technical questions: network fees, delays, upgrades
Network fees and confirmation delay determine whether trading on a DEX feels like exchange trading. During peak hours, the cost of an operation grows multiple times, and the transaction hangs in the pending queue when the price has already moved.
For an order book, this is critical: the user gets slippage where they expected execution at their price.
We separate matching and settlement: order reconciliation happens off-chain, and only the final settlement by batches of trades goes to the blockchain.
One operation closes dozens of matches — the fee per trade drops, and order cancellation does not require an on-chain record at all. Below are answers to questions asked before starting.
How is the network fee controlled at peak?
Before sending settlement, we estimate the current cost of the operation and maintain an upper bound: if it is more expensive, the transaction will not go through. If it does not pass the bound, settlement moves to the next batch, and the order remains active.
Will the order book be able to react without delays?
Matching happens in memory, and response to a signed order is fractions of a second. An order executes at the price specified in it or does not execute at all: partial matching does not pull the trade at market, so slippage occurs only where the user themselves set it.
How are contracts upgraded and what about their security?
We separate logic and storage: state remains in place, only the settlement module changes, and the upgrade goes through a delay and confirmation with multiple keys.
Before deployment — invariant tests, a run on a network copy with real transaction history, and an independent audit. Rollback is done by swapping the module back, without balance migration.
Let's discuss the task: we'll review the architecture and come back with an estimate and plan
You can discuss a DEX development task without a finished specification — just describe what already exists and where we are heading.
The more specific the inputs, the more accurate the architecture review: we do not guess the execution model and custody, but calculate based on your conditions.
- Pairs and order types: limit, market, stop, closing auction — the order book structure depends on this.
- Order matching model: fully on-chain, off-chain with a settlement layer, or hybrid.
- Custody: who holds funds, how deposits and withdrawals are structured, whether there is a settlement counterparty.
- Networks and assets: where we deploy, whether a bridge is needed, whether token listing is planned.
- What is already done: contract drafts, repository, data schemas, code review reports.
- Constraints: order privacy, access requirements, external integrations.
In the first conversation, we review the order and settlement flow, contentious points, and risk classes — order book manipulation, front-running, settlement layer failure.
Then we come back with a work plan: module composition, stage order, what we close in the first iteration, and which checks are delivered together with the code.
Project estimation relies on contract volume, order matching complexity, and fault-tolerance requirements — without "we'll clarify later" assumptions.
Describe the task in a convenient format — we will come back with an estimate and plan.