CIP-Number: 85
title: Performance and Consistency Rewards
author: @felixhenneke, @harisang
status: active
created: 2026-02-26

Simple Summary

This CIP adapts the rewards mechanism to encourage solvers to provide a consistent service. This is realized by fixing the budget for rewards to a fixed percent of protocol revenue, where one part of this budget is spent on rewards in their current form, while the remaining part is distributed based on metrics related to consistent participation. The CIP also gives a mandate to the core team to experiment with different metrics for distributing rewards for consistency.

Motivation

The current reward mechanism, akin to a second-price auction, which we will refer to as performance rewards, is designed to encourage solvers to innovate on providing better prices to users. One thing performance rewards do not sufficiently encourage is providing a consistent service or broad coverage of token pairs and small volume buckets. For example, settling a trade with small volume is minimally (or no longer) profitable, as CIP-74 effectively removed cross-auction subsidies for orders which are difficult to monetize. This can result in solvers focusing on large orders and specializing on a niche. Coming second in the competition is also not tied to any reward, which shows that robustness through participation is not encouraged.

Since the goal of CoW Protocol is to be the settlement layer for all trades on Ethereum, we propose to explicitly reward solvers for providing a consistent service across all trades. For that, we will generate a budget for consistency rewards by reducing performance rewards. This budget will be distributed based on metrics measuring consistency of solvers.

A similar mechanism for consistency was introduced in CIP-20 and removed in CIP-48. One problem with the old implementation of the idea was that the budget was dependent on performance rewards not being above some absolute threshold and the metric for distribution was easy to manipulate. The first issue is addressed by explicitly allocating a certain fraction of protocol revenue to be distributed as rewards, the latter by giving the core team a mandate to experiment with different metrics for distribution.

Specification

The upper cap for performance rewards per solver in each auction is set to a default value of 50% of protocol revenue from protocol fees and protocol surplus share accumulated in all successful settlements the solver executed in that auction (down from 100%); a different percent can apply only in certain cases, as specified later in this section. Any amount of the 50% of protocol revenue that is not spent on performance rewards in an accounting period is added to the budget for consistency rewards.

In addition, the consistency rewards budget can grow due to penalties. As a reminder, unsuccessful settlements can lead to negative rewards, called penalties. As the protocol is not interested in gaining from these penalties (their primary intention is very different), we propose that the decrease in performance rewards due to penalties should result in an increase of the budget for consistency rewards, i.e., these penalties should be added back to the consistency rewards budget.

This budget now should be distributed to solvers prorated on a consistency metric.

As mentioned above, the fraction of protocol revenue contributing to the upper cap is set to 50% by default. The core team has a mandate to modify this parameter in the interval [50%, 100%] for individual networks, if needed, provided that the network’s total revenue is less than 5% of the protocol’s total revenue.

For example, with the default value of 50%, if the uncapped reward is 0.01 ETH and the protocol revenue is 0.03 ETH, then the performance reward is 0.01 ETH and 0.005 ETH is added to the consistency budget.

The initial consistency metric used will be the number of executed orders for which a solver proposed a solution in an accounting period. The core team has a mandate to adapt the consistency metric.

Every change to the consistency budget and metric will be announced in advance on the forum.

The specification can also be found here in the form of changes to the documentation.

Rationale

This CIP introduces a fixed rewards budget of 50% of protocol revenue (or more, for smaller networks). Previous CIPs often only defined fixed parameters which made it difficult to react to changing market conditions and solver landscape. This has led to periods where the success of the protocol, e.g., in terms of volume traded, did not benefit solvers, and phases where the success of the protocol mostly benefited solvers. Aligning incentives of solvers to incentives of the protocol is expected to lead to a more predictable and overall stronger solver competition.

The current cap of performance rewards of 100% of protocol revenue ensures economic viability of rewards. Since October 2025, the aggregate reward paid on mainnet amounted to around 45% to 70% of protocol revenue. On average, fixing the reward budget to be 50% of protocol revenue will result in similar amounts paid, with the exception of the last few weeks where rewards were elevated.

With this proposal, in the time range 2025-12-02 to 2026-02-24 on mainnet, of the 50% of protocol revenue, around 55% of it would be spent on performance rewards, and the remaining 45% would be spent on consistency rewards.

Setting the cap per auction to 50% of protocol revenue, the same fraction used for the aggregate budget, ensures that there will practically be no periods with vanishing consistency rewards. This will prevent ending up in a situation as before CIP-48 where elevated performance rewards meant that no consistency rewards were being distributed.

The mandate to increase the percent of protocol fees spent on rewards on certain networks will also allow to have additional incentives for solvers to join new networks and networks with lacking solver support. As long as the total revenue on a network is small, such an incentive can improve the quality of the solver competition in a cost effective way. As soon as the absolute amount of revenue on a network increases consistently to above 5% of the total protocol revenue, the default of 50% will be used.

We have tested several metrics for distributing rewards based on consistency. They differ in how easy they are to implement and in how resistant they are to manipulation.

• Number of executed orders a solver bids on: This is a natural generalization of consistency rewards from CIP-20 to combinatorial auctions. It is easy to compute and reason about. It is potentially easy to manipulate by submitting solutions not intended to be executed, by settling economically unviable trades, or wash trading.

• Point-based approach: A total of 12 points is distributed equally among the first 4 solvers for each executed order. Points are aggregated throughout an accounting period. This is similar to the number of orders bid on with the modification of rewarding better bids more.

• Marginal contribution to robust surplus, a surplus corrected by using participation rates in an accounting period: Define participation rates as the fraction of executed orders bid on compared to all executed orders. Given an executed order, suppose every solver who submitted a solution for that order had only submitted their solution with a probability given by the participation rate. The resulting expected value of the score for this order is called robust score of this order. The marginal increase to robust scores by a solver from submitting their bids is aggregated over an accounting period.

  This metric captures robustness via participation rates. It is similar to a second price auction in case solvers submit bids for every order. If solvers do not bid on every order, the second best and all other orders contribute to the robust score, naturally leading to rewards for solvers who did not win. This metric is more difficult to manipulate. Direct wash trading would still result in shifting the distribution but is simpler to detect than faulty bids which leave no trace from an execution.

The different approaches are implemented in this Dune query.

As mentioned already, we propose to start with the simplest metric, i.e., number of executed orders a solver bids on, to enable rapid deployment; the mandate allows the core team to upgrade to more robust metrics as data accumulates.