Solver rewards

The protocol is currently subsidizing the solver competition on all chains it operates on, by rewarding solvers on a weekly basis (currently, every Tuesday) with rewards paid in COW. Solvers are rewarded based on their performance and participation in the solver competition as specified by CIP-20, CIP-36, CIP-38, CIP-48, CIP-57, CIP-67, CIP-74, CIP-85, and CIP-XX. Solver rewards for participating in the price estimation competition and providing quotes that are needed for the gas estimates and limit price computations of market orders, which from now on we will call price estimation or quote rewards, are specified in CIP-27, CIP-36, CIP-57, and CIP-72.

note

For the interested reader, the main source of truth for the weekly payments to solvers is this Dune dashboard. The dashboard is populated with data aggregated by scripts within the solver-rewards repository.

Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74, 85, XX)

Performance rewards

Performance rewards are computed using a mechanism akin to a Vickrey–Clarke–Groves mechanism (a generalization of a second-price auction to combinatorial auctions). First, each solver proposes multiple solutions. Each solution contains a price vector and a list of trades to execute, which can be used to compute the solution's score. The protocol then selects the winning solutions (and winning solvers) using a fair combinatorial auction, which first filters out the solutions deemed unfair and then selects the combination of fair solutions that maximizes the total score of the auction (see here for more details).

note

From the protocol's perspective, a solution as executed onchain must equal the solution as submitted at the bidding stage.

The performance reward to the winning solver $i$ is

$$\textrm{performanceReward}_i = \textrm{cap}(\textrm{totalScore} - \textrm{referenceScore}_i-\textrm{missingScore}_i).$$

Here $\textrm{totalScore}$ is the sum of the scores of all winning solutions in the auction and $\textrm{missingScore}_i$ is the sum of the scores of solver $i$'s winning solutions that reverted. Finally, $\textrm{referenceScore}_i$ is the total score of a counterfactual auction in which all bids from solver $i$ are removed from the set of bids that survive the fairness filtering. If only one solver submits solutions, $\textrm{referenceScore}_i$ is, by definition, zero.

note

The performance reward calculation can result in a negative value, in which case the solver is required to pay the protocol.

The performance reward is capped from above and below using the function $\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$.

The upper cap $c_u$ is equal to a chain-specific fraction $\beta$ of the protocol fee (excluding partner fees) that the protocol earned from the trades in all solutions successfully executed on-chain by the solver in that auction. $\beta$ is determined by the following values:

• Ethereum mainnet, Arbitrum, Base chain, and BNB: $\beta = 50\%$
• Gnosis Chain, Avalanche, Polygon, Linea, Ink, and Plasma: $\beta = 100\%$

The parameter $\beta$, which naturally corresponds to a revenue-sharing parameter between protocol and solvers, is set to 50% by default. The core team has a mandate to change this parameter for individual networks, if needed, to a value in the interval [50%, 100%], given that the network has a total revenue less than 5% of the total protocol revenue.

The lower cap $c_l$ is determined by the orders that solver $i$ won but did not settle. Every order has a penalty cap associated with it in each auction, expressed in the native token of the chain, and

$$c_l = \sum_{o \,\in\, \textrm{unsettled}_i} \textrm{penaltyCap}_o,$$

where $\textrm{unsettled}_i$ is the set of orders that are part of one of solver $i$'s winning solutions in that auction and that solver $i$ did not settle on-chain within the auction deadline.

Penalty caps

The penalty cap of an order is a fraction of the order's quote, bounded by a global absolute cap:

$$\textrm{penaltyCap}_o = \min(\phi_o \cdot \textrm{quote}_o, \bar{c}).$$

Here $\textrm{quote}_o$ is the value of the quote of order $o$, expressed in the native token of the chain. The quote of an order is the buy amount with all volume fees deducted for sell orders, and the sell amount with all volume fees added for buy orders. The global bound $\bar{c}$ is the native token equivalent of 20 USD. For partially fillable orders, the penalty cap is scaled to the fraction of the order that the winning solution proposed to execute.

