-
Notifications
You must be signed in to change notification settings - Fork 30
Update documentation for CIP on consistency rewards #603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 13 commits
942c686
f7b9807
19d1cae
b6b7ef8
ecbce4e
0131910
be2ecf6
960de8a
6abec8d
997f7e0
74d40dd
4a60710
9639a52
58ebf3b
bb945ad
cf3d5c1
a3f2110
4052a1c
e49ea8e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -5,56 +5,80 @@ sidebar_position: 3 | |||||
|
|
||||||
| # Solver rewards | ||||||
|
|
||||||
| The protocol is currently subsidizing the solver competition on all chains it operates on, by rewarding solvers on a weekly basis (currently, every Tuesday) with rewards paid in COW. Solvers are rewarded based on their performance as solvers (i.e., when participating in the standard solver competition) as specified by [CIP-20](https://snapshot.org/#/cow.eth/proposal/0x2d3f9bd1ea72dca84b03e97dda3efc1f4a42a772c54bd2037e8b62e7d09a491f), [CIP-36](https://snapshot.org/#/cow.eth/proposal/0x4e58f9c1208121c0e06282b5541b458bc8c8b76090263e25448848f3194df986), [CIP-38](https://snapshot.org/#/cow.eth/proposal/0xfb81daea9be89f4f1c251d53fd9d1481129b97c6f38caaddc42af7f3ce5a52ec), [CIP-48](https://snapshot.org/#/cow.eth/proposal/0x563ab9a66265ad72c47a8e55f620f927685dd07d4d49f6d1812905c683f05805) [CIP-57](https://snapshot.box/#/s:cow.eth/proposal/0x46d4fea1492207cf400fcb7a01141a7d4c730791d658cc77236941fc9eb7dccb), [CIP-67](https://snapshot.box/#/s:cow.eth/proposal/0xf9ecb08c4738f04c4525373d6b78085d16635f86adacd1b8ea77b2c176c99d32) and [CIP-74](https://snapshot.org/#/s:cow.eth/proposal/0x0c70c8cd92accee872b52614b4fa10e3e3214f45c5b6857f7e88e910607a3c1d). Solver rewards for participating in the price estimation competition and providing quotes that are needed for the gas estimates and limit price computations of market orders are specified in [CIP-27](https://snapshot.org/#/cow.eth/proposal/0x64e061568e86e8d2eec344d4a892e4126172b992cabe59a0b24c51c4c7e6cc33), [CIP-36](https://snapshot.org/#/cow.eth/proposal/0x4e58f9c1208121c0e06282b5541b458bc8c8b76090263e25448848f3194df986), [CIP-57](https://snapshot.box/#/s:cow.eth/proposal/0x46d4fea1492207cf400fcb7a01141a7d4c730791d658cc77236941fc9eb7dccb), and [CIP-72](https://snapshot.box/#/s:cow.eth/proposal/0xc1b1252f0c99126b4e09730022faa31a7bb58073a3dc064c19b74d44164c39a7). | ||||||
| The protocol is currently subsidizing the solver competition on all chains it operates on, by rewarding solvers on a weekly basis (currently, every Tuesday) with rewards paid in COW. Solvers are rewarded based on their performance and participation in the solver competition as specified by [CIP-20](https://snapshot.org/#/cow.eth/proposal/0x2d3f9bd1ea72dca84b03e97dda3efc1f4a42a772c54bd2037e8b62e7d09a491f), [CIP-36](https://snapshot.org/#/cow.eth/proposal/0x4e58f9c1208121c0e06282b5541b458bc8c8b76090263e25448848f3194df986), [CIP-38](https://snapshot.org/#/cow.eth/proposal/0xfb81daea9be89f4f1c251d53fd9d1481129b97c6f38caaddc42af7f3ce5a52ec), [CIP-48](https://snapshot.org/#/cow.eth/proposal/0x563ab9a66265ad72c47a8e55f620f927685dd07d4d49f6d1812905c683f05805), [CIP-57](https://snapshot.box/#/s:cow.eth/proposal/0x46d4fea1492207cf400fcb7a01141a7d4c730791d658cc77236941fc9eb7dccb), [CIP-67](https://snapshot.box/#/s:cow.eth/proposal/0xf9ecb08c4738f04c4525373d6b78085d16635f86adacd1b8ea77b2c176c99d32), [CIP-74](https://snapshot.org/#/s:cow.eth/proposal/0x0c70c8cd92accee872b52614b4fa10e3e3214f45c5b6857f7e88e910607a3c1d), and CIP-XX(add snapshot link). Solver rewards for participating in the price estimation competition and providing quotes that are needed for the gas estimates and limit price computations of market orders, which from now on we will call price estimation or quote rewards, are specified in [CIP-27](https://snapshot.org/#/cow.eth/proposal/0x64e061568e86e8d2eec344d4a892e4126172b992cabe59a0b24c51c4c7e6cc33), [CIP-36](https://snapshot.org/#/cow.eth/proposal/0x4e58f9c1208121c0e06282b5541b458bc8c8b76090263e25448848f3194df986), [CIP-57](https://snapshot.box/#/s:cow.eth/proposal/0x46d4fea1492207cf400fcb7a01141a7d4c730791d658cc77236941fc9eb7dccb), and [CIP-72](https://snapshot.box/#/s:cow.eth/proposal/0xc1b1252f0c99126b4e09730022faa31a7bb58073a3dc064c19b74d44164c39a7). | ||||||
|
|
||||||
| :::note | ||||||
|
|
||||||
| For the interested reader, the main source of truth for the weekly payments to solvers is this [Dune dashboard](https://dune.com/cowprotocol/cow-solver-rewards). The dashboard is populated with data aggregated by scripts within the [solver-rewards](https://github.com/cowprotocol/solver-rewards) repository. | ||||||
|
|
||||||
| ::: | ||||||
|
|
||||||
| ## Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74) | ||||||
| ## Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74, XX) | ||||||
|
|
||||||
| Solver rewards are computed using a mechanism akin to a Vickrey–Clarke–Groves mechanism (a generalization of a second-price auction to combinatorial auctions). First, each solver proposes multiple solutions. Each solution contains a price vector and a list of trades to execute, which can be used to compute the solution's score. The protocol then selects the winning solutions (and winning solvers) using a fair combinatorial auction, which first filters out the solutions deemed unfair and then selects the combination of fair solutions that maximizes the total score of the auction (see [here](competition-rules#off-chain-protocol) for more details). | ||||||
| ### Performance rewards | ||||||
|
|
||||||
| Performance rewards are computed using a mechanism akin to a Vickrey–Clarke–Groves mechanism (a generalization of a second-price auction to combinatorial auctions). First, each solver proposes multiple solutions. Each solution contains a price vector and a list of trades to execute, which can be used to compute the solution's score. The protocol then selects the winning solutions (and winning solvers) using a fair combinatorial auction, which first filters out the solutions deemed unfair and then selects the combination of fair solutions that maximizes the total score of the auction (see [here](competition-rules#off-chain-protocol) for more details). | ||||||
|
|
||||||
| :::note | ||||||
|
|
||||||
| From the protocol's perspective, a solution as executed on chain must equal the solution as submitted at the bidding stage. | ||||||
| From the protocol's perspective, a solution as executed onchain must equal the solution as submitted at the bidding stage. | ||||||
|
|
||||||
| ::: | ||||||
|
|
||||||
| The payment to the winning solver $$i$$ is | ||||||
| The performance reward to the winning solver $$i$$ is | ||||||
|
|
||||||
| $$ | ||||||
| \textrm{payment}_i = \textrm{cap}(\textrm{totalScore} - \textrm{referenceScore}_i-\textrm{missingScore}_i). | ||||||
| \textrm{performanceReward}_i = \textrm{cap}(\textrm{totalScore} - \textrm{referenceScore}_i-\textrm{missingScore}_i). | ||||||
| $$ | ||||||
|
|
||||||
| Here $$\textrm{totalScore}$$ is the sum of the scores of all winning solutions in the auction and $$\textrm{missingScore}_i$$ is the sum of the scores of solver $$i$$'s winning solutions that reverted. Finally, $$\textrm{referenceScore}_i$$ is the total score of a counterfactual auction in which all bids from solver $$i$$ are removed from the set of bids that survive the fairness filtering. | ||||||
| Here $$\textrm{totalScore}$$ is the sum of the scores of all winning solutions in the auction and $$\textrm{missingScore}_i$$ is the sum of the scores of solver $$i$$'s winning solutions that reverted. Finally, $$\textrm{referenceScore}_i$$ is the total score of a counterfactual auction in which all bids from solver $$i$$ are removed from the set of bids that survive the fairness filtering. If only one solver submits solutions, $$\textrm{referenceScore}_i$$ is, by definition, zero. | ||||||
|
|
||||||
| :::note | ||||||
|
|
||||||
| The payment calculation can result in a negative figure, in which case the solver is required to pay the protocol. | ||||||
| The performance reward calculation can result in a negative value, in which case the solver is required to pay the protocol. | ||||||
|
|
||||||
| ::: | ||||||
|
|
||||||
| The payment is capped from above and below using the function $$\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$$, where $$c_u$$ is the protocol fee (excluding partner fees) that the protocol earned from the trades in all solutions supplied by the solver in that auction and $$c_l$$ is chain-specific, determined by the following values: | ||||||
| The performance reward is capped from above and below using the function $$\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$$, where $$c_u$$ is equal to a chain-specific $$\beta$$ percent of the protocol fee (excluding partner fees) that the protocol earned from the trades in all solutions successfully executed onchain by the solver in that auction, and $$c_l$$ is chain-specific as well. $$\beta$$ and $$c_l$$ are determined by the following values: | ||||||
|
|
||||||
| - Ethereum mainnet, Arbitrum, and Base chain: $$\beta = 50\%$$, $$c_l = 0.010 \;\textrm{ETH}$$ | ||||||
| - Gnosis Chain: $$\beta = 100\%$$, $$10 \;\textrm{xDAI}$$ | ||||||
| - Avalanche: $$\beta = 100\%$$, $$0.3 \;\textrm{AVAX}$$ | ||||||
| - Polygon: $$\beta = 100\%$$, $$30 \;\textrm{POL}$$ | ||||||
| - BNB: $$\beta = 100\%$$, $$0.04 \;\textrm{BNB}$$ | ||||||
| - Linea and Ink: $$\beta = 100\%$$, $$0.0015 \;\textrm{ETH}$$ | ||||||
| - Plasma: $$\beta = 100\%$$, $$30 \;\textrm{XPL}$$ | ||||||
|
|
||||||
| - Ethereum mainnet, Arbitrum, and Base chain: $$0.010 \;\textrm{ETH}$$ | ||||||
| - Gnosis Chain: $$10 \;\textrm{xDAI}$$ | ||||||
| - Avalanche: $$0.3 \;\textrm{AVAX}$$ | ||||||
| - Polygon: $$30 \;\textrm{POL}$$ | ||||||
| - BNB: $$0.04 \;\textrm{BNB}$$ | ||||||
| - Linea and Ink: $$0.0015 \;\textrm{ETH}$$ | ||||||
| - Plasma: $$30 \;\textrm{XPL}$$ | ||||||
| The parameter $$\beta$$, which naturally corresponds to a revenue-sharing parameter between protocol and solvers, is set to 50% by default. The core team has a mandate to change this parameter for individual networks to a value in the interval [50%, 100%], given that the network has a total revenue less than 5% of the revenue on mainnet. | ||||||
|
harisang marked this conversation as resolved.
Outdated
|
||||||
|
|
||||||
| If only one solver submits solutions, $$\textrm{referenceScore}_i$$ is, by definition, zero. | ||||||
|
|
||||||
| :::note | ||||||
|
|
||||||
| There is no guarantee that the per-auction rewards are greater than the costs of executing a transaction (due to, for example, gas costs). Hence, solvers cover these costs by adjusting their reported score. Of course, a solver who adjusts their score downward too aggressively is then at a disadvantage in the auction. The mechanism, therefore, incentivizes the accurate estimation of costs such as gas. | ||||||
|
|
||||||
| ::: | ||||||
|
|
||||||
| ### Consistency rewards | ||||||
|
|
||||||
|
|
||||||
| With CIP-XX (add snapshot link), the protocol introduced consistency rewards. These rewards are based on aggregate metrics evaluated over the full accounting week and are intended to incentivize consistent, reliable solver behavior, broad token coverage, and other aspects the core team considers important for maintaining healthy competition. | ||||||
|
|
||||||
| Concretely, in each auction, solver $$i$$'s contribution to the consistency budget is | ||||||
|
|
||||||
| $$ | ||||||
| \frac{1}{2} \cdot \textrm{protocolFee}_i - \textrm{performanceReward}_i, | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The 1/2 should probably be replaced by the chain-specific parameter |
||||||
| $$ | ||||||
|
|
||||||
| where $$\textrm{protocolFee}_i$$ is the protocol fee (excluding partner fees) earned from the trades in all successfully executed onchain by solver $$i$$ in that auction. When the performance reward is a penalty (i.e., negative), the penalty itself contributes to the consistency budget. The total consistency budget for an accounting period is the sum of these contributions across all solvers and auctions. | ||||||
|
|
||||||
| The consistency budget is distributed at the end of each accounting period according to a consistency metric. The core team has a mandate to adapt this metric when they see fit; every change will be announced in advance on the [CoW Protocol forum](https://forum.cow.fi). | ||||||
|
|
||||||
| **Current metric: order count.** Each solver's share of the consistency budget is proportional to the number of executed orders for which it submitted a solution: | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will add a sentence on this restriction. |
||||||
|
|
||||||
| $$ | ||||||
| \textrm{consistencyReward}_i = \textrm{consistencyBudget} \times \frac{\textrm{orderCount}_i}{\sum_j \textrm{orderCount}_j}. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems a bit sloppy/not-very-precise, due to not well defined notation. We could skip it altogether, or try to define things properly
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it should be removed |
||||||
| $$ | ||||||
|
|
||||||
| ### Buffer accounting | ||||||
|
|
||||||
| It is possible that the state of the external liquidity sources used as part of a solution changes between the bidding stage and the execution stage. We say that there is negative slippage when the solver's execution generates less than the expected amount, and positive slippage otherwise. In case of negative slippage the solver can utilize the buffers available in the settlement contract, while a solver can accumulate positive slippage in the settlement contract. Every week, the protocol computes a "net" slippage and either pays a solver (when it is positive) or requests a payment from a solver (when it is negative). For more information, see the [accounting section](/cow-protocol/reference/core/auctions/accounting). | ||||||
|
|
@@ -71,7 +95,9 @@ With respect to optimal bidding, note that the protocol rewards allow a solver t | |||||
|
|
||||||
| The presence of the cap on rewards $$c_u$$, however, makes the problem more complex as it introduces a "first-price auction" logic: if the difference between the best and second-best solution is very large, then the winning solver wins more when it underreports its score. The filtering step of the fair combinatorial auction also makes this problem more complex, because there are some edge cases in which by reducing the score of a solution, solver $i$ can benefit by making the filtering steps less stringent for its opponents (see [here](https://forum.cow.fi/t/combinatorial-auctions-from-theory-to-practice-via-some-more-theory-about-rewards/2877) for a discussion). However, determining the optimal amount of underreporting is very complex and requires each solver to make strong assumptions regarding the performance of competing solvers. | ||||||
|
|
||||||
| To summarize, truthfully revealing the (cost-adjusted) score that a solver can generate for each submitted solution is optimal if the cap is not binding, and misreporting does not affect $$\textrm{referenceScore}_i$$. It is not necessarily optimal in uncompetitive auctions when the difference between the best and second-best solution may be large, and in some edge cases in which a solver may benefit from making the filtering step less stringent. However, in these cases, deriving the optimal strategy is a very complex problem. We conclude by noting that most CoW Protocol batches are very competitive - at the time of writing (November 2025) the cap on rewards is binding only in about 9% of auctions - and that a solver benefits by making the filtering steps less stringent for its opponents only in sporadic cases. | ||||||
| To summarize, truthfully revealing the (cost-adjusted) score that a solver can generate for each submitted solution is optimal if the cap is not binding, and misreporting does not affect $$\textrm{referenceScore}_i$$. It is not necessarily optimal in uncompetitive auctions when the difference between the best and second-best solution may be large, and in some edge cases in which a solver may benefit from making the filtering step less stringent. However, in these cases, deriving the optimal strategy is a very complex problem. | ||||||
|
|
||||||
| Consistency rewards introduce an additional strategic dimension; for example, the order-count metric rewards solvers for submitting solutions to auctions in which orders are ultimately executed, solvers have an incentive to participate broadly across auctions, even in cases where they do not expect to win the performance reward. | ||||||
|
|
||||||
| ## Price estimation competition rewards (CIPs 27, 36, 57, 72) | ||||||
|
harisang marked this conversation as resolved.
|
||||||
|
|
||||||
|
|
||||||
Uh oh!
There was an error while loading. Please reload this page.