Recommended Bidding Strategy for Solvers

This guide describes a recommended baseline bidding strategy for solvers in CoW Protocol’s combinatorial auction, that is, the bid each solver should submit by default for a given solution, optimal under the standard assumptions that a solver values its own solution truthfully and does not model competitor behaviour. It gives a per-solution baseline formula, the inputs required to compute it, and the cases where deviating from this baseline may be profitable but requires additional information or assumptions, which is what the later sections cover.

The intended reader is someone running or planning to run a CoW Protocol solver who wants a self-contained operational reference.

info

TL;DR: How to bid?

For each solution a solver can settle, the recommended bid is a score equal to the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. The solver should also set a threshold on acceptable negative slippage so that a solution is settled only when its realised value remains non-negative, and should submit every solution it can profitably execute.

Overview

For each candidate solution $x$ the solver can submit, estimate the value it creates, the probability it settles successfully. Use the risk-adjusted score as the baseline bid. This is a dominant strategy in a simplified mechanism explained below and a recommended baseline in production. Deviations from the baseline require data about competitor scores, reward-cap binding, or fairness-filter effects.

The auction setting

The protocol runs a combinatorial auction. In each auction, a solver can submit candidate solutions. A solution is a commitment to settle a specified set of orders together with a reported score $s$. A solution may cover:

• A single directed token pair (handling all orders on that pair).
• Multiple directed token pairs (a batched solution, useful when coincidence-of-wants (CoWs) between pairs allow for peer-to-peer trading or when shared gas improves the routing).

The protocol filters batched solutions for fairness, then picks the combination of solutions across pairs and solvers that maximises total reported score.

An operationally important constraint is that winner selection cannot choose two solutions that touch the same directed token pair i.e, in each group, all orders have the same sell and buy tokens. A solver should also check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. If a solver wants to execute multiple orders on the same directed pair, those executions must be included in one combined solution. Multiple separate solutions on the same directed pair are not automatically aggregated by winner selection.

For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e. the best outcome the protocol could have achieved without that solver. This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$).

After winning, the solver is responsible for settling on chain. In the single-solution case, if the settlement does not land before the deadline, the settlement is unset: the solver pays the protocol $\min(\text{reference score}, c_l)$. With multiple winning solutions, partial settlement failures require the corresponding more general accounting. This is why solvers should adjust reported scores for the risk of an unset.

This per-solution view provides a useful approximation for reasoning about how expected settlement risks should enter reported scores.

Score and value

Let $x$ denote a candidate solution: the set of orders to be executed, their effective executed amounts, and the routing/liquidity sources used to execute them.

There are two main ways to assign value to a solution. Conflating them is the most common source of confusion.

• $S(x)$: the solver’s estimate of total score-relevant value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route).
• $s(x)$: the score reported to the protocol for solution $x$.

The reported score induced by the solution $x$ is sum of three components:

$$s(x) = (\text{user surplus}) + (\text{protocol fee}) + (\text{partner fee})$$

The user receives only the user surplus component. The remaining two are value generated by the trade that the protocol and any integrating partner collect.

The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also instead transfer the amount to itself immediately in the settled token). The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring.

Recommended baseline bid

For each candidate solution $x$ the solver can submit, estimate:

• $S(x)$: net value the solution delivers
• $p(x)$: probability the settlement succeeds until auction deadline (does not become unset)
• $c_l$: lower penalty cap.

The recommended baseline should account for both settlement risk and the fact that the solver's downside on an unset is capped. Use this as the baseline score:

$$s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$$

The two terms correspond to two regimes.

When the penalty cap does not bind, settlement risk discounts the value of the execution directly:

$$s_{\text{base}}(x) = p(x)\ S(x)$$

A strategy is dominant if it is the best choice regardless of what other solvers submit. This is the dominant strategy in the simplified mechanism where the reward cap does not bind and fairness filtering is ignored, and it is a robust baseline in production. In this setting, that means the solver does not need to predict the reference score or model competitor behaviour to choose the baseline score.

The intuition is that, in this regime, when the relevant caps do not bind and fairness filtering is ignored, changing the reported score only changes whether the solution wins. It does not change the solver’s payoff conditional on that solution winning: lowering the score may lose profitable wins, while raising it may win unprofitable ones.

When the lower penalty cap does bind, the loss from an unsuccessful settlement is bounded by $c_l$, the cap on the unset penalty lets the solver bid more aggressively:

$$s_{\text{base}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big)$$

The recommended baseline is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score.

Worked example

Consider a solver in an Ethereum mainnet auction ($c_l = 0.01$ ETH) who has computed three candidate solutions:

• Solution A: WETH→USDC pair. $S(A) = 0.15$ ETH, $p(A) = 0.97$
• Solution B: WBTC→USDC pair. $S(B) = 0.20$ ETH, $p(B) = 0.96$
• Solution C: batched solution combining both pairs, internalising CoWs between sellers. $S(C) = 0.42$ ETH, $p(C) = 0.94$

Applying the penalty-cap-adjusted baseline:

Solution	$s_{\text{base}}$ (ETH)
A	0.1497
B	0.1996
C	0.4193