The fraction $\phi_o$ depends on the chain and on whether the two tokens traded by the order are correlated. The classification into correlated and uncorrelated token pairs follows the same logic that is used in determining the protocol volume fee. For correlated token pairs, $\phi_o = 0.1 \;\textrm{bps}$ on all chains. For uncorrelated token pairs, the values are:

• Ethereum mainnet: $4 \;\textrm{bps}$
• Gnosis Chain: $3 \;\textrm{bps}$
• Arbitrum: $1 \;\textrm{bps}$
• Base: $2 \;\textrm{bps}$
• Avalanche: $2 \;\textrm{bps}$
• Polygon: $3 \;\textrm{bps}$
• BNB: $1 \;\textrm{bps}$
• Linea: $2 \;\textrm{bps}$
• Ink: $1 \;\textrm{bps}$
• Plasma: $1 \;\textrm{bps}$

These caps are chosen such that solvers settle their winning solutions with a high probability, given estimates of price movements during the window of exclusivity, i.e., the time between the moment a solver is notified that it won and the deadline by which the auction has to be settled. The core team has a mandate to change the penalty cap per order within the interval [0 bps, 10 bps], if needed, to tune the trade-off between competitive prices and fast execution. Any change to the penalty cap is announced to solvers in advance and reflected in this documentation.

note

There is no guarantee that the per-auction rewards are greater than the costs of executing a transaction (due to, for example, gas costs). Hence, solvers cover these costs by adjusting their reported score. Of course, a solver who adjusts their score downward too aggressively is then at a disadvantage in the auction. The mechanism, therefore, incentivizes the accurate estimation of costs such as gas.

Consistency rewards

With CIP-85, the protocol introduced consistency rewards. These rewards are based on aggregate metrics evaluated over the full accounting week and are intended to incentivize consistent, reliable solver behavior, broad token coverage, and other aspects the core team considers important for maintaining healthy competition.

Concretely, in each auction, solver $i$'s contribution to the consistency budget is

$$\beta \cdot \textrm{protocolFee}_i - \textrm{performanceReward}_i,$$

where $\textrm{protocolFee}_i$ is the protocol fee (excluding partner fees) earned from the trades in all solutions successfully executed onchain by solver $i$ in that auction and $\beta$ is the chain-specific parameter defined above. When the performance reward is a penalty (i.e., negative), the penalty itself contributes to the consistency budget. The total consistency budget for an accounting period is the sum of these contributions across all solvers and auctions.

The consistency budget is distributed at the end of each accounting period according to a consistency metric: solver $i$ receives

$$\textrm{consistencyReward}_i = \frac{\textrm{consistencyMetric}_i}{\sum_{j} \textrm{consistencyMetric}_j} \cdot \textrm{consistencyBudget},$$

where the sum runs over all solvers. The core team has a mandate to adapt this metric when they see fit; every change will be announced in advance on the CoW Protocol forum.

Current metric: bid quality and settlement success. Since June 30, 2026, each solver's share of the consistency budget is proportional to a metric that combines the quality of the solver's bids with its settlement success rate, as announced in this forum post. It replaces an earlier metric that simply counted the executed orders a solver had bid on.

The metric has two components:

1. Bid quality. A solver bids on an order if it submits a solution containing that order. For each executed order, the solvers that bid on the order in the auction in which it was executed share a total weight of one, in proportion to the surplus they proposed. The share of solver $i$ for order $o$ is

$$\textrm{orderShare}_i(o) = \frac{\textrm{surplus}_i(o)}{\sum_{j} \textrm{surplus}_j(o)},$$

where $\textrm{surplus}_i(o)$ is the largest surplus that any of solver $i$'s solutions proposed for order $o$ in that auction (the difference between the proposed execution amounts and the order's limit amounts), and the sum runs over all solvers that bid on the order. If all bids on an order propose zero surplus, the share of every solver for that order is set to zero. We stress that only solutions that pass the fairness filtering are considered in the above computations. Since each executed order distributes a total weight of one, orders with few competitive bids yield a larger share for the solvers submitting them, an incentive for solvers to join such competitions with competitive bids.

