CIP-Draft: Performance and Consistency Rewards

[felixhenneke]

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 the 50% of protocol revenue that is not spent on performance rewards in an accounting period becomes the budget for consistency reward. That budget is distributed to solvers prorated on a consistency metric.

The fraction protocol revenue is set to 50% by default. The core team has a mandate to change this fraction for individual networks to a values in the interval [50%, 100%], given that the network has a total revenue less than 5% of the revenue on mainnet.

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 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 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-02-24 on mainnet around 55% of rewards are spent on performance rewards. The remaining 45% are spent on consistency rewards.

Query and other networks

The data is based on this Dune query.

Mainnet:

Total Protocol Fee: 2095.706 ETH
New Reward Total: 1048.968 ETH
Perf Reward: 579.713 ETH (55.3%)
Consistency Reward: 469.255 ETH (44.7%)

Arbitrum:

Total Protocol Fee: 106.068 ETH
New Reward Total: 53.020ETH
Perf Reward: 34.305 ETH (64.7%)
Consistency Reward: 18.715 ETH (35.3%)

Base:

Total Protocol Fee: 136.013 ETH
New Reward Total: 68.021 ETH
Perf Reward: 56.563 ETH (16.8%)
Consistency Reward: 8.012 ETH (83.2%)

BNB:

Total Protocol Fee: 66.089 BNB
New Reward Total: 33.045 BNB
Perf Reward: 12.447 BNB (37.7%)
Consistency Reward: 20.597 BNB (62.3%)

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.

The mandate to increase the fraction of protocol fees spend on rewards will allow to have additional incentives for solvers to join new networks and networks with lacking solver support. As long is the total revue 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 revenue from mainnet, the default of 50% will be used.

Unsuccessful settlement can lead to negative rewards also called penalties. These penalties decrease performance rewards. With this proposal this decrease in performance rewards results in an increase of the budget for consistency rewards.

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.

The different approaches are implemented 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-02-24 would change as follows.

Query and other networksThe figure is based on this Dune query.

Arbitrum:

Base:

BNB:

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-02-24, the solver settling most small volume trades would have earned 25.3 ETH from settling such trades, while with the current mechanism they only earned 3.3 ETH (comparing with and without filtering).

[Update 2026-03-16: added link to Dune query with experiments, added link to PR to documentation

Update 2026-03-19: change consistency budget to increase from penalties (update text, figures, and queries accordingly); add clause on increasing budget on smaller networks]

[hihiben]

Thanks for putting together this comprehensive proposal. I have a few points I’d like to confirm and discuss.
–
The example in the specification illustrates that protocol revenue is effectively split 50/50 between the DAO and solvers, where any portion not claimed as performance reward flows into the consistency pool. To confirm my understanding, comparing to the scenario given

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.

in the scenario where uncapped payment exceeds the 50% cap:

If the uncapped reward is 0.02 ETH and the protocol revenue is 0.03 ETH, then the performance reward is capped at 0.015 ETH, 0.015 ETH goes to the DAO, and 0 ETH goes to the consistency pool.

Is this correct?
–
The mechanism described here applies to successfully settled auctions. When a solver wins but fails to settle (revert), the resulting penalty effectively becomes DAO revenue. This means the DAO’s actual share of protocol revenue is expected to be consistently above 50%, while the solver group’s share will be consistently below 50%. It may be worth explicitly noting this asymmetry in the specification.
–
An observation worth highlighting: the consistency pool is only funded by auctions where the performance reward is below 50% of protocol revenue, i.e., auctions with tighter competition between solvers. In auctions where one solver dominates (let’s say U/R), the surplus above the cap flows to the DAO, not to the consistency pool. This structure does effectively encourage solvers to compete more intensely and to submit more stable (rather than aggressive but high-risk) bids, since tighter competition is what generates the consistency budget in the first place.
–
The CIP’s motivation centers on encouraging broader coverage, across order sizes and asset types. However, all three proposed consistency metrics are solver-level aggregates that are agnostic to the type of orders being covered

• Orders Bid On: Bidding on 1,000 ETH/USDC orders scores the same as bidding on 1,000 long-tail token orders.

• Points-Based: Ranking top-4 on a mainstream pair scores the same as ranking top-4 on an underserved pair.

• Robust Surplus: Still inherently volume-weighted. Large orders contribute more surplus, so marginal contributions are dominated by mainstream pairs.

Under any of these metrics, a solver covering only high-volume mainstream pairs can score highly, while a solver uniquely covering long-tail assets may not be compensated for the performance reward they lose to the cap (since long-tail orders tend to have high U/R due to limited competition).
To better align the metric with the stated goal of “providing a consistent service across all trades,” I’d suggest incorporating a token coverage dimension into the metric at the same time. For example:

