Developing batch auctions: where the retail flow breaks
Continuous execution seems simple: an order arrives, lands in the nearest block, the trade closes.
Everything breaks in the interval between submission and inclusion in a block — the order becomes visible before it is executed, and someone who buys priority in the queue overtakes it. The retail order arrives at an already shifted price.
Slippage on retail volume hurts the most. The order itself barely moves the price, but a queue of front-running trades builds around it, and execution ends up 1–3% worse than the quote the client saw on screen.
With a hard limit, the trade is rolled back entirely: the fee for the failed attempt is already spent, and the user resubmits the order.
Repeated failed executions become a constant background. During volatile hours, the failure rate reaches a third of retail flow, and each new attempt again enters the same race for transaction ordering — block after block, with no exit from the cycle.
The root of all three failures is the same: the flow has no single moment in which all orders are matched at one price. We break down how this is closed by batch order execution — and what exactly changes in batch auction development.
What batch execution delivers: the effect in protocol metrics
Batch settlement changes not the speed of an individual trade, but how orders meet each other. Instead of execution as they arrive, each cycle collects orders over a fixed interval, and the price is determined by the overall intersection of supply and demand.
Hence the first consequence: losses from order ordering within a batch are zero — all participants get one price, and queue priority ceases to be a subject of bargaining.
The first measurable effect is the share of successful executions. Orders that under one-by-one processing would remain without a counterparty are closed in a batch by offsetting: a buy and a sell of the same asset cancel each other directly, without going to external liquidity.
The larger the batch, the higher the match rate, so a small order gets a price unattainable for it alone.
Batch settlement time is an engineering budget that must be held.
The entire path from order collection to payout calculation must fit within a fixed interval, so computation grows not per order but per groups of intersecting interests: a batch several times larger is computed in comparable time.
We check resilience under activity spikes separately: batch boundaries and order composition must remain stable under load. The reference point is the CoW Protocol model, where cycle settlement and rights to its result are explicitly separated.
In peak flow simulations, we monitor that the share of executed orders and settlement time remain within target boundaries rather than degrading gradually.
Batch auction formats: uniform price, ring offsetting
The uniform clearing price is the point at which the batch's total demand intersects total supply. All orders within the window execute at it, so the order in which they arrive ceases to provide an advantage: front-running and buying up a position in the queue lose meaning.
The only remaining question is how to collect the batch itself and what to use to close unmatched volumes.
The choice of scheme is determined by two factors: whether there is counter-interest within the flow and what execution delay the market is willing to tolerate.
Below are four options that are actually chosen between during design — in a working configuration they are usually combined.
| Option | When it fits | Limitations |
|---|---|---|
| Pure batch auction | Dense homogeneous one-way flow, protection against order front-running matters | Little internal liquidity, some orders go unexecuted |
| Ring offsetting of counter orders | Multi-directional interests close into a chain A→B→C→A | Requires ring search over a graph; on rare pairs offsetting remains incomplete |
| Hybrid settlement with external liquidity | Internal volume is insufficient, a topping-up source is needed | Dependence on an external source: adds delay and the risk of its unavailability |
| Periodic scheduled settlement | Thin market where tick predictability matters | The order waits until the end of the window, and an arbitrage window arises at its boundary |
In practice, a pure batch and ring offsetting give the best price but require dense flow, so they are supplemented with hybrid topping-up.
Implementation order: from order flow audit to acceptance
Deploying batch settlement is not connecting an external service but moving order matching logic into a controlled loop. We start with a survey and finish with acceptance on real data, so that the divergence from the previous flow is visible before production rollout.
- Order flow audit. We take order and cancellation logs, count the share of counter orders, the share of partially executable orders, and book depth. The output is a flow profile: how often orders overlap and what volume actually enters a batch.
- Batch settlement scheme. We fix the collection window boundaries, batch closing moment, uniform price rule, and residual distribution order. The scheme is agreed before code — otherwise settlement yields a correct but unexpected result.
- Solution selection rules. We describe which order sets are considered admissible, how ties are resolved, and what to do with orders that did not enter the batch. The rules become part of configuration, not logic in code.
- Settlement loop setup. We bring up the settlement service, order intake gateway, and settlement data handler. The batch is settled as a whole: either all orders in it pass, or none do.
- Historical data validation. We run past flows through the new scheme and compare with what was executed previously. We explain divergences for each order: where it worked out better, where differently.
- Handover and acceptance. We hand over the settlement scheme, selection rules, on-call regulations, and metrics. Acceptance is based on parallel run results, not a demonstration.
Handover package: settlement configuration, roles, regulations
System handover is not a file archive but a set of artifacts by which your team can itself bring up the settlement loop, change batch parameters, and restore operation after a failure without our involvement.
We assemble the package so that every decision has an explanation: what is configured, why exactly so, and what will change if a parameter is touched. Below is the composition you accept by act.
- Settlement configuration — auction window duration, batch size, order priority rules, permissible slippage thresholds, and execution limits, with a note for each parameter: what it affects and within what bounds it is safe to change.
- Component interaction schemes — the order path from intake to settlement, the price fixing moment, points of reconciliation with external sources, and places where settlement stops on divergence.
- Access policies and roles — a "role — action — environment" matrix for the operator, risk manager, and on-call engineer; separately, the procedure for issuing and revoking keys and separation of rights to change parameters and to move funds.
- Support regulations — inspection schedule, dependency update procedure, settlement stop criteria, on-call procedures, and notification channels for deviations.
- Settlement recovery plan — state checkpoints, the procedure for re-running a batch from the order log, and permissible divergence bounds when reconciling the result.
- Documentation — architecture description, data schemas, decision log with justifications for rejected options, and instructions for the on-call shift.
- Test loop — order sets with reference results and run scenarios, so that your changes are validated before rollout, not after.
Acceptance proceeds item by item: our engineers go through the composition together with your team, answer questions on each artifact, and record comments. Describe the task — we will return with an estimate and a handover plan.
Case study: how batch settlement removed the race for order ordering
The client is a trading venue with a continuous order flow: market makers and retail participants sent orders into a common queue, and the trade price was determined by the order of entry into it.
Whoever came first took the difference, while others received execution on a residual basis. In measurements before implementation, the share of executed orders stayed around 58%, and the price spread between participants within a single flow reached 3%.
The core was rewritten for batch settlement: orders accumulate in the auction window, and after it closes the settlement loop matches them at a uniform clearing price.
Counter-interests are matched directly, so the intermediary link that previously intercepted the flow disappeared.
The matching scheme was built on the model of CoW Protocol — matching counter orders instead of racing for the queue, and with it went repeated attempts to send an order at an already outdated price.
| Metric | Before | After |
|---|---|---|
| Share of executed orders | 58% | 91% |
| Price spread between batch participants | up to 3% | 0.2–0.4% |
| Repeated order submission attempts | up to 4 per order | isolated |
| Load on the settlement loop | linear with order flow | one settlement per batch |
The batch auction case delivered an effect not only in prices. Load on the settlement loop stopped growing with each order: settlement is performed once per batch, not for each counter offer, so the settlement node handles peak windows without scaling.
Before-and-after measurements were taken on the same load profile — the increase in the execution share is explained by the change in the settlement model, not a change in flow.
How batch execution differs from continuous exchange
Both modes solve one task — bringing a buyer together with a seller — but answer differently the question of when the price is fixed.
In continuous exchange, a trade closes immediately when a counter order appears: the book updates on every event, and the result depends on who was faster. In batch mode, orders accumulate within the window, and the price is determined once for the entire accumulated volume.
Hence the difference in who benefits from speed. In continuous exchange, the advantage goes to the participant with the fastest infrastructure: seeing someone else's order, they manage to get in front of it, while others get a worse price.
Batch mode removes this possibility — within the window, the submission moment ceases to affect the result, everyone executes at a uniform price, and the order of order arrival drops out of the calculation.
The fate of partial execution looks different. In continuous exchange, an order closes in pieces, can hang in the book for hours, and its author knows neither the final volume nor the average price until the very end.
In batch mode, at the window boundary the remainder is either partially executed at the common price or returned to the owner — that is why auction rules separately specify the residual policy: what share may be closed and what to do with the unexecuted part.
The two modes handle rare counter-interest differently. A thin book in continuous mode produces a wide spread and slippage: every trade moves the price.
A batch collects flows in one window and allows ring matches — when there is no direct pair, but three or four participants close into a chain, and each gets the desired asset. This reduces the requirement for constant liquidity but complicates settlement.
The choice of settlement mode is a consequence of the liquidity model, not a matter of taste. With a constant flow of liquidity providers, continuous exchange is simpler and gives instant feedback. With an intermittent flow, batch windows give a fairer price and less slippage.
In practice, a combination is often built: a batch auction as the main mechanism and continuous exchange for those who need an exit at any moment.
Technical concerns: delays, liquidity, updates
A batch auction collects orders into a round window and settles them after it closes — execution is delayed by the window length. This is a conscious trade-off: all trades in the round go at a uniform price, and an order cannot be front-run between submission and execution. Below are four concerns that are usually checked before starting.
Batch settlement delay — how large is it?
It equals the round window, not the settlement time itself. An order can be canceled or replaced before closing, winners are determined by the final book, so late submission gives no advantage.
Window length is a parameter: shorter for active instruments, longer for rare ones to accumulate counter-interest.
The order book is thin — will there be execution at all?
Matching is sought between all orders of the round, including cross pairs, so a thin book does not mean empty settlement. A volume threshold applies: if it is not reached, the auction does not start, and orders are returned without execution. The uncovered remainder goes to external liquidity sources.
Can contracts be updated without stopping settlement?
Rules are versioned: new logic is published as a separate contract, the registry pointer switches to it, and open rounds are played out under the previous version. There is no downtime — settlement of the current window does not depend on a rule change. Rollback is switching the pointer back; settled rounds are not recalculated.
How can we be sure settlement is correct and compatible with the current exchange?
Compatibility is checked at the integration stage: order formats, rounding precision, and residual distribution order are compared.
Correctness is confirmed by a reference settlement model — it runs historical and synthetic rounds and reconciles the sum of debits with the sum of credits. Before deployment, the rules are tested on a copy of the network.
Let's discuss the task: batch settlement for your order flow
For a substantive conversation, full documentation is not needed — a description of the current order flow is enough: how many arrive and at what frequency, whether there are counter orders, how the settlement price is currently determined, and what prevents settling orders in batches. The more concrete the input, the fewer assumptions in the estimate.
After the discussion, we return with four things: an estimate, a stage plan, the scope of settlement work, and the distribution of responsibility between teams.
- Estimate — effort and timelines by stage, with an explicit list of assumptions they depend on.
- Stage plan — matching and batch disclosure logic, settlement smart contracts, integration with your order source, load testing, launch.
- Settlement scope — order disclosure procedure, uniform price for the entire batch, handling of partially executed and canceled orders.
- Responsibility distribution — what we cover, what remains on your side: accesses, keys, price source, infrastructure.
- Failure scenarios — how the batch behaves when the price source is unavailable, during state desynchronization, and when rolling back to a previous version.
- Acceptance criteria — which scenarios we test, which metrics we consider target, and on which order sample we reconcile the result.
- Risks and open questions — recorded before the start, not in the middle of the work.
Describe the task in free form — in writing or on a call, whichever is more convenient. We will name what data is missing for a final estimate and suggest a convenient starting point for the batch auction project.