2. Settlement success rate. The success rate of solver $i$ in an accounting period is

$$\textrm{successRate}_i = \frac{\textrm{count}(\textrm{auction-order pairs won and settled in time by } i)}{\textrm{count}(\textrm{auction-order pairs won by } i)}.$$

Both counts are at the level of auction-order pairs: solver $i$ wins an order in an auction if the order is part of one of solver $i$'s winning solutions in that auction. Each such pair counts once towards the denominator, and towards the numerator only if solver $i$ then settled the order onchain within that auction's deadline. In particular, winning the same order repeatedly without settling it lowers the success rate: a solver that wins an order in $n$ auctions but only settles it after the $n$-th win has a success rate of $1/n$ (all else being equal). A solver that does not win any order in the period has a success rate of zero.

The consistency metric of solver $i$ for an accounting period is the product

$$\textrm{consistencyMetric}_i = \textrm{successRate}_i \cdot \sum_{o} \textrm{orderShare}_i(o),$$

where the sum runs over all order executions in the period (an order that is executed in several auctions, e.g., a partially fillable order, counts once per execution).

For example, suppose four solvers bid on an order with proposed surplus of 0.1, 0.08, 0.019, and 0.001 ETH. The total proposed surplus is 0.2 ETH, so the order shares are 0.5, 0.4, 0.095, and 0.005, respectively. If the solvers have success rates of 0.8, 0.9, 1.0, and 0.5 in the accounting period, this order contributes 0.4, 0.36, 0.095, and 0.0025, respectively, to their consistency metrics.

note

The forum post defines bid quality in terms of surplus relative to the winning bid. Since the winning bid's surplus cancels out in the normalization, that definition is equivalent to the one given here.

Buffer accounting

It is possible that the state of the external liquidity sources used as part of a solution changes between the bidding stage and the execution stage. We say that there is negative slippage when the solver's execution generates less than the expected amount, and positive slippage otherwise. In case of negative slippage the solver can utilize the buffers available in the settlement contract, while a solver can accumulate positive slippage in the settlement contract. Every week, the protocol computes a "net" slippage and either pays a solver (when it is positive) or requests a payment from a solver (when it is negative). For more information, see the accounting section.

Hence, although buffers and the possibility of using them are not an explicit element of the mechanism, they are nonetheless relevant in determining the solver's optimal strategy, because they allow a solver to average out positive and negative slippage over a period of time (vs. making sure to always produce at least as much as promised at the bidding stage).

Solver's strategy

To determine the optimal routing, the recommended strategy for a solver is to start by dividing the available orders into groups of orders on the same directed token pairs - i.e., in each group, all orders have the same sell and buy tokens. The next step is to compute the best possible routing for each group and submit it as a solution. Note that, by construction, each of these solutions will use outside liquidity. Finally, a solver should check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. These additional efficiencies may come from, for example, exploiting liquidity already available on the protocol - using one order as liquidity for the other (in a CoW) or using surplus-capturing JIT liquidity - or from gas savings. Solvers should submit an additional solution for every combination of groups of orders for which additional efficiencies are possible. When submitting such a solution, they should pay attention to sharing the additional efficiencies among all orders in the batch; otherwise, the batched solution may be filtered out as unfair.

As already discussed, solvers are responsible for paying the gas cost of a solution. Also, if a solution is not settled in time, a solver may incur a penalty, bounded by the sum of the penalty caps of the orders it does not settle. Hence, when reporting their solution, solvers should adjust their reported score to account for the expected costs of settling a solution on the chain and the risk of not settling it in time.