token_weight = 1 / num_solvers_covering_token
solver_score = Σ token_weight for each token the solver covered

This captures a solver’s contribution to asset diversity: covering tokens that few other solvers support yields a higher score than covering tokens already well-served by the competition. It also creates a self-balancing dynamic. As more solvers begin covering a previously underserved token, the weight naturally decreases. This approach directly incentivizes solvers to integrate new assets and new liquidity sources, working toward the goal of broad, consistent coverage without requiring anyone to manually define what counts as “long-tail.”

[harisang]

in the scenario where uncapped payment exceeds the 50% cap:

If the uncapped reward is 0.02 ETH and the protocol revenue is 0.03 ETH, then the performance reward is capped at 0.015 ETH, 0.015 ETH goes to the DAO, and 0 ETH goes to the consistency pool.

Is this correct?

Yes, this is correct.

The mechanism described here applies to successfully settled auctions. When a solver wins but fails to settle (revert), the resulting penalty effectively becomes DAO revenue. This means the DAO’s actual share of protocol revenue is expected to be consistently above 50%, while the solver group’s share will be consistently below 50%. It may be worth explicitly noting this asymmetry in the specification.

Good point. Penalties are not meant to be an explicit source of revenue, in my opinion, as they were set up to encourage solvers to do revert risk and not block the system by bogus overbidding. But, strictly speaking, this is income towards the DAO, so indeed when doing the accounting, the DAO’s income is the sum of protocol fees and penalties, while its spending is equal to the rewards given out.

I would add here, though, that the original intention of the CIP should probably not change, as otherwise I feel that this would lead to solvers being more sloppy in terms of risk management (as any revert would increase the consistency budget and very consistent but very sloppy solvers with a high number of reverts could mitigate their penalties just because they bid a lot and reclaim back part of the penalties as consistency rewards; haven’t thought this through much but at a first glance it seems risky to me).

An observation worth highlighting: the consistency pool is only funded by auctions where the performance reward is below 50% of protocol revenue, i.e., auctions with tighter competition between solvers. In auctions where one solver dominates (let’s say U/R), the surplus above the cap flows to the DAO, not to the consistency pool. This structure does effectively encourage solvers to compete more intensely and to submit more stable (rather than aggressive but high-risk) bids, since tighter competition is what generates the consistency budget in the first place.

Indeed, strong competition is what generates the consistency budget in the first place, and this is definitely intentional, as there have been several comments/concerns about the second-price auction leading to an exhausting race to zero. So, this in a way attempts to mitigate this.

Do you think the 50% is too harsh and could lead, as you seem to hint, to solvers trying to bid reasonably and “good-enough” but not necessary very competitively?

[hihiben]

On the penalty point, I agree this risk is worth thinking about, but it exists whether or not penalty revenue goes into the consistency pool.

A solver with a high revert rate but also a high bid count would:

• Pay penalty P to the DAO
• Earn consistency reward C from the pool
• If C > P, they’ve already offset their penalties

This is true regardless of where the pool’s funding comes from. The penalty per auction is capped at c_l (0.01 ETH on mainnet), which is tiny compared to the total consistency pool. The solver’s ability to offset penalties comes from their high consistency score, not from whether penalties flow into the pool. So keeping penalties out of the pool doesn’t fix this. It just shifts a small amount from the solver group to the DAO. To really address this, the consistency metric itself would need to consider failed settlements, which is a separate question from pool funding.

On whether 50% could push solvers toward “good-enough” bidding rather than strong competition, I’m not sure yet. I think the real question is how large consistency rewards become relative to performance rewards over time. It might help to see data on the per-auction distribution to understand how often the cap actually binds and how solver behavior might shift in response.

Also, going back to my earlier point on the consistency metric, I’d like to hear your thoughts on bringing token coverage into the design. All three proposed metrics treat every order the same, whether it’s ETH/USDC or a long-tail token that only one solver can route. If the goal is really about consistent service across all trades, the metric should reflect that. Is the team open to looking at something like the token coverage approach I described above? I understand that token-based metrics would need their own safeguards against wash trading, such as filtering out low-liquidity or suspicious tokens, and that would require additional mechanism design. But overall I believe this direction would be a positive step toward encouraging broader service availability across the protocol.

[felixhenneke]

@hihiben

A solver with a high revert rate but also a high bid count would:

• Pay penalty P to the DAO
• Earn consistency reward C from the pool
• If C > P, they’ve already offset their penalties

This is true regardless of where the pool’s funding comes from. The penalty per auction is capped at c_l (0.01 ETH on mainnet), which is tiny compared to the total consistency pool. The solver’s ability to offset penalties comes from their high consistency score, not from whether penalties flow into the pool. So keeping penalties out of the pool doesn’t fix this. It just shifts a small amount from the solver group to the DAO. To really address this, the consistency metric itself would need to consider failed settlements, which is a separate question from pool funding.

