Performance and Consistency Rewards
Simple Summary
This CIP adapts the reward mechanism to encourage solvers to provide a consistent service. This is realized by fixing the budget for rewards to 50% 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 call here 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 not at all) profitable anymore, 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 that comes 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 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 consistency rewards, the latter by giving the core team a mandate to experiment with different metrics for distribution.
Specification
The upper cap for performance rewards in each auction is set to 50% of protocol revenue from protocol fees and protocol surplus share (down from 100%). Any amount of this 50% of protocol revenue that is not spent on performance rewards adds to a budget for consistency reward. That budget is distributed to solvers prorated on a consistency metric.
For example, if the uncapped reward is 0.01ETH and the protocol revenue is 0.03ETH, then the performance reward is 0.01ETH and 0.005ETH is added to the consistency budget.
The initial consistency metric used will be the number of executed orders a solver proposed a solution for in an accounting period. The core team has a mandate to adapt the consistency metric.
Every change to the consistency metric will be announced in advance on the forum.
Rationale
This CIP introduces a fixed budget on rewards of 50% of protocol revenue. 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 benefitted 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.
Query and other networks
The figure is based on this Dune query.
Results for other networks are as follows
Arbitrum:
Base:
BNB:
With this proposal, in the time range 2025-12-02 to 2026-01-13 on mainnet around 64% of rewards are spent on performance rewards. The remaining 36% are spent on consistency rewards.
Data and other networks
Mainnet:
Total Protocol Fee: 799.247 ETH
New Reward Total: 399.624 ETH
Perf Reward: 254.109 ETH (63.6%)
Consistency Reward: 145.515 ETH (36.4%)
Base:
Total Protocol Fee: 48.126 ETH
New Reward Total: 24.063 ETH
Perf Reward: 16.051 ETH (66.7%)
Consistency Reward: 8.012 ETH (33.3%)
Arbitrum:
Total Protocol Fee: 30.101 ETH
New Reward Total: 15.051 ETH
Perf Reward: 9.737 ETH (64.7%)
Consistency Reward: 5.314 ETH (35.3%)
BNB:
Total Protocol Fee: 18.912 ETH
New Reward Total: 9.456 ETH
Perf Reward: 8.216 ETH (86.9%)
Consistency Reward: 1.240 ETH (13.1%)
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. It will prevent ending up in a situation as before CIP-48 where elevated performance rewards meant that no consistency rewards were being distributed.
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.
Example
Solvers A, B, and C have scores 10, 9, and 8, and participation rates 90%, 80%, and 95%, respectively. The robust score of the auction then is: (0.9 * 10) + ((1-0.9) * 0.8 * 9) + ((1-0.9) * (1-0.8) * 0.95 * 8 ) = 9.872. If solver A is removed, the robust score is: (0.8 * 9) + ((1-0.8) * 0.95 * 8 ) = 8.72, meaning that solver A’s marginal contribution to the robust score is ~1.15. Solvers B and C contribute ~0.11 and ~0.15.
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.
[Data on the differences between these approaches will be supplied later. The first two approaches can be tested in this Dune query.]
Given a distribution based on the number of orders bid on, the distribution of total rewards to solvers on mainnet in the time range 2025-12-02 – 2026-01-13 would change as follows.
Performance rewards are mostly spent on orders which are easy to monetize, e.g. large orders and orders between volatile tokens. This has led to solvers not profiting from settling trades with small volume. We can compare how much a solver profited from settling small orders by removing all solutions with small volume for a given solver and recomputing their rewards. In the time period 2025-12-02 to 2026-01-13, the solver settling most small volume trades would have earned 9.3ETH from settling such trades, while with the current mechanism they only earned 1.7ETH (comparing with and without filtering).