Cowswap

Cowswap solvers: auction bids and trade execution

Cowswap solvers compete to turn signed trading orders into executable settlements through CoW Protocol’s auctions. Each proposal identifies trades, token amounts and the liquidity needed to fulfill them. The protocol compares eligible bids using user surplus and protocol fees, then selects a fair combination of winners. A winning bid still needs successful on-chain settlement within the auction deadline.

Your signed terms define acceptable outcomes, giving solvers a boundary for the execution they propose. Understanding that division helps explain route choices, price improvement and the difference between an attractive proposal and a completed trade.

Signed limits and the orders in a bid

An order’s token amounts and price boundary constrain the trades a solver can include in a solution. A sell order sets the quantity to sell and minimum return; a buy order sets the desired purchase and maximum spending. Solvers can search different routes without changing those authorized trading terms. The settlement contract enforces the limit price. An improved price can produce surplus, while an incompatible proposal cannot fulfill the order within its signed conditions.

Partial-fill settings determine whether a solution can execute only part of the order. A fill-or-kill order permits its full specified amount or no execution; a partially fillable order permits smaller fills. The order’s recipient and expiry remain relevant whichever solver wins, alongside its amount and price constraints. Market orders derive a price boundary from their quote and slippage tolerance, while limit orders use their specified price target. An unfilled order can remain eligible across auctions until expiry, subject to balance and other execution checks.

Peer matching, pools and private liquidity

Solvers can draw on matching orders, automated market makers and private market makers to assemble a settlement. A Coincidence of Wants occurs when orders supply assets other orders need. Automated market makers, or AMMs, provide pool liquidity through their trading contracts. Private market makers offer liquidity a solver can incorporate when it has access to it.

Peer matching, pools and private liquidity

Solvers can draw on matching orders, automated market makers and private market makers to assemble a settlement. A Coincidence of Wants occurs when orders supply assets other orders need. Automated market makers, or AMMs, provide pool liquidity through their trading contracts. Private market makers offer liquidity a solver can incorporate when it has access to it.

• Source of trade proceeds (Liquidity source) Coincidence of Wants: Other orders in the batch AMM liquidity: Tokens held in trading pools Private market maker liquidity: Liquidity offered by a market maker
• Solver’s use (Liquidity source) Coincidence of Wants: Match compatible trading demand AMM liquidity: Select or combine executable pool routes Private market maker liquidity: Incorporate executable quoted liquidity
• What must be available (Liquidity source) Coincidence of Wants: Orders with mutually compatible amounts and prices AMM liquidity: Accessible pools with sufficient liquidity Private market maker liquidity: A quote the solver can access and execute

These sources can complement one another within a proposed settlement. The source changes where the buy tokens come from; the order still governs acceptable exchange terms. Compatible demand enables direct matching; external liquidity can fill any remaining gap when the combined route satisfies the trading conditions.

View full-size image

These sources can complement one another within a proposed settlement. The source changes where the buy tokens come from; the order still governs acceptable exchange terms. Compatible demand enables direct matching; external liquidity can fill any remaining gap when the combined route satisfies the trading conditions.

The solver engine, driver and auction coordinator

A solver engine computes which orders to execute using available liquidity, then returns settlement instructions to a driver for evaluation. Different engines can use different matching algorithms and liquidity connections. This division separates the search for a good trading solution from the operational work needed to put it on-chain. CoW Protocol treats the engine and its driver together as a solver.

The driver encodes the instructions into a transaction, checks execution through simulation and handles submission when the auction selects its bid.

CoW Protocol’s autopilot coordinates the auction, including its eligible orders and timing. It communicates auction information to registered solvers and arbitrates the competition, drawing on trading instructions the order book supplies. An engine’s mathematical answer therefore needs an executable transaction and coordination with the auction infrastructure. Liquidity discovery, accurate cost estimation and successful submission all affect whether its proposal becomes a trade.

Surplus and fees in the auction score

Surplus measures improvement relative to an order’s acceptable exchange terms, using the executed amount as its basis. Sell-order surplus counts additional buy tokens received beyond the minimum for that executed sell amount. For a buy order, it is the sell tokens saved against the corresponding spending limit. Those measurements use different tokens. CoW Protocol scores solutions using user surplus and protocol fees, converted into a common unit of value. This conversion permits comparisons across solutions involving different token pairs.

An auction score describes a proposal’s aggregate value, while your proceeds depend on your order’s executed amounts and fees. Protocol fees contribute to scoring alongside the surplus left to traders. Solvers also account for execution costs when constructing competitive bids. A route with greater gross output can lose its advantage when execution consumes more resources. Comparing the expected net trade amount with the order’s price condition keeps the trader’s outcome separate from the solver’s competition score.

Fairness before the winning combination

The auction compares directed-pair bids with proposals combining trades across multiple pairs. A directed pair means a particular sell token and buy token in that direction. The best available bid containing only that directed pair supplies its reference score. A combined proposal must meet each applicable pair reference, so gains on other pairs cannot offset a lower score on an included pair.

After filtering, the protocol selects a combination of compatible winning bids with the aim of maximizing total score. All executed orders on the same directed pair must belong to one winning bid. The selection must respect those grouping constraints and the computation available for finding a combination. Consequently, one proposal’s large aggregate score does not alone establish that it will win.

Several solvers can win parts of one auction, with each winner responsible for settling its selected solutions.

Uniform exchange prices within each solution

Uniform Directional Clearing Prices (UDCP) require the same exchange price for orders trading the same token pair in the same direction within a solution. Each solution must respect uniform directional prices, with an exception to account for the gas costs of hooks. A hook is an extra call associated with an order. The rule does not demand one identical price across every alternative proposal a solver submits. Fee policies can also change net proceeds without changing the underlying swap price.

Settlement deadlines, liquidity changes and MEV

Auction selection creates an execution commitment; the solver must get its winning settlement onto the blockchain within the deadline. It must preserve the promised score and executed amounts when delivering that settlement. A solution can look feasible during bidding and later fail because external liquidity changes or transaction inclusion takes too long. The deadline follows the applicable network’s auction configuration.

The driver can keep simulating the proposed transaction against blockchain state while submitting settlement to reduce execution uncertainty. Pool movements between bidding and execution create positive or negative slippage for the solver. Settlement buffers can absorb permitted differences under protocol accounting rules. They do not authorize a solver to ignore the user’s price limit or deliver different amounts from its winning bid. Reverts and late execution can lead to penalties.

AMM interactions can expose a settlement to transaction-ordering attacks, a form of maximal extractable value (MEV). The reference driver can use protected submission for those transactions and a different strategy for settlements without AMM interactions. Completed settlements remain visible in on-chain trade records.

Performance rewards and reliable settlement

Performance rewards relate to the value a solver adds beyond the auction outcome possible without its bids. Reward caps and failures to execute winning solutions in time affect the calculation and can produce a penalty. The protocol pays solver rewards in COW tokens, while operators pay transaction costs in the network’s native asset. Those costs can exceed the reward from an individual auction.

Consistency rewards also evaluate competitive bidding and settlement reliability over an accounting period. The bid-quality component concerns executed market orders; out-of-market limit orders do not contribute to that component. Timely settlement of won orders affects the success-rate component. This encourages operators to offer competitive proposals they can deliver, including when other solvers win the eventual execution.

Reward rules can change, and protocol accounting combines reward calculations with network-fee and settlement-buffer accounting to determine an operator’s final payout.

Bonding, registration and execution accountability

A production solver must have bonding support and registration in CoW Protocol’s off-chain infrastructure. The settlement address needs authorization, and a bonding pool vouches for the solver’s submission and rewards addresses. Joining a pool differs from creating a new pool. Reduced bonding arrangements concern solvers already vouched for under the CoW DAO pool and require approval. A working algorithm therefore needs an approved production setup before it can participate as an executing solver.

Governance oversight addresses unfair execution against baseline liquidity, score inflation and harmful use of settlement buffers beyond the contract’s own checks. CoW DAO can penalize or slash operators for rule violations. A transaction succeeding does not establish compliance with every competition rule. The contract, auction infrastructure and governance enforce different requirements.

Auction proposals and the settled trade record

CoW Explorer combines off-chain order information with on-chain settlement data. An order identifier locates the order and its recorded status, while a settlement transaction hash identifies the orders executed together. The Order book API also provides solver-competition information by auction identifier or transaction hash. These records answer different questions: the competition describes proposed execution, while settlement shows the trades the winning solver actually executed.

Executed sell and buy amounts give a more direct account of the trade than the solver’s total score. Fee records explain protocol or partner charges associated with that execution. Partial fills require their own executed amounts, because the original order size can exceed a particular fill. A pending order has no completed proceeds simply because a solver proposed an attractive route. The relevant outcome is the recorded fill under the order’s authorized conditions.

Cowswap solvers - common questions