cowswap is a DEX aggregator built on CoW Protocol: users sign swap orders, and solvers compete to settle them in batches. For an integration routing user trades, choose cowswap over a direct AMM call when the order should compete across DEX liquidity with reduced sandwich exposure. CoW Swap executes only within the user’s signed price bound.
What does cowswap aggregate?
It aggregates execution proposals, not just pool quotes. Solvers can match compatible orders directly, route unmatched volume through DEX liquidity, or combine both in one settlement. A direct match, called a Coincidence of Wants, can avoid an external pool trade; its availability depends on the orders present in that auction.
The useful distinction for an integrator is between a quote and an execution guarantee. A quote estimates what a solver can deliver now, while the signed order states the worst price the user accepts until expiry. Changing liquidity or gas costs can make that order unattractive to solvers without making it invalid.
Batch auctions also change the MEV exposure. Users submit signed orders off-chain rather than broadcasting individual swaps for a bot to sandwich. Orders on the same directed pair in a winning solution face a uniform clearing price, subject to protocol rules; this reduces a common extraction route but does not promise that every fill beats every other venue.
How does an order reach settlement?
The path is quote, signature, order book, solver auction, then on-chain settlement. An integration requests a quote for a sell or buy amount, checks the returned amounts and costs, and constructs an order whose token addresses, amounts, recipient, expiry and app data match the user’s intent. The user signs the order; submitting that signature does not itself move tokens.
For a sell order, sellAmount caps the input and buyAmount sets the minimum output. A buy order reverses the economic constraint: its requested output is fixed and its input is capped. validTo is a Unix expiry time, while partiallyFillable determines whether a solver may execute less than the full amount.
The order book makes eligible orders available to the auction service, which sends them to solvers. Solvers propose feasible groups of fills and liquidity interactions; the auction selects winning solutions under price and fairness constraints. A winning solver submits the settlement transaction, where the signed limit is enforced on-chain.
Before submission, the wallet needs enough sell tokens and an allowance for the protocol’s token spender. A first ERC-20 approval is an on-chain transaction with its own gas cost; later signed orders can use an existing allowance. Check the chain and signing domain as well as the spender, since an otherwise valid signature or approval on the wrong chain cannot fund this order.
Track the order by its UID through open, filled, expired or cancelled states, and reconcile fills against on-chain trade records. A successful API submission means the order entered the order book, not that a solver will execute it. If balance or allowance falls below the required amount before settlement, a previously eligible order can stop filling.
What price and costs should the user expect?
The user should expect a net execution at or inside the signed limit, with no promise of a fill. For example, suppose an illustrative sell quote exchanges 10,000 USDC for 5 ETH. A 0.5% slippage tolerance sets a 4.975 ETH minimum; a 5.01 ETH net fill beats the quote by 0.2% and the signed floor by 0.035 ETH.
That 4.975 ETH floor is a constraint, not a forecast. If available routes deliver only 4.97 ETH after costs, the solver cannot fill the order at that price. Increasing tolerance raises fill probability but accepts a worse outcome; tightening it does the reverse, especially for thin pairs or volatile markets.
Separate network execution costs from protocol or integration fees when presenting a quote. The solver pays gas to submit settlement, but those costs are reflected economically in the offered trade; “gasless swap” does not mean costless execution. Fee policies can also take a share of price improvement or apply to volume, so compare the user’s net received or spent amount rather than a pool’s gross rate.
Limit orders add a different trade-off. A limit price can stay eligible across multiple auctions until validTo, but touching that price on a chart does not ensure a solver can settle the full order after gas, liquidity impact and fees. Partial fills help large orders use available liquidity, while creating a residual position the integration must continue to track.
How should an integrator put it into a product?
Build the flow around the signed constraint and the observed settlement. Request a fresh quote, show the net amount and worst acceptable amount, obtain any required approval, then sign and submit the order. Keep the order UID and use order status plus confirmed trades to update balances; a quote response alone is insufficient accounting evidence.
Choose quote latency deliberately. Waiting longer can let more solvers respond, particularly on thin pairs, but increases the time before a user can sign a price that may already have moved. For example, a streaming quote timeout around one to a few seconds is a starting point to measure against your pair mix, not a fixed execution deadline.
CoW Swap fits an integration that can tolerate auction latency in exchange for solver competition and a signed minimum outcome. I would ship a sell-order flow first, measure net fill rate and time to settlement by pair, then add buy orders and partial fills only when the product can account for their different constraints.