With respect to optimal bidding, note that the protocol rewards allow a solver to participate in an auction without misreporting the score they can generate (net of expected costs). This is easy to see if the cap is not binding, and misreporting does not affect $\textrm{referenceScore}_i$. Then, by reducing the reported score of a solution, solver $i$ does not affect its payoff if this solution is among the winners (which only shifts from protocol rewards to positive slippage), while reducing the probability that this solution is a winner. It is therefore a dominant strategy to bid truthfully.

The presence of the cap on rewards $c_u$, however, makes the problem more complex as it introduces a "first-price auction" logic: if the difference between the best and second-best solution is very large, then the winning solver wins more when it underreports its score. The filtering step of the fair combinatorial auction also makes this problem more complex, because there are some edge cases in which by reducing the score of a solution, solver $i$ can benefit by making the filtering steps less stringent for its opponents (see here for a discussion). However, determining the optimal amount of underreporting is very complex and requires each solver to make strong assumptions regarding the performance of competing solvers.

To summarize, truthfully revealing the (cost-adjusted) score that a solver can generate for each submitted solution is optimal if the cap is not binding, and misreporting does not affect $\textrm{referenceScore}_i$. It is not necessarily optimal in uncompetitive auctions when the difference between the best and second-best solution may be large, and in some edge cases in which a solver may benefit from making the filtering step less stringent. However, in these cases, deriving the optimal strategy is a very complex problem.

Consistency rewards introduce an additional strategic dimension; since the consistency metric rewards competitive bids on executed orders, solvers have an incentive to participate broadly across auctions with bids close to the winning one, even in cases where they do not expect to win the performance reward. At the same time, since bid quality is discounted by the settlement success rate, solvers should only submit bids they are prepared to settle.

Price estimation competition rewards (CIPs 27, 36, 57, 72)

The price estimation competition is a separate competition where solvers provide the best response to a quote request. Quote requests look almost identical to single-order batch auctions, where there is only one order with a trivial limit price, and solvers propose executions of this order with the goal to maximize "out amount minus gas costs" in the case of a sell request, or minimize "in amount + gas costs" in the case of a buy request.

As specified in CIP-27, CIP-36 CIP-57, and CIP-72, a solver that provides the best quote to an order that is then submitted is rewarded if and only if all of the following conditions are satisfied:

1. The order is a fill-or-kill market order;
2. The quote is verified (i.e., its calldata successfully simulated in the autopilot);
3. The order was executed (not necessarily by the quoting solver);
4. The solver that provided the winning quote during order creation proposed an execution of the order (in at least one auction) that is at least as good as the quote, and that execution was not filtered out by the fairness filtering of the fair combinatorial auction mechanism.

The current rewards for eligible quotes are as follows:

• Ethereum mainnet: $\min\{0.0007 ~\textrm{ETH}, 6 ~\textrm{COW}\}$,
• Gnosis Chain: $\min\{0.15 ~\textrm{xDAI}, 6 ~\textrm{COW}\}$,
• Arbitrum: $\min\{0.00024 ~\textrm{ETH}, 6 ~\textrm{COW}\}$,
• Base Chain: $\min\{0.00024 ~\textrm{ETH}, 6 ~\textrm{COW}\}$,
• Avalanche-C Chain: $\min\{0.006 ~\textrm{AVAX}, 6 ~\textrm{COW}\}$,
• Polygon Chain: $\min\{0.6 ~\textrm{POL}, 6 ~\textrm{COW}\}$
• BNB Chain: $\min\{0.001 ~\textrm{BNB}, 6 ~\textrm{COW}\}$
• Linea: $\min\{0.00003 ~\textrm{ETH}, 6 ~\textrm{COW}\}$.
• Plasma: $\min\{0.6 ~\textrm{XPL}, 6 ~\textrm{COW}\}$.
• Ink: $\min\{0.00003 ~\textrm{ETH}, 6 ~\textrm{COW}\}$.

where, again, the conversion from native token to COW is done by using an up-to-date price (specifically, the average native token/COW Dune prices of the past 24h before the payout are used to determine these exchange rates).