Batch arbitrage combines trades in one settlement so price differences across orders and liquidity pools can help improve execution. It matters most when another trader wants the token you are selling, or when a pool’s price differs from the price available elsewhere.
Batch arbitrage connects orders before using a pool
Solvers inspect orders grouped into an auction and look for ways to settle them together. If one person is selling Token A for Token B while another is selling Token B for Token A, the trades may match directly; the solver can then use a pool only for any unmatched remainder.
That direct match can avoid some pool fees and price impact. Arbitrage can also help when a pool offers a better price for one leg of a trade than another available route: a solver can combine the route with other orders, then compete to submit a solution that gives users more surplus while respecting their limits.
For example, say you want to sell 100 USDC for Token X, and another order wants to sell Token X for USDC. If their amounts and acceptable prices line up, the solver may match part of both orders without sending that portion through an automated market maker. If only 70 USDC worth matches, the solver still has to find a route for the remainder—or leave your order unfilled if it cannot meet your minimum.
The best batch is judged by what orders receive
Arbitrage improves your result only when it supports a feasible solution that offers you an acceptable execution price. Solvers propose individual or grouped bids, and the auction selects a fair combination intended to maximize order surplus; a grouped bid cannot give an order less than an available individual bid. Orders trading the same token pair in the same direction also face a consistent clearing price within the batch, subject to protocol rules.
Suppose your sell order’s minimum is 1.8 Token X per USDC. A route that could produce 1.9 on the first 70 USDC but only 1.7 on the rest may fail if your order requires the full amount at or above 1.8. A partial-fill order may allow the solver to execute the better-priced portion, depending on your order settings. The limit price, available liquidity, fees, and executable trade sizes—not the mere existence of an arbitrage—decide the result.
If your immediate task is to swap through CoW Protocol, the cowswap interface lets you submit an order with its minimum acceptable output; check that threshold before signing. The auction can find a better route or match, but it cannot guarantee a fill at any price you prefer. This is the practical reason to set a limit you can accept rather than treating a displayed estimate as certain.
Check the minimum output and allow for a missed fill
For a one-off swap, compare the estimated output with the minimum output shown before you sign, and decide whether the trade still works at that floor. A tighter minimum protects your price but can leave the order pending or unfilled if pool prices move or no suitable counterpart appears; a looser one accepts more price movement.
Batching can also take time because the order is collected and solved with others, rather than being sent as a standalone pool transaction. If speed is more important than finding a matching order, account for that when choosing your trade settings. When you use cowswap, the useful question is whether the minimum output and possible wait fit this particular trade.
Use a batch auction when a direct match or better combined route could improve your acceptable output; otherwise, choose based on the minimum price and timing you need.