CIP-Draft: Quote Competition Redesign

[arcsh7]

Quote Competition Redesign

CIP: Draft
title: Quote Competition Redesign
author: @felixhenneke, @arcsh7, @fleupold
status: Draft
created:  2026-09-09

Summary

This CIP replaces the flat reward paid to the winning quoter with a dedicated quote reward budget, expressed as a share of protocol revenue. If approved, it would mandate the core team to define and change the underlying mechanism that allocates that budget among solvers. This proposal only specifies how much funds to allocate for quote rewards, not the mechanism specifically .

Motivation

Quotes are the entry point to the protocol. A trader or partner compares it against other venues, and only then creates an order. If the protocol’s quote is not the best one, the order is not placed on CoW protocol and no revenue can be earned from it.

Despite that, the quote competition today is much weaker than the solve competition:

• Several of the solvers that do best in the solve competition barely quote at all, while some of the largest earners of quote rewards earn close to nothing in performance rewards.
  
  
• Solvers currently underbid in the quote competition: the price a solver quotes is - on average - worse than the price it goes on to bid for the same order. If every solver quoted as well as they bid in the auction, quotes could improve as much as ~4.8 bps volume-weighted. We are not showing this price improvement today.
  
  

Over the last three months, quote rewards were about 6% of total solver rewards, which is roughly 3% of protocol revenue at the current ratio of solver rewards to revenue. Per quote request that works out to roughly 0.02 cents. Our estimates for other aggregators are in the range of 0.02–0.05 cents per quote request. Note that those aggregators pay a single pricing engine to run. In CoW Protocol, a quote is a competition among all participating solvers, so keeping many of them participating requires a multiple of that figure rather than parity with it.

Currently, a quote reward is paid only if all four of the following conditions are met:

• the order is a fill-or-kill market order

• the quote was verified by simulation

• the order is created and executed, and

• the solver that provided the winning quote later proposed an execution at least as good as its quote.

All of these conditions make it so that today only 0.05% of all quotes and 21% of all quotes that converted into a trade are rewarded.

We believe that the last condition in particular incentivises solvers to underbid in the quote competition.
On top of that, only the best quote is paid, so a solver that is consistently second best gets nothing.
Given the importance that the quote competition has in attracting order flow and the increasing demand from non-exclusive B2B integrations in which we directly compete with other aggregators, we believe flexibility to experiment and refine the exact reward mechanism is at the essence. A budget keeps total spend tied to revenue as traffic grows, whatever the allocation rule turns out to be.

Specifications

Quote reward budget. Quote rewards are allocated from a dedicated budget targeting 10% of protocol revenue. The 10% target roughly triples the budget we have today (~3% of revenue). The intent is that better quotes win more order flow and that the additional revenue covers the increase.

This budget is separate from the performance and consistency reward budget set in CIP-85, which this CIP does not change.

Mandate. The core team has a mandate to define and change the mechanism that allocates the quote reward budget among solvers, with the goals of:

• maximising conversion and long-term protocol revenue, and

• making the quote competition as strong as the solve competition i.e, a solver that wins on price at quote time should generally be the solver that wins the auction.

[arcsh7]

Candidate mechanisms

We are not proposing to fix a mechanism here, but two families look promising.

• Weight by eventual accuracy. Instead of paying the highest quote, pay the most accurate ones. Once an order settles we know the achieved price, so for each solver that quoted it we can measure how far off it was, and split the reward across solvers in inverse proportion to that error.

  The intuition is that what we want to reward is not who states the highest number, but whose quote turns out to be right. It also makes over-quoting and under-quoting symmetrically costly, rather than over-quoting being disqualifying as it is today.

• Weight by quote quality times honoring rate.This is the quote-competition analogue of today’s consistency rewards: Concretely, a solver’s share of the reward for a quote request is its quote quality relative to the sum of all quote qualities, multiplied by the share of orders for which it went on to bid at least what it quoted.
  Mathematically, For a quote request with reward R and participating solvers i:

  reward_i = R × (Q_i / Σ_j Q_j) × h_i

  where Q_i is solver i’s quote quality, and h_i is the share of orders for which solver i went on to bid at least what it quoted.

  A simpler discrete variant of the same idea is a fixed split by rank (for example 60/30/10 across the top three quotes), again scaled by h_i. Here the rate has to be measured per rank: the 60% weight must be scaled by how often that solver honored its quote when it ranked first, not by its honoring rate across all of its quotes.
  The intuition is that the quality term rewards being competitive and the honoring term discourages quoting a price you cannot deliver, without making the reward conditional on conversion.

[tokenwood]

I’m glad to see this problem being addressed, Cowswap must be the only venue that currently encourages underquoting.

I like the idea of weight by eventual accuracy more than the weigh by quote quality, since keeping the term h_i still encourages underquoting. Maybe it is possible to reward a “quote vs bid accuracy” rather than a “bid>quote ratio” though, like for instance measuring how often a quote is < N bps from bid.

