CIP-Draft: Align Solver Rewards with Protocol Revenue and introduce a volume based fee

Governance
,
1

This proposal is an evolution of CIP-Draft: Align Solver Rewards with Protocol Revenue

Simple Summary

CoW Protocol’s current second-price auction uses a fixed reward cap, which suppresses solver rewards on high-value batches and lets rewards exceed protocol fees on low-fee batches (especially on L2s). This CIP replaces the fixed cap with a dynamic cap tied to protocol fees generated by the winning solution, and introduces a very small unconditional volume fee of 2 bps (0.02%).

The goal of this CIP is to change the reward mechanism in a way that aligns incentives of solvers and the protocol to ensure economic viability even under adversarial or long tail order flow conditions.

Motivation

CoW Protocol currently uses a second-price auction mechanism for solver rewards, with a fixed reward cap. The winning solver’s reward is determined by the difference between their solution’s score and the next-best solution’s score (the “second-price”), and this reward is capped at an upper bound (for example, ~0.012 ETH on mainnet).

Since surplus and protocol fees tend to follow a fat-tailed distribution (few trades contribute most of the value) we observe cases in which the protocol profits significantly from fees (price improvement or surplus fees) while the upside of solvers that provided a very good solution are capped at a fairly low amount. On the other hand, we also observe a lot of batches (especially on L2s) in which the protocol doesn’t earn sufficient protocol fee to cover the solver rewards.

The goal of this CIP is to align incentives between the protocol and solvers to make sure that in auctions in which the protocol benefits a lot, solvers can also benefit a lot and conversely limit protocol exposure when fees are low.

To achieve this we propose to change the fixed (upper) reward cap with a dynamic one that is computed based on the total protocol fees a solver solution contributes. Assuming our current fee policies however, this change by itself would lead to a tremendous increase in auctions in which no reward is paid. We therefore also suggest adding an unconditional volume based protocol fee of 2bps.

Backtesting & Simulation

An interactive simulation based on past data (not taking into account possible change in user behavior) can be found here: https://dune.com/cowprotocol/reward-mechanism-experiments?volume_fee_bps_n0500b=2&start_time_d7df20=2025-09-01+00%3A00%3A00&end_time_d70df8=2025-10-01+00%3A00%3A00

Trade-offs & Market Impact

Under the new fee model both solvers as well as the protocol will be significantly more profitable. We expect an increase in the number of auctions in which the cap on rewards is binding, which however remains reasonable. We also expect a decrease in the volume settled in auctions in which the cap on rewards is binding. Overall, we believe that solvers can continue to participate in the competition by bidding truthfully, thus reducing complexity and reducing barriers to entry of new solvers..

