From c2410e0f380a03dc3fae52fbfacd3fe868e7b6f8 Mon Sep 17 00:00:00 2001 From: Felix Henneke Date: Mon, 10 Aug 2026 11:12:03 +0200 Subject: [PATCH 1/4] Document per-order penalty caps --- .../reference/core/auctions/rewards.md | 59 ++++++++++++++++--- 1 file changed, 50 insertions(+), 9 deletions(-) diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index 47a25680a..7ba3f9ebd 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -39,18 +39,57 @@ The performance reward calculation can result in a negative value, in which case ::: -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 fraction $$\beta$$ 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: +The performance reward is capped from above and below using the function $$\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$$. -- 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}$$ +The upper cap $$c_u$$ is equal to a chain-specific fraction $$\beta$$ 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. $$\beta$$ is determined by the following values: + +- Ethereum mainnet, Arbitrum, and Base chain: $$\beta = 50\%$$ +- Gnosis Chain, Avalanche, Polygon, BNB, Linea, Ink, and Plasma: $$\beta = 100\%$$ 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, if needed, to a value in the interval [50%, 100%], given that the network has a total revenue less than 5% of the total protocol revenue. +The lower cap $$c_l$$ is determined by the orders that solver $$i$$ won but did not settle. Every order has a penalty cap associated with it in each auction, expressed in the native token of the chain, and $$c_l$$ is the sum of the penalty caps of all orders in solver $$i$$'s winning solutions that were not executed in time, or not executed at all, + +$$ +c_l = \sum_{o \,\in\, \textrm{unsettled}_i} \textrm{penaltyCap}_o. +$$ + +In particular, a solver that settles all the orders it won within the auction deadline has $$c_l = 0$$, and its performance reward for that auction cannot be negative. + +#### Penalty caps + +The penalty cap of an order is a fraction of the order's quote, bounded by a global absolute cap: + +$$ +\textrm{penaltyCap}_o = \min(\phi_o \cdot \textrm{quote}_o, \bar{c}). +$$ + +Here $$\textrm{quote}_o$$ is the value of the quote of order $$o$$, expressed in the native token of the chain. The quote of an order is the buy amount with all volume fees deducted for sell orders, and the sell amount with all volume fees added for buy orders. The global bound $$\bar{c}$$ is the native token equivalent of 20 USD. For partially fillable orders, the penalty cap is scaled to the fraction of the order that the winning solution proposed to execute. + +The fraction $$\phi_o$$ depends on the chain and on whether the two tokens traded by the order are correlated. The classification into correlated and uncorrelated token pairs follows the same logic that is used in determining the [protocol volume fee](/governance/fees/fees). For correlated token pairs, $$\phi_o = 0.1 \;\textrm{bps}$$ on all chains. For uncorrelated token pairs, the values are: + +- Ethereum mainnet: $$4 \;\textrm{bps}$$ +- Gnosis Chain: $$3 \;\textrm{bps}$$ +- Arbitrum: $$1 \;\textrm{bps}$$ +- Base: $$2 \;\textrm{bps}$$ +- Avalanche: $$2 \;\textrm{bps}$$ +- Polygon: $$3 \;\textrm{bps}$$ +- BNB: $$1 \;\textrm{bps}$$ +- Linea: $$2 \;\textrm{bps}$$ +- Ink: $$1 \;\textrm{bps}$$ +- Plasma: $$1 \;\textrm{bps}$$ + +For example, consider an order selling 9 wstETH for wETH with a quote of 10 wETH. Since the token pair is correlated, the penalty cap of that order is 0.1 bps of the quote, i.e., 0.0001 ETH. If a solver wins three orders in an auction and settles only one of them, with the two unsettled orders having penalty caps of 0.001 ETH and 0.005 ETH, then $$c_l = 0.006 \;\textrm{ETH}$$: an uncapped performance reward of, say, $$-0.02\;\textrm{ETH}$$ results in a penalty of 0.006 ETH. + +These caps are chosen such that solvers settle their winning solutions with a high probability, given estimates of price movements during the window of exclusivity, i.e., the time between the moment a solver is notified that it won and the deadline by which the auction has to be settled. The core team has a mandate to change the penalty cap per order within the interval [0 bps, 10 bps], if needed, to tune the trade-off between competitive prices and fast execution. Any change to the penalty cap is announced to solvers in advance and reflected in this documentation. + + + +:::note + +Penalty caps per order replace the earlier chain-specific absolute penalty caps, as specified in [this CIP](https://forum.cow.fi/t/cip-draft-penalty-cap-redesign/3520). The change is not intended to change the total payment to solvers, which is fixed to a fraction of protocol revenue by the consistency rewards described below, but the implied solver behavior and the distribution of rewards between solvers. + +::: :::note @@ -125,7 +164,7 @@ Hence, although buffers and the possibility of using them are not an explicit el To determine the optimal routing, the recommended strategy for a solver is to start by dividing the available orders into groups of orders on the same directed token pairs - i.e., in each group, all orders have the same sell and buy tokens. The next step is to compute the best possible routing for each group and submit it as a solution. Note that, by construction, each of these solutions will use outside liquidity. Finally, a solver should check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. These additional efficiencies may come from, for example, exploiting liquidity already available on the protocol - using one order as liquidity for the other (in a CoW) or using [surplus-capturing JIT liquidity](/cow-protocol/reference/core/auctions/the-problem#surplus-capturing-jit-orders) - or from gas savings. Solvers should submit an additional solution for every combination of groups of orders for which additional efficiencies are possible. When submitting such a solution, they should pay attention to sharing the additional efficiencies among all orders in the batch; otherwise, the batched solution may be filtered out as unfair. -As already discussed, solvers are responsible for paying the gas cost of a solution. Also, if a solution reverts, a solver may incur a penalty. Hence, when reporting their solution, solvers should adjust their reported score to account for the expected costs of settling a solution on the chain and the revert risk. +As already discussed, solvers are responsible for paying the gas cost of a solution. Also, if a solution is not settled in time, a solver may incur a penalty, bounded by the sum of the penalty caps of the orders it does not settle. Hence, when reporting their solution, solvers should adjust their reported score to account for the expected costs of settling a solution on the chain and the revert risk. With respect to optimal bidding, note that the protocol rewards allow a solver to participate in an auction without misreporting the score they can generate (net of expected costs). This is easy to see if the cap is not binding, and misreporting does not affect $$\textrm{referenceScore}_i$$. Then, by reducing the reported score of a solution, solver $$i$$ does not affect its payoff if this solution is among the winners (which only shifts from protocol rewards to positive slippage), while reducing the probability that this solution is a winner. It is therefore a dominant strategy to bid truthfully. @@ -133,6 +172,8 @@ The presence of the cap on rewards $$c_u$$, however, makes the problem more comp 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. +The penalty cap $$c_l$$ also has to be taken into account for optimal bidding: since a solver only pays a penalty up to the caps of the orders it does not settle, the caps determine the price movement at which a solver prefers not to settle a winning solution, and hence how aggressively it can bid on an order (see [here](https://forum.cow.fi/t/how-penalties-affect-bidding-of-solvers/3341) for a discussion). + Consistency rewards introduce an additional strategic dimension; since the consistency metric rewards competitive bids on executed orders, solvers have an incentive to participate broadly across auctions with bids close to the winning one, even in cases where they do not expect to win the performance reward. At the same time, since bid quality is discounted by the settlement success rate, solvers should only submit bids they are prepared to settle. ## Price estimation competition rewards (CIPs 27, 36, 57, 72) From 244e6cb6cf316fb52620c7fdc1d140f4aa473501 Mon Sep 17 00:00:00 2001 From: Felix Henneke Date: Mon, 10 Aug 2026 12:22:20 +0200 Subject: [PATCH 2/4] Document per-order penalty caps --- .../reference/core/auctions/rewards.md | 22 ++++--------------- 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index 7ba3f9ebd..c0a17617a 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -5,7 +5,7 @@ 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 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-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff). 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). +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), [CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff), and CIP-XX. 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 @@ -13,7 +13,7 @@ For the interested reader, the main source of truth for the weekly payments to s ::: -## Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74, 85) +## Solver competition rewards (CIPs 20, 36, 38, 48, 57, 67, 74, 85, XX) ### Performance rewards @@ -43,8 +43,8 @@ The performance reward is capped from above and below using the function $$\text The upper cap $$c_u$$ is equal to a chain-specific fraction $$\beta$$ 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. $$\beta$$ is determined by the following values: -- Ethereum mainnet, Arbitrum, and Base chain: $$\beta = 50\%$$ -- Gnosis Chain, Avalanche, Polygon, BNB, Linea, Ink, and Plasma: $$\beta = 100\%$$ +- Ethereum mainnet, Arbitrum, Base chain, and BNB: $$\beta = 50\%$$ +- Gnosis Chain, Avalanche, Polygon, Linea, Ink, and Plasma: $$\beta = 100\%$$ 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, if needed, to a value in the interval [50%, 100%], given that the network has a total revenue less than 5% of the total protocol revenue. @@ -54,8 +54,6 @@ $$ c_l = \sum_{o \,\in\, \textrm{unsettled}_i} \textrm{penaltyCap}_o. $$ -In particular, a solver that settles all the orders it won within the auction deadline has $$c_l = 0$$, and its performance reward for that auction cannot be negative. - #### Penalty caps The penalty cap of an order is a fraction of the order's quote, bounded by a global absolute cap: @@ -79,18 +77,8 @@ The fraction $$\phi_o$$ depends on the chain and on whether the two tokens trade - Ink: $$1 \;\textrm{bps}$$ - Plasma: $$1 \;\textrm{bps}$$ -For example, consider an order selling 9 wstETH for wETH with a quote of 10 wETH. Since the token pair is correlated, the penalty cap of that order is 0.1 bps of the quote, i.e., 0.0001 ETH. If a solver wins three orders in an auction and settles only one of them, with the two unsettled orders having penalty caps of 0.001 ETH and 0.005 ETH, then $$c_l = 0.006 \;\textrm{ETH}$$: an uncapped performance reward of, say, $$-0.02\;\textrm{ETH}$$ results in a penalty of 0.006 ETH. - These caps are chosen such that solvers settle their winning solutions with a high probability, given estimates of price movements during the window of exclusivity, i.e., the time between the moment a solver is notified that it won and the deadline by which the auction has to be settled. The core team has a mandate to change the penalty cap per order within the interval [0 bps, 10 bps], if needed, to tune the trade-off between competitive prices and fast execution. Any change to the penalty cap is announced to solvers in advance and reflected in this documentation. - - -:::note - -Penalty caps per order replace the earlier chain-specific absolute penalty caps, as specified in [this CIP](https://forum.cow.fi/t/cip-draft-penalty-cap-redesign/3520). The change is not intended to change the total payment to solvers, which is fixed to a fraction of protocol revenue by the consistency rewards described below, but the implied solver behavior and the distribution of rewards between solvers. - -::: - :::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. @@ -172,8 +160,6 @@ The presence of the cap on rewards $$c_u$$, however, makes the problem more comp 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. -The penalty cap $$c_l$$ also has to be taken into account for optimal bidding: since a solver only pays a penalty up to the caps of the orders it does not settle, the caps determine the price movement at which a solver prefers not to settle a winning solution, and hence how aggressively it can bid on an order (see [here](https://forum.cow.fi/t/how-penalties-affect-bidding-of-solvers/3341) for a discussion). - Consistency rewards introduce an additional strategic dimension; since the consistency metric rewards competitive bids on executed orders, solvers have an incentive to participate broadly across auctions with bids close to the winning one, even in cases where they do not expect to win the performance reward. At the same time, since bid quality is discounted by the settlement success rate, solvers should only submit bids they are prepared to settle. ## Price estimation competition rewards (CIPs 27, 36, 57, 72) From df72f6295b7fbcc9903f9a5e2ab6eb29fba1ed28 Mon Sep 17 00:00:00 2001 From: Felix Henneke Date: Tue, 11 Aug 2026 11:01:26 +0200 Subject: [PATCH 3/4] Address review comments on penalty cap docs --- docs/cow-protocol/reference/core/auctions/rewards.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index c0a17617a..aa0b6dc9e 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -41,19 +41,21 @@ The performance reward calculation can result in a negative value, in which case The performance reward is capped from above and below using the function $$\textrm{cap}(x) = \max(-c_l, \min(c_u, x))$$. -The upper cap $$c_u$$ is equal to a chain-specific fraction $$\beta$$ 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. $$\beta$$ is determined by the following values: +The upper cap $$c_u$$ is equal to a chain-specific fraction $$\beta$$ of the protocol fee (excluding partner fees) that the protocol earned from the trades in all solutions successfully executed on-chain by the solver in that auction. $$\beta$$ is determined by the following values: - Ethereum mainnet, Arbitrum, Base chain, and BNB: $$\beta = 50\%$$ - Gnosis Chain, Avalanche, Polygon, Linea, Ink, and Plasma: $$\beta = 100\%$$ 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, if needed, to a value in the interval [50%, 100%], given that the network has a total revenue less than 5% of the total protocol revenue. -The lower cap $$c_l$$ is determined by the orders that solver $$i$$ won but did not settle. Every order has a penalty cap associated with it in each auction, expressed in the native token of the chain, and $$c_l$$ is the sum of the penalty caps of all orders in solver $$i$$'s winning solutions that were not executed in time, or not executed at all, +The lower cap $$c_l$$ is determined by the orders that solver $$i$$ won but did not settle. Every order has a penalty cap associated with it in each auction, expressed in the native token of the chain, and $$ -c_l = \sum_{o \,\in\, \textrm{unsettled}_i} \textrm{penaltyCap}_o. +c_l = \sum_{o \,\in\, \textrm{unsettled}_i} \textrm{penaltyCap}_o, $$ +where $$\textrm{unsettled}_i$$ is the set of orders that are part of one of solver $$i$$'s winning solutions in that auction and that solver $$i$$ did not settle on-chain within the auction deadline. + #### Penalty caps The penalty cap of an order is a fraction of the order's quote, bounded by a global absolute cap: @@ -152,7 +154,7 @@ Hence, although buffers and the possibility of using them are not an explicit el To determine the optimal routing, the recommended strategy for a solver is to start by dividing the available orders into groups of orders on the same directed token pairs - i.e., in each group, all orders have the same sell and buy tokens. The next step is to compute the best possible routing for each group and submit it as a solution. Note that, by construction, each of these solutions will use outside liquidity. Finally, a solver should check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. These additional efficiencies may come from, for example, exploiting liquidity already available on the protocol - using one order as liquidity for the other (in a CoW) or using [surplus-capturing JIT liquidity](/cow-protocol/reference/core/auctions/the-problem#surplus-capturing-jit-orders) - or from gas savings. Solvers should submit an additional solution for every combination of groups of orders for which additional efficiencies are possible. When submitting such a solution, they should pay attention to sharing the additional efficiencies among all orders in the batch; otherwise, the batched solution may be filtered out as unfair. -As already discussed, solvers are responsible for paying the gas cost of a solution. Also, if a solution is not settled in time, a solver may incur a penalty, bounded by the sum of the penalty caps of the orders it does not settle. Hence, when reporting their solution, solvers should adjust their reported score to account for the expected costs of settling a solution on the chain and the revert risk. +As already discussed, solvers are responsible for paying the gas cost of a solution. Also, if a solution is not settled in time, a solver may incur a penalty, bounded by the sum of the penalty caps of the orders it does not settle. Hence, when reporting their solution, solvers should adjust their reported score to account for the expected costs of settling a solution on the chain and the risk of not settling it in time. With respect to optimal bidding, note that the protocol rewards allow a solver to participate in an auction without misreporting the score they can generate (net of expected costs). This is easy to see if the cap is not binding, and misreporting does not affect $$\textrm{referenceScore}_i$$. Then, by reducing the reported score of a solution, solver $$i$$ does not affect its payoff if this solution is among the winners (which only shifts from protocol rewards to positive slippage), while reducing the probability that this solution is a winner. It is therefore a dominant strategy to bid truthfully. From 90ac7428ea9799cd233307ac78e5dc7366baddb2 Mon Sep 17 00:00:00 2001 From: Felix Henneke Date: Tue, 11 Aug 2026 11:32:05 +0200 Subject: [PATCH 4/4] Fix broken link to the fees page The volume fee link pointed at /governance/fees/fees, but Docusaurus treats fees/fees.md as the folder index, so the page is served at /governance/fees. With onBrokenLinks set to throw, this failed the build. Co-Authored-By: Claude Opus 5 --- docs/cow-protocol/reference/core/auctions/rewards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index aa0b6dc9e..c9cbc13a6 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -66,7 +66,7 @@ $$ Here $$\textrm{quote}_o$$ is the value of the quote of order $$o$$, expressed in the native token of the chain. The quote of an order is the buy amount with all volume fees deducted for sell orders, and the sell amount with all volume fees added for buy orders. The global bound $$\bar{c}$$ is the native token equivalent of 20 USD. For partially fillable orders, the penalty cap is scaled to the fraction of the order that the winning solution proposed to execute. -The fraction $$\phi_o$$ depends on the chain and on whether the two tokens traded by the order are correlated. The classification into correlated and uncorrelated token pairs follows the same logic that is used in determining the [protocol volume fee](/governance/fees/fees). For correlated token pairs, $$\phi_o = 0.1 \;\textrm{bps}$$ on all chains. For uncorrelated token pairs, the values are: +The fraction $$\phi_o$$ depends on the chain and on whether the two tokens traded by the order are correlated. The classification into correlated and uncorrelated token pairs follows the same logic that is used in determining the [protocol volume fee](/governance/fees). For correlated token pairs, $$\phi_o = 0.1 \;\textrm{bps}$$ on all chains. For uncorrelated token pairs, the values are: - Ethereum mainnet: $$4 \;\textrm{bps}$$ - Gnosis Chain: $$3 \;\textrm{bps}$$