Cowswap
Cowswap solvers compete to execute trades within your signed limits.
Last updated -Cowswap solvers search for executable trades and compete through CoW Protocol’s batch auctions. They combine matching orders with available liquidity, then propose settlements that respect users’ signed limits. The protocol evaluates those proposals and can select several winning solutions within an auction. You authorize the execution terms when you sign the order, then check what the selected solver actually delivers. Competition creates opportunities for better execution, but available liquidity, transaction costs, and settlement timing constrain those opportunities. A winning bid alone doesn’t establish that your trade completed. Understanding the distinction between routing, auction selection, and settlement helps explain both successful fills and orders that remain open.
Order Matching, Liquidity Routing, and Settlement Construction
Solvers perform connected jobs: find compatible orders, obtain any additional liquidity, and construct transactions that can execute the proposed trades. Each job depends on different inputs. Matching needs compatible trading intentions. Routing needs accessible liquidity at acceptable prices. Settlement construction needs contract calls that work together without violating order constraints.
A Coincidence of Wants occurs when trading intentions provide liquidity for one another. That match can cover an entire trade or only part of it. Solvers can obtain the remainder elsewhere, combine orders that share a route, or split execution across liquidity sources. These choices can reduce pool interactions and price impact. The benefit depends on the orders and liquidity available in that auction; not every trade receives the same routing advantage.
The Solver Engine and Driver
When a solver uses a separate driver, its engine searches for solutions, while the driver handles supporting work that turns proposed trades into executable settlement transactions. Both affect execution quality.
Liquidity and Order Inputs
The engine receives auction information and uses liquidity that its implementation can access. Preprocessing can supply token metadata and exclude orders that lack sufficient balances. Different liquidity connections and optimization methods can therefore produce different proposals for the same auction.
Simulation and Submission
The reference driver encodes proposed settlements and simulates them before treating them as valid. It also checks execution conditions during submission. Simulation tests a transaction against a particular blockchain state. It doesn’t reserve that state, so subsequent liquidity changes or congestion can still prevent settlement.
Fair Combinatorial Auctions Select Compatible Bids
The auction compares bids covering individual directed token pairs with bids covering groups of pairs. A directed pair distinguishes selling one token for another from trading in the opposite direction. The protocol establishes a reference score for each directed pair, then excludes grouped bids that underperform the relevant reference.
A fair combinatorial auction can select multiple winning solutions. Selection seeks a combination of eligible bids with the highest total score, subject to the auction’s constraints. This makes the comparison broader than choosing one solver’s headline quote. A proposal must fit the eligible combination and satisfy fairness requirements.
Order Surplus and Auction Scores
Surplus measures execution relative to an order’s limit, with different calculations for sell and buy orders. The auction aggregates eligible order scores using reference prices, allowing it to compare outcomes involving different tokens. Protocol fees also enter the scoring calculation; the score isn’t simply a wallet balance increase.
Sell-Order Surplus
A sell order receives surplus when its buy amount exceeds the minimum associated with the executed sell amount. For a partial fill, the relevant minimum follows the filled quantity. Comparing a partial fill with the minimum for the entire order would misstate its execution.
Buy-Order Surplus
A buy order receives surplus when it spends less than the permitted sell amount for the quantity bought. In either case, surplus above the signed limit differs from improvement over an earlier quote. A generous limit can leave room for surplus even when execution doesn’t beat that quote.
The Settlement Contract Enforces Order Boundaries
The settlement contract checks signed order parameters before executing trades. Those checks cover authorization, expiry, filled quantities, and acceptable prices. Solvers choose how to assemble a settlement within these boundaries. They don’t gain authority to rewrite the signed trade merely because their bid wins.
The settlement contract rejects execution that violates an order’s limit price. For ordinary ERC-20 transfers, users approve the vault relayer contract rather than an individual solver. Protocol contracts then handle transfers under the settlement rules. An approval to a solver’s own address isn’t part of that authorization arrangement.
Execution Costs and Solver Incentives
Solver economics influence which routes remain competitive after execution costs. A route that produces more tokens before costs may require enough additional gas to lose its advantage. Solvers account for these costs when constructing and bidding on solutions. Separately, performance rewards depend on the solver’s contribution relative to competing bids and whether its winning solutions settle on time. The reward mechanism can produce penalties for unsuccessful execution. These incentives encourage executable proposals, although they don’t turn a selected bid into a completed trade.
Liquidity Changes and Unfilled Orders
An order can remain open when solvers can’t find a competitive, executable solution within its terms. Auction participation doesn’t require every submitted order to fill.
Thin liquidity restricts the volume available near an acceptable price. Splitting a route can help when suitable alternatives exist, but additional routing can’t create liquidity that counterparties don’t offer.
Balances and approvals also affect feasibility. If either changes after submission, a previously plausible settlement may fail its checks. Solvers must work with the account state that execution will encounter.
Timing adds another constraint. Winning solutions must meet the auction’s settlement deadline, whose configuration depends on the network. That deadline differs from the order’s expiry. A valid unfilled order may remain eligible for later auctions, while a missed settlement opportunity proves nothing about the next auction’s outcome. A displayed market price alone doesn’t establish that sufficient liquidity remains available for the requested quantity after costs.
MEV Protection Depends on the Execution Path
Delegated execution changes exposure to maximal extractable value, or MEV, because the user signs an intent rather than broadcasting an ordinary swap transaction. Solvers must source an execution that respects that intent. Peer matching can avoid the pool interactions that create opportunities for conventional sandwich attacks.
Settlements that use external pools still interact with changing markets. Submission methods can reduce exposure to public transaction ordering, and the reference driver supports different strategies for that purpose. These mechanisms don’t freeze pool prices or promise secrecy for order information. For a thinly traded pair, market movement can remove an executable route before settlement even while the signed limit still rules out execution at a worse price.
Clearing Prices and Net Receipts
Uniform Directional Clearing Prices require orders trading the same pair in the same direction within a solution to share a clearing price. Orders containing hooks have an exception that accounts for their additional gas costs. The requirement applies within each solution, rather than universally across separate solutions or different auctions.
A clearing price and a final wallet receipt describe different things. Fees and executed quantities affect the amount a recipient obtains. Compare realized amounts using the same fee treatment and fill quantity before attributing a difference to solver performance. The settlement’s routing graph can explain how liquidity moved, while the order’s executed amounts establish what that particular trade delivered.
A Winning Bid Checked Against Its Actual Fill
Consider a hypothetical full-fill sell order offering 127.5 sell tokens for at least 82.5 buy tokens. Assume its signed terms express those amounts after applicable fees. A selected solver proposes 83.5 buy tokens. All quantities and the proposed outcome in this example are hypothetical.
The proposed improvement doesn’t yet justify treating the bought tokens as available. Look up the existing order by its order ID in CoW Explorer and inspect its execution record. In this example, the record later links the order to a successful settlement showing the complete sell quantity and 83.5 buy tokens delivered to its recipient. That changes the evidence from a proposed bid to an executed trade.
The full-fill quantity and recipient match, and the received amount exceeds the minimum: 83.5 minus 82.5 equals 1.0 buy tokens. A transaction containing other orders, without this order’s fill, wouldn’t establish the same result. Raising the hypothetical minimum above 83.5 would make this particular proposal insufficient.
Frequently asked questions about Cowswap solvers
Do I Choose Which Solver Executes My Order?
The protocol’s auction selects the winning solutions for ordinary orders. You don’t need to choose an individual solver before submitting a trade. Your signed terms determine acceptable execution, while competing solvers propose ways to achieve it. The settlement record identifies the participant that executed the winning solution.
Does the Solver That Supplies a Quote Have to Settle the Trade?
Providing a quote doesn’t reserve the later settlement for that solver. Price estimation and settlement competition serve different purposes. Quotes help establish expected execution and order limits, while the auction evaluates executable proposals after submission. Another solver can win the right to settle the order.
Must I Hold COW Tokens to Benefit From Solver Competition?
An ordinary trading order doesn’t require a COW balance simply to enter solver competition. COW-denominated solver rewards concern the participants that provide execution. Your order instead needs the relevant trading balance, authorization, and valid terms. Receiving surplus doesn’t depend on personally receiving a solver reward.
Who Pays Gas When a Solver’s Settlement Transaction Reverts?
The account submitting the reverted settlement transaction bears its network gas charge. Solver execution costs differ from separate transactions that a user submits, such as token approvals. A settlement revert doesn’t reverse an earlier successful approval transaction or refund the network fee paid for that approval.
Where Can I Inspect Bids That Didn’t Win?
The solver competition API provides competition information associated with an auction or settlement transaction. That information serves a different purpose from an order’s fill history: it describes the competition around execution. A losing proposal remains a proposed solution, so its quoted amounts aren’t evidence of tokens delivered.
What Does Becoming a Production Solver Require Beyond an Algorithm?
Production settlement requires authorization and bonding arrangements as well as software that produces valid solutions. Solver participants must satisfy the competition’s operational and governance rules. Writing a routing algorithm alone doesn’t authorize its account to submit settlements, and bonding requirements shouldn’t be confused with requirements for ordinary traders.
Why Can an Old Order’s Filled-Amount Storage Show Zero After Execution?
A solver can clear expired orders’ filled-amount storage to recover gas, so that storage alone isn’t reliable historical execution evidence. Historical settlement events and order trade records preserve the relevant execution context. A zero value in cleared storage doesn’t establish that an old order never traded.