While quantifying the exact execution quality across competing venues remains hard, recent independent research (https://arxiv.org/abs/2503.00738) suggests that CoW Protocol’s unique execution quality advantage will not be impaired by such a small volume based fee.

A markout comparison between 1Inch Fusion and CoW Protocol for September also shows a larger than 2bps execution advantage for CoW (​​https://dune.com/queries/6017103).

Moreover, a small unconditional fee will make some toxic flow (i.e. arbitrage bots) unprofitable, which allows market makers to further tighten their spreads and therefore likely lead to a smaller than 2bps impact on execution.

We acknowledge that this fee may cause a decline in total trading volume, but also highlight that this type of fee-sensitive volume is notoriously elastic and therefore not as valuable for the DAO nor solvers as compared to the increase in profitability.

Lastly the new model simplifies new network deployments, since the protocol no longer has to predict reasonable reward caps in advance.

Specification

https://github.com/cowprotocol/docs/commit/63b222e0324145fe7cf2dfd05bb8d89d70d9bbce

3 Likes
CIP-Draft: Align Solver Rewards with Protocol Revenue
2

Hi @fleupold,

Thank you for pushing this important proposal forward. I strongly support the core idea of aligning solver rewards with protocol revenue by moving away from a fixed cap to a dynamic one. This is a crucial step for the long-term economic sustainability of the protocol, and the problem statement is very clearly articulated.

My main concern, however, lies with the introduction of a rigid, universal 2 bps volume fee.

While I understand the need for an unconditional fee to ensure a reward baseline, a one-size-fits-all approach presents two significant problems:

  1. It might be too high for highly fee-sensitive pairs.

  2. It might be too low for less fee-sensitive, high-volume pairs.

1. The Issue with Fee-Sensitive Pairs (Stables & Mint/Redeem)

A 2 bps fee can be prohibitively expensive for certain use cases that have razor-thin margins.

  • Stablecoins & Like-Asset Pairs: Swaps like USDC/DAI or like-asset-pairs (e.g., cbETH/WETH) operate on extremely tight spreads, often supported by deep, specialized AMM pools. A 2 bps fee could make CoW Protocol uncompetitive for this significant flow, pushing users to other venues, consequently potentially making them to also migrate other trading activity.

  • Mint/Redeem Use Case: We have actively promoted CoW Protocol as an ideal back-end for mint/redeem functionality. This use case offers users simplicity and security, allowing them to, for example, mint a token by swapping it without interacting with the underlying contract directly. Our ability to guarantee the baseline contract price (or better) was a key factor in integrations like Sky Money. A 2bps fee may render this entire use case non-viable, undermining a powerful tool for user acquisition and business development.

2. The Missed Opportunity (Under-monetizing Volatile Pairs)

Conversely, for many high-volume, high-volatility pairs (e.g., ETH/PEPE, or even ETH/USDC), the market can easily sustain a fee much higher than 2 bps.

Uniswap’s tiered fee model (0.05%, 0.3%, 1%) exists precisely for this reason: liquidity providers capture more fees on volatile pairs where traders are less price-sensitive. By setting a rigid 2 bps fee, we are potentially leaving a significant amount of protocol revenue on the table for our most popular trading pairs.

A Hybrid Proposal: Low Default + Custom Tiers

I’d like to propose a hybrid model that addresses both issues, capturing the best of both worlds:

  1. Establish a very low default fee (e.g., 0.5 bps).

    • This fee would apply to all token pairs by default.

    • It’s low enough to protect our fee-sensitive volume (stables, mint/redeem) and remain competitive.

    • Crucially, it still provides the “unconditional baseline fee” needed to fund the dynamic solver reward mechanism, addressing the core problem this CIP is aiming to solve.

  2. Introduce a DAO-managed process for custom, higher fees on specific pairs.

    • The DAO could curate a list of high-volume pairs (e.g., the top 20-50 pairs) and set appropriate, higher fees (e.g., 2 bps, 5 bps, or more) based on their volatility and liquidity.

    • This allows CoW DAO to properly monetize the most valuable flow, aligning protocol revenue with market realities.

While this adds some complexity, I believe the “curation” overhead is manageable—we’d only need to focus on a small, contained list of pairs that drive the vast majority of volume.

This hybrid approach would allow us to protect our valuable, fee-sensitive use cases while significantly optimizing our monetization on mainstream pairs.

I believe this alternative structure has its own benefits and should be considered. Would love to see more discussion and hear thoughts on this tiered approach!

2 Likes
3

Thank you @middleway.eth for your comment and alternative proposal. The main motivation of this CIP is to align solver reward incentives with protocol economics. For this we propose to cap solver rewards by protocol fees.

Without a volume fee however, this would leave the majority of auctions without any rewards at all. We believe that solver rewards are a crucial part of CoW Protocol’s success and that the ecosystem isn’t yet ready to bootstrap competition without any rewards.

At a 0.5bps volume fee the simulation shows an increase in solver rewards only on mainnet whereas all other chains will effectively have less rewards (and significantly more auctions in which truthful bidding isn’t dominant anymore). I believe this value is too low to truly align incentives with solvers, but would love to also hear solvers comment on the parameter choice.

While I see your worry about potentially missed opportunities on volatile token pairs, I believe creating a sophisticated fee model per token pair requires effort and complexity that doesn’t easily go with the current focus of expanding to more networks (and reducing protocol complexity). I think this could be something that can be implemented at the UI not protocol level.

I understand your worry about integrations for likewise token pairs or mint/redeem cases. I want to highlight that 2bps is still significantly smaller than most other minimum fee tiers in DeFi and orders of magnitude smaller than other trading venues charge. Specifically mint/redeem cases usually require custom solver integrations and thus solver rewards incentives. I think the simplicity and security for the user needs to be worth a small fee and serious long term partners will likely want to charge a much higher partner fee than what is proposed here themselves.

4

Given the discussion around the correct fee amount and the lack of input otherwise, we suggest to move this CIP into voting with the following amendment tomorrow:

The Core Team is delegated authority to adjust the baseline volume-based protocol fee per token pair in the inclusive range of [0.00%, 0.05%]. The maximum total protocol fee per order (including all protocol fee policies, but excluding partner fees) shall be capped at 1%. To ensure accountability, the Core Team will maintain a registry of all fee exceptions with their justifications, report these changes regularly to the DAO, and remain subject to the DAO’s ultimate oversight and authority.

Also, the final docs wording will be [Draft] CiP to align solver and protocol incentives by fleupold · Pull Request #550 · cowprotocol/docs · GitHub

5

Thank you for the quick follow-up and especially for proposing the amendment.

This amendment is a great addition and directly addresses the core of my concern. The proposal to delegate authority to the Core Team to set per-token-pair fees within a 0-5 bps range is a good solution and gives us the exact flexibility I think is needed.

My primary point was never about a specific number (like 0.5 bps vs. 2 bps). To be honest, I don’t have a deep data analysis to definitively back one baseline over the other. My argument is simply that markets are not uniform. Applying any single, uniform fee will almost inevitably be suboptimal—we’d either be overcharging on fee-sensitive pairs and pushing them elsewhere, or undercharging on volatile pairs - either way leaving money on the table. This amendment opens a path to mitigate this issue with custom fee caps when needed.

For what it’s worth, I did play with the simulation tool. It was interesting to see that both 0.5 bps and 2 bps seem to turn the protocol from unprofitable to profitable (on the Base network for the tested period), which is great.

I also noticed both settings resulted in a high percentage of “missed rewards” and “untruthful auctions.” I have to admit I don’t fully understand all the simulation’s parameters, and I’d love to get more explanation on how to best interpret those metrics. I also recognize the simulation can’t fully model the “low baseline + custom high fees” hybrid I was suggesting, so it’s an incomplete picture.

With the new amendment, the debate over the initial baseline fee becomes much less critical, as we now have the tools to adjust it.

Given this new flexibility, I think it’s important that we establish a clear and transparent process for how these per-pair fees are managed. I’d like to strongly suggest we formalize this. As our approach develops, I think a good process would include:

  1. Public Discussion Period: A defined public notice-and-comment period before any fee change for a specific pair is implemented.

  2. Data-Driven Justification: A requirement to publish a supporting data analysis justifying why a fee change is warranted (e.g., market volatility, spread, competitive landscape).

  3. Community Proposal Path: A clear path for community members to formally propose a fee change (up or down) for a specific pair, complete with its own supporting data.

1 Like
6

Leaving my support on this initiative, even under the initial baseline.

I do support the flexibility on the mandate to ensure fine-tuning of the protocol revenue vs. attractiveness to integrators / partners. In my view, the most important aspect is aligning incentives along protocol participants (Users, Solvers and the DAO/tokenholders), and ensuring overall per network profitability. In the end, a more profitable product, can generate higher value and grow the cake to be distributed.

Agree with @middleway.eth that there should be a documented process on fee setting / changes, but do not think that should hinder the proposal moving to vote, as specifications will take their time to implement.

@middleway.eth , could you clarify your proposed #3? Are you suggesting an avenue for tokenholders to propose fee changes that the Core Team implements? Or that fee changes would require a full formal CIP process? (I agree with the first interpretation, and disagree with the second).

2 Likes
7

I am not suggesting that every fee change should require a full, formal CIP process. That would be far too slow and completely defeat the purpose of delegating this to the Core Team for agility.

My idea is exactly what you described: to have a clear, documented, and lightweight path for anyone in the community to submit a well-reasoned proposal to the Core Team (or a future dedicated committee) for consideration.

For example, a user could present a case with some data like, “The fee on pair X/Y is causing volume to leak to [competitor], here’s the data, please consider lowering it,” or “The volatility on pair A/B could easily support a 5bps fee, please consider raising it.”

The Core Team would then be expected to review and respond to these community-initiated proposals as part of their regular management of the fee registry. It’s just about ensuring the process is transparent and collaborative, not purely top-down.

And I completely agree with you—this is just a “process” discussion and definitely shouldn’t hinder the main proposal from moving to a vote. We can pass this CIP now and build out the specifics of this transparent process as we go.

1 Like
8

The CIP has been posted: https://snapshot.org/#/s:cow.eth/proposal/0x0c70c8cd92accee872b52614b4fa10e3e3214f45c5b6857f7e88e910607a3c1d

1 Like
9

Simulation on Base shows that solver rewards are roughly 2× lower with the new algorithm. Is CoW comfortable with this reduction?

:link: Dune Simulation – Reward Mechanism Experiments

Also, could you update the simulation to display at least one decimal place for floating‑point values? It’s currently difficult to see exactly how much reward our solver would lose because of this CIP.

10

Is CoW comfortable with this reduction?

I think specifically on Base we were observing the most toxic flow (stablecoins trading back and forth at a premium)

Also, could you update the simulation to display at least one decimal place for floating‑point values?

Done. Also feel free to fork the simulation and play with the query.

11

As I see from the simulations covering the period from September 1 to the end of October on both Base and Ethereum, CoW plans to take up to 65–70% of all user-paid fees, while only 30–35% are shared among solvers. In the long term, what fee distribution ratio does CoW aim for between the solvers and the protocol itself?

12

new_reward_fee_cap = min(scaling * new_protocol_fee, max(-lower_cap, uncapped_reward))

As this formula suggests, the upper cap of the reward is reduced or remains unchanged (for the majority of auctions), while the penalty cap stays the same. This means that in cases where the blockchain state changes significantly in a way that worsens conditions for the solver (making its bid impossible to execute without incurring a loss), the solver will have to execute the transaction more often.

Basically, this CIP makes the penalty/reward structure asymmetrical, which forces solvers to take fewer risks. They will likely execute only those orders that generate a sufficiently large protocol fee to cover potential losses due to blockchain state changes or unavoidable reverts that occur from time to time.

13

In the long term, what fee distribution ratio does CoW aim for between the solvers and the protocol itself?

I don’t think there is a fixed target. The mechanism is designed in a way that potentially 100% of rewards can go to solvers (it depends on the quality of the competition).

Basically, this CIP makes the penalty/reward structure asymmetrical, which forces solvers to take fewer risks.

I believe the penalty/reward structure is already asymmetrical. Assume you bid a score of 100, second best solver bids 99. Let’s say the cap is 10. If the winning solver lands the settlement they are rewarded 1, but if they revert they get penalized 10. So already today, the optimal strategy for solvers requires reducing the bid by the revert probability to ensure positive returns in expectation.

14

Why doesn’t the protocol simply make the protocol fees proportional to the solver reward? The fee could be calculated as the difference between the best solver’s score and the second-best solver’s score. Twice this value could then be set as the protocol fee for the user. I understand that this would require solvers to adjust transactions after the solve phase, but I think it’s doable. This approach would perfectly align CoW’s profit with the solvers’ profit.

I believe that, in its current state, this CIP should not be accepted as is. It worsens the incentives for the solvers.

1 Like
15

The fee could be calculated as the difference between the best solver’s score and the second-best solver’s score.

We studied a version of this where the winning solver gets told the second best score before settling and only has to achieve that second best score (ie they can reduce their bid by their execution advantage ex post).

However, this mechanism suffers from unfair surplus shifting in batched solutions. Take the following bids on orders o1, o2, o3 (where “-” means no bid):

  • solver 1: 2, 10, 5
  • solver 2: 1, -, -
  • solver 3: - 10, 6,9

In this example solver 2 and solver 3 win for a total score of 17.9 (vs. 17 of solver 1). However, now it’s not clear how the 0.9 score difference should be distributed amongst orders 1,2 and 3.

16

I don’t see how this issue fundamentally blocks CoW from making the solver reward and protocol fee proportional to each other.

Why not, in this particular case:

Protocol Fees

order1: 0
order2: 0
order3: 1.9

Rewards

solver1: 0
solver2: 0
solver3: 0.95 (effectively 50% of the protocol fees)

What I suggest is defining the protocol fee for each order as the difference between the surpluses of the best and second-best solutions for that particular order. Then, define the solver reward as a percentage of the protocol fee.

I believe the best way to achieve long-term protocol stability is to ensure that CoW directly shares the fees paid by users with solvers as a reward, without artificially capping or subsidizing it (as can happen now). This way, CoW can manage user fees in its own best interest — which will naturally align with the interests of solvers — for example, by introducing a volume fee once competition becomes tight enough and sharing part of these fees with the winning solver.

1 Like
17

Just to understand better: suppose there are two orders and two bids from two different solvers. One bid returns more to the first order and less to the second order relative to the other bid. For the sake of the argument say that the first bid has higher overall value and wins. How would you calculate protocol fees and rewards? And what do users get?

1 Like
18

Why not, in this particular case: protocol feed order1: 0, order2: 0, order3: 1.9

The outcome on chain will then be (1, 10, 5), which is strictly worse than the bid of solver 1 (2, 10, 5) meaning the protocol now enabled a suboptimal/unfair execution for the user.

19

image

The calculations are a bit complicated, so please help me understand this:

  1. Is it planned that, based on the formula on GitHub, the solver can earn the same as the protocol?
  2. If so, the protocol can’t take more than 50% minus 2bp from surplus, correct?
    Otherwise, the total payout to the protocol and the solver will be greater than what the user can receive as a benefit from using the protocol.
1 Like
20

The solver can earn more than the protocol (the protocol earns 0 if the cap is binding). At the same time, if the solver competition is strong the reward is still primarily defined by the difference in score to the second best solution (so it can be smaller than the protocol fees as well).

1 Like