One observation here is that on some chains (e.g. Gnosis, Base, see this query) penalties have a significant effect, reducing payments under the new scheme from 50% to sometimes below 10%. So there is a real impact of the choice to include penalties into the budget or not including them.

My argument for not including them is roughly as follows: With our current mechanism solver should account for the risk of not settling in their bidding (and routing), see also this post. Now, if we include penalties into the consistency budget, the general mechanism does not change. Solvers should still include penalties into their bidding (and routing). It is just that (for the example consistency metrics) the penalty is effectively reduced by a solvers fraction of the consistency budget. E.g. if a solver receives 20% of the consistency budget, they effectively only pay 80% of the penalty.

This moderate reduction of penalties can also achieved with other means. Using consistency rewards for this would make the penalty mechanism even more complicated to understand than it is now.

@hihiben

Also, going back to my earlier point on the consistency metric, I’d like to hear your thoughts on bringing token coverage into the design. All three proposed metrics treat every order the same, whether it’s ETH/USDC or a long-tail token that only one solver can route. If the goal is really about consistent service across all trades, the metric should reflect that. Is the team open to looking at something like the token coverage approach I described above? I understand that token-based metrics would need their own safeguards against wash trading, such as filtering out low-liquidity or suspicious tokens, and that would require additional mechanism design. But overall I believe this direction would be a positive step toward encouraging broader service availability across the protocol.

We welcome this suggestion and are thinking about incorporating such ideas in the future. At the moment we are leaning towards proposing to use the simplest possible metric to be able to go live with consistency rewards as soon as possible. The mandate for changing the consistency rewards will then allow for improving the metric later.

On a technical level, it is true that just rewarding bids independent of the token pair does not strongly incentivize to support new tokens. Only looking at tokens traded would do that but lacks an incentive for support across multiple such orders or across order size. Maybe one could use the per-token weight in the definition of per-order scores.

[hihiben]

I take your point on the mechanical discount. But I think the underlying issue is that the DAO profits risk-free from solver execution failures. Solvers bear all the execution risk (gas costs, penalty, lost rewards), while the DAO simply collects penalty revenue on top of its guaranteed 50% share. This feels like a misaligned incentive.

The mechanical discount concern is valid, but it stems from reverted solutions still counting toward consistency scores, not from penalties flowing into the pool. These two things can be addressed separately:

• Let penalty revenue flow into the consistency pool
• Exclude reverted solutions from the consistency metric

This way, a solver who reverts still pays the full penalty AND loses consistency score (since their reverted solution doesn’t count). The disincentive against reverts is actually stronger than the current proposal, because reverts now cost the solver both a direct penalty and a reduced share of consistency rewards. Meanwhile, the solver group as a whole isn’t penalized for individual execution risk through lost pool funding.

[felixhenneke]

Thanks for being persistent here. After discussing this point internally I think that incorporating penalties into the consistency budget is an overall win.

The main reasons for this are as follows:

• The budget spent on rewards is actually stable at 50% of revenue across all chain. This makes this fraction a clear business decision and it does not need to be tuned with penalties in mind. Otherwise some L2s (e.g. Base) would have had significantly smaller payments.
• Some forms of unavoidable unsets (“unsuccessful settlements”) are handled a bit better when including penalties into consistency rewards. For example, if there were an externally given unset reason in 10% of auctions and consistency rewards were distributed according to auction wins, the penalty from such unavoidable unsets would not need to be taken into account when solvers take a cut from surplus to cover penalties. Instead, penalties from these unsets are reimbursed to solvers via consistency rewards. The incentive to prevent avoidable unsets remains, albeit being a bit weaker than at the moment.
• The DAO actively profiting from unsets is a strange misalignment of incentives.

Overall, these advantages seem stronger than the increase in complexity of the bidding due to changes in per-auction penalties.

I will update the CIP text (and queries and docs PR) accordingly.

@hihiben

Exclude reverted solutions from the consistency metric

Just as a clarification: Unsets are not being considered in any of the approaches we tried.

I will also add one additional clause to the CIP text which allows the core team to increase rewards on small L2s a bit more:

The core team asks for a mandate to change the fraction of revenue directed towards solvers on small networks to a value between 50% and 100%. This will allow for redirecting more revenue to solvers on chains where the solver competition is still lacking. One prime example would be new networks.

[hihiben]

Thanks for the discussion and taking the feedback on board. I understand the value of shipping a first version and iterating from there. Getting consistency rewards live first and refining the metric later with something like token coverage or something else is probably more practical for addressing the issues at hand.

Just to confirm the current direction: is the plan to move forward with Orders Bid On as the initial consistency metric, or are the other two approaches (points-based and marginal contribution to robust surplus) still being considered as well?