Are you planning on keeping the requirement to verify quotes? I’m not sure about other solvers, but Fractal does not include RFQ systems in quoting to not spam their apis requesting calldata for transactions that won’t happen. It would be possible to give non-verifiable orderbook based price estimation though. Also, in order to get a verified quote, solvers must return a contract call from the settlement contract. However I’d like to point out that it doesn’t work to match quote requests with cowswap limit orders. (it’s not a contract call, it’s a COW).

I don’t have a perfect solution but wanted to point out that accurately quoting can be in conflict with creating a verifiable quote.

[gabari]

Nexroute supports this proposal. Quotes are the entry point and the goal stated in the mandate, that the solver winning on price at quote time should generally be the one winning the auction, is the right one. Tying the budget to revenue and giving the team room to iterate on the mechanism both make sense.

One request: keep today’s flat reward as a guaranteed floor.

The draft says the 10% target roughly triples the budget, based on quote rewards being about 3% of protocol revenue. That 3% is a global average. Today’s reward is flat per eligible quote (min(0.001 native, 6 COW) on BNB), so it scales with quote count, not with revenue. Depending on how the budget is split across chains and across quote requests, “triple globally” can mean a cut locally. The solvers that quote the most on those chains would see their quote income drop on day one.

Concretely:

• A winning quote that meets today’s four conditions keeps earning at least today’s flat amount. The new mechanism distributes everything the budget adds on top.
• Globally the floor costs at most what is spent today, about a third of the new budget. So it does not limit the room to experiment.
• If a permanent floor is too rigid, the same guarantee for a fixed transition period (for example 6 months after the new mechanism goes live) would already help a lot.

It would also help to see current quote spend as a share of revenue per chain, so everyone can check what 10% means on each network.

Happy to share our BNB numbers if useful.

---

[arcsh7]

Thanks for the read. You’re right that increasing the global budget does not guarantee higher rewards on any particular chain or integration.

Today’s flat per-quote reward isn’t connected to what the rewarded flow earns: it scales with quote count, while revenue scales with volume and fee policy. In aggregate the two roughly track each other, and we believe quote rewards are underfunded overall.

But a flat reward becomes difficult to sustain for flows with many small trades, where revenue per trade is small, the reward per trade is fixed, and the reward becomes a large share of what that flow returns.

One example is a wallet on BNB in August: 32,971 trades, 12,968 of which qualified for a quote reward. Quote rewards on that flow worked out to roughly 25 cents per trade against 7.4 cents retained, approximately 3.4x what the flow returned.

Quote rewards ultimately need to be funded from protocol fees. A guaranteed floor would preserve this mismatch, and its cost could grow with traffic rather than revenue. That is why the proposal does not include a floor at the existing flat amount.

We think the budget should remain linked to protocol fees, while leaving room for the core team to adjust how it is allocated across chains and partners as the numbers change.

[gabari]

Thank you @arcsh7. I think the economics issue this proposal addresses is real, but given the impact it deserves a highlight.

Could you share the expected effect on the absolute quote reward per chain? For instance what August would have paid under this CIP vs what was actually paid.

[arcsh7]

Following the discussion, we simulated how the proposed quote budget could be allocated across 43,174 orders on Ethereum, BNB Chain and Base (1–7 September 2026), using an inverse-squared rule limited to the top five quotes. We tested several other allocation rules as well, and inverse-squared weighting rewarded accuracy most strongly of those we tried.

For this comparison, the budget is 10% of gross protocol fees, before partner payments, calculated separately for each chain.
Today the same flat reward costs 4.7% of protocol fees on Ethereum, 10.3% on Base and 31.2% on BNB Chain, 6.6 times the Ethereum share. Holding all three at 10% would take Ethereum’s budget to 2.11× today’s, keep Base’s close to where it is at 0.97×, and bring BNB Chain’s down to 0.32×. Linking the budget to fees ties it more accurately to what each chain’s orders earn.

Under the simulated rule, a solver’s share depends on how close its quotes land to the executed price on the orders it quotes, which is why some solvers with modest win rates gain share and some of today’s largest earners give it up.
The reward on each order stays concentrated: on average the most accurate quote receives 57.8% of that order’s budget on Ethereum, 59.7% on BNB Chain and 67.0% on Base, with the rest shared among the other quotes in the top five.

[gabari]

Thank you @arcsh7.

• Could you confirm: will the 10% cap per chain for quote rewards be on the gross protocol fee (before partner share) or the net protocol fee (after partner share)?

• Can we also generate the same data on our side, do you have a Github to share with us?
  It would be nice for anyone to run it, we would like to get the same stats on the week 15 to 22 of September, happy to do it ourselves if there is some code that we can run on our side.

[arcsh7]

• The budget is 10% of protocol revenue, as set out in the CIP, rather than a percentage of a particular fee line.
• We’ve uploaded the anonymised input data behind the simulations, covering Ethereum, BNB Chain and Base here. For every order in the windows, it includes each solver’s quote, the solve-competition bids, the executed trades and the fees, so the statistics can be recomputed directly using the formula mentioned here.