cowswap is a DEX aggregator where solvers settle signed token orders through CoW Protocol batch auctions. A swap fills only if a solver can meet the order’s minimum output before it expires. For a live token swap, use cowswap to put the trade into that competition and seek execution across DEX liquidity.
-
A signed order states the trade the user accepts; it is not an immediate on-chain swap.
-
Solvers match users or route through liquidity pools, then settle the winning solution.
-
Build around net received amount, expiry and confirmed settlement, not the quote alone.
How does cowswap turn an order into a swap?
CoW Swap sends a user’s signed trade intent to CoW Protocol’s off-chain order book. That order states the tokens, amount and worst exchange rate the user accepts. Eligible orders enter batch auctions, where solvers bid to satisfy them; a winning solver submits the settlement transaction under those signed constraints.
Solvers look for a coincidence of wants: orders that can trade against each other. Without a useful match, they can tap DEX pools or other liquidity, sometimes combining routes. The auction favors solutions that create surplus, meaning output above a seller’s minimum or input saved below a buyer’s maximum.
Batching reduces a specific MEV risk. Ethereum.org describes maximal extractable value as value gained by controlling transaction inclusion or order; sandwiching a visible AMM swap is one example. The user’s signed intent is not itself a public mempool swap, and its limit constrains settlement, though neither feature guarantees an optimal price.
Consider users on opposite sides of a liquid token pair: a solver may match them without moving an AMM price. For a thin pair with no opposing order, the solver may need several pool hops, and the trade can fail the user’s limit. Matching is an opportunity, not a requirement for a fill.
What must an integrator specify and sign?
Specify the chain, token contract addresses and decimals, amount, order kind, recipient and validity window. Symbols alone are unsafe because different contracts can share one. A sell order caps input and sets minimum output; a buy order fixes desired output and caps input.
Translate slippage tolerance into the signed limit. Say a sell quote estimates 0.400 ETH for 1,000 USDC: at 0.5% tolerance, the illustrative minimum is 0.398 ETH, calculated from the net quote. A solver may improve on that floor but cannot settle below it.
The wallet signs EIP-712 typed data, which binds order fields to a chain and verifying contract. The EIP-712 specification defines that domain separation; show the token amounts and recipient before requesting the signature. The sell token needs sufficient allowance for the protocol’s spender, and an approval transaction can require native gas.
At cowswap.dev, you would run a representative swap with the same pair and size to see the result your interface must explain. For programmatic orders, CoW Protocol’s SDK or order book API can fetch a quote and submit the user’s signed order. Keep the quote and signed payload together so a refresh cannot change what the user approved. If you stream quotes, mark unverified estimates as provisional: a later verified quote can be numerically worse but more executable.
What does a swap cost, and when does it fill?
A CoW Swap trade fills only while a solver can meet its signed limit; its real cost is the net amount received or spent at settlement. That amount reflects execution costs and any applicable protocol fee. Gas conditions, liquidity and order size affect the result, so show the quote beside the signed worst case in the same units.
The user signs the order off-chain; the solver submits the settlement transaction and accounts for its cost in the solution. If the sell token lacks sufficient allowance, approval is an on-chain transaction paid by the user. A gasless signature therefore does not mean the first trade has no network cost.
An aggressive limit on a thin pair may expire unfilled; a market-style order derives its limit from a quote and slippage tolerance. A partially fillable order can settle in pieces. A fill-or-kill order settles its specified amount or remains open until cancellation or expiry.
How should an integration confirm the outcome?
Track the order UID until on-chain settlement confirms input, output and recipient. Order-book submission means the order is eligible for solving, not that the trade happened. Reconcile its off-chain status with the transaction before crediting a balance or declaring success.
For an open order, show expiry and allow cancellation or replacement under the protocol’s rules. Cancellation and settlement can race, so treat final on-chain state as decisive. For a partial fill, record cumulative amounts rather than calling the first execution the whole trade.
After an unfilled expiry, fetch a fresh quote and request a new signature. I would test one liquid pair and one thin pair, then ship only when the interface handles both a confirmed fill and an unfilled expiry without presenting the quote as a promise.