The solver submits all three solutions. The protocol picks whichever combination maximises total score, subject to fairness filtering. If C survives the filter and its score beats other solvers’ contributions on the same pairs, the protocol picks C. If C is filtered out, A and B can still win their respective pairs.

Submitting every viable candidate is generally the right move once the solver has already computed the corresponding routes: each submitted solution adds an option for the protocol.

Slippage and unsuccessful settlements

Solvers can choose not to settle a selected solution, for example, if the desired routing would return significantly fewer tokens than expected. One way to implement this is to set a slippage tolerance $\gamma$: the maximum negative slippage the solver is willing to absorb between bidding and settlement. If on-chain slippage would exceeds $-\gamma$, the settlement does not happen.

A conservative baseline per submitted solution:

$$\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$$

The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. Unsetting instead incurs the a penalty $min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes.

For small solutions where $s(x)\leq c_l$, this reduces to $\gamma(x)\approx S(x)$. For larger solutions, it becomes $\gamma(x)\approx S(x)-s(x)+c_l$, meaning the solver tolerates less negative slippage because the cost of unsetting is capped.

Fairness filtering

A batched solution is excluded by the fairness filter if it under-delivers on any directed token pair relative to the per-pair reference outcome (constructed from the best individual-pair solutions across all solvers).

Two operational implications:

Submit individual-pair fallbacks. If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. A high-scoring batched solution that fails fairness is worth zero, the individual-pair fallbacks ensure the solver still wins the pairs it can.

Verify batched solutions pass the filter. Compute the per-pair reference outcome from the best individual-pair solutions in the auction and check that the batched solution delivers at least that much on every directed pair it touches.

Individual-vs-batch submission can also be strategic: strong individual-pair bids raise the fairness benchmark and can exclude competitors’ batched solutions, and vice versa. The baseline strategy in this guide does not rely on strategically changing scores to affect the fairness filter, and we do not recommend solvers use the fairness filter as a strategic target. Instead, solvers should compute honest individual-pair solutions, submit batched solutions only when they create additional value, and verify that those batched solutions pass the fairness filter.

Reward cap

The upper reward cap $c_u$ makes the mechanism first-price-like when it binds. Beyond the cap, increasing the induced score no longer increases the solver’s protocol reward, but it can still reduce the value the solver retains. In that regime, shading the score downward can increase expected profit. Doing so safely, however, requires a model of competitor scores: shading too far increases the probability of losing the auction.

Empirically on Ethereum mainnet (Dune query, ~2,000 auctions), the cap binds in about a third of winning batches, but the value at stake is usually small and concentrated in tail auctions:

Metric	Value
Auctions where cap binds	~34.8% (510 / 1,464)
Median clipped, when binding	~0.0002 ETH (~$1)
p99 clipped, when binding	~0.075 ETH (~$300)
Max clipped, single auction	~0.849 ETH

The baseline score remains the protocol's suggested starting point because it does not require predicting competitor behaviour. Solvers are free to use different scoring strategies, including reward-cap-aware shading, based on their own models of competition, execution risk, and expected payoff.

Consistency rewards

CIP-85 distributes a weekly consistency budget across solvers based on participation. Penalties paid on unsets feed this budget, so a solver receives back a fraction $\alpha$: their share of the budget at week-end, which is non-trivial to estimate. The effective per-revert protocol cost is therefore $(1-\alpha)c_l$, not $c_l$. The baseline formula above ignores this. Solvers with a stable consistency share can refine the cap-binding term by replacing $c_l$ with $(1-\alpha)c_l$ which increases optimal bids when the penalty cap binds. The exact $\alpha$ depends on aggregate weekly metrics that themselves depend on other solvers' behaviour, so the refinement only pays off for solvers who can estimate their share reliably and hence is used as an heuristic.

Quote rewards

If a solver won the quote competition for an order CIP-72, they must bid at least their quote $q$ in the auction to earn the quote reward. This adds a constraint $s \geq q$ on top of the baseline.

This means quote rewards should be incorporated into the solver’s expected-value calculation rather than treated separately from bidding. If satisfying the quote-reward condition requires reporting a score above the baseline score, the solver should account for the additional probability of winning and the expected payoff of those extra wins. Whether this is profitable depends on the quote reward, the distribution of competing scores, and the solver’s settlement risk.

The baseline score in this guide should therefore be read as the starting point before quote-reward incentives. Solvers participating in quote competition should incorporate the quote reward into their own expected-profit model.

Practical checklist

For each candidate solution $x$:

1. For each candidate solution $x$, estimate $S(x)$, $p(x)$.
2. Compute the baseline score $s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$
3. Set the settlement slippage tolerance using $\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$
4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome.
5. For multiple orders on the same directed pair, combine them into one solution.
6. Submit individual-pair fallbacks alongside batched solutions.
7. If quote rewards apply, incorporate the quote constraint and expected reward into the profit model.
8. Submit every viable candidate.

Deviate from the baseline only with empirical evidence that the reward cap binds materially in the solver’s auctions and that competitor-aware shading captures meaningful profit.