From bb33018de0b43c713697b204ea7bafa95dc7bb0e Mon Sep 17 00:00:00 2001 From: Architsharma7 <90101251+Architsharma7@users.noreply.github.com> Date: Tue, 25 Aug 2026 17:38:16 +0200 Subject: [PATCH 1/8] added optimal bidding strategy page to docs tutorials --- .../tutorials/solvers/optimal_bidding.md | 178 ++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 docs/cow-protocol/tutorials/solvers/optimal_bidding.md diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md new file mode 100644 index 000000000..856ed7e19 --- /dev/null +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -0,0 +1,178 @@ +--- +id: optimal-bidding +--- + +# Recommended Bidding Strategy for Solvers + +This guide describes a recommended _baseline_ bidding strategy for solvers in CoW Protocol’s combinatorial auction, that is, the bid each solver should submit by default for a given solution, optimal under the standard assumptions that a solver values its own solution truthfully and does not model competitor behaviour. It gives a per-solution baseline formula, the inputs required to compute it, and the cases where deviating from this baseline may be profitable but requires additional information or assumptions, which is what the later sections cover. + +The intended reader is someone running or planning to run a CoW Protocol solver who wants a self-contained operational reference. + +:::info +**TL;DR: How to bid?** + +For each solution a solver can settle, the recommended bid is a score equal to the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. The solver should also set a threshold on acceptable negative slippage so that a solution is settled only when its realised value remains non-negative, and should submit every solution it can profitably execute. +::: + +## Overview + +For each candidate solution $x$ the solver can submit, estimate the value it creates, the probability it settles successfully. Use the risk-adjusted score as the baseline bid. This is a dominant strategy in a simplified mechanism explained below and a recommended baseline in production. Deviations from the baseline require data about competitor scores, reward-cap binding, or fairness-filter effects. + +## The auction setting + +The protocol runs a **combinatorial auction**. In each auction, a solver can submit candidate **solutions**. A solution is a commitment to settle a specified set of orders together with a reported **score** $s$. A solution may cover: + +- A single directed token pair (handling all orders on that pair). +- Multiple directed token pairs (a batched solution, useful when coincidence-of-wants (CoWs) between pairs allow for peer-to-peer trading or when shared gas improves the routing). + +The protocol filters batched solutions for fairness, then picks the combination of solutions across pairs and solvers that maximises total reported score. + +An operationally important constraint is that winner selection cannot choose two solutions that touch the same directed token pair i.e, in each group, all orders have the same sell and buy tokens. A solver should also check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. If a solver wants to execute multiple orders on the same directed pair, those executions must be included in one combined solution. Multiple separate solutions on the same directed pair are not automatically aggregated by winner selection. + +For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e. the best outcome the protocol could have achieved without that solver. This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$). + +After winning, the solver is responsible for settling on chain. In the single-solution case, if the settlement does not land before the deadline, the settlement is **unset**: the solver pays the protocol $\min(\text{reference score}, c_l)$. With multiple winning solutions, partial settlement failures require the corresponding more general accounting. This is why solvers should adjust reported scores for the risk of an unset. + +This per-solution view provides a useful approximation for reasoning about how expected settlement risks should enter reported scores. + +## Score and value + +Let $x$ denote a candidate solution: the set of orders to be executed, their effective executed amounts, and the routing/liquidity sources used to execute them. + +There are two main ways to assign value to a solution. Conflating them is the most common source of confusion. + +- $S(x)$: the solver’s estimate of total score-relevant value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route). +- $s(x)$: the score reported to the protocol for solution $x$. + +The reported score induced by the solution $x$ is sum of three components: + +$$ +s(x) = (\text{user surplus}) + (\text{protocol fee}) + (\text{partner fee}) +$$ + +The user receives only the user surplus component. The remaining two are value generated by the trade that the protocol and any integrating partner collect. + +The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also instead transfer the amount to itself immediately in the settled token). The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring. + +## Recommended baseline bid + +For each candidate solution $x$ the solver can submit, estimate: + +- $S(x)$: net value the solution delivers +- $p(x)$: probability the settlement succeeds until auction deadline (does not become unset) +- $c_l$: lower penalty cap. + +The recommended baseline should account for both settlement risk and the fact that the solver's downside on an unset is capped. Use this as the baseline score: + +$$ +s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right) +$$ + +The two terms correspond to two regimes. + +When the penalty cap does not bind, settlement risk discounts the value of the execution directly: + +$$ +s_{\text{base}}(x) = p(x)\ S(x) +$$ + +A strategy is dominant if it is the best choice regardless of what other solvers submit. This is the dominant strategy in the simplified mechanism where the reward cap does not bind and fairness filtering is ignored, and it is a robust baseline in production. In this setting, that means the solver does not need to predict the reference score or model competitor behaviour to choose the baseline score. + +The intuition is that, in this regime, when the relevant caps do not bind and fairness filtering is ignored, changing the reported score only changes whether the solution wins. It does not change the solver’s payoff conditional on that solution winning: lowering the score may lose profitable wins, while raising it may win unprofitable ones. + +When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, the cap on the unset penalty lets the solver bid more aggressively: + +$$ +s_{\text{base}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) +$$ + +The recommended baseline is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score. + +## Worked example + +Consider a solver in an Ethereum mainnet auction ($c_l = 0.01$ ETH) who has computed three candidate solutions: + +- **Solution A**: WETH→USDC pair. $S(A) = 0.15$ ETH, $p(A) = 0.97$ +- **Solution B**: WBTC→USDC pair. $S(B) = 0.20$ ETH, $p(B) = 0.96$ +- **Solution C**: batched solution combining both pairs, internalising CoWs between sellers. $S(C) = 0.42$ ETH, $p(C) = 0.94$ + +Applying the penalty-cap-adjusted baseline: + +| Solution | $s_{\text{base}}$ (ETH) | +| -------- | ----------------------- | +| A | 0.1497 | +| B | 0.1996 | +| C | 0.4193 | + +The solver submits all three solutions. The protocol picks whichever combination maximises total score, subject to fairness filtering. If C survives the filter and its score beats other solvers’ contributions on the same pairs, the protocol picks C. If C is filtered out, A and B can still win their respective pairs. + +Submitting every viable candidate is generally the right move once the solver has already computed the corresponding routes: each submitted solution adds an option for the protocol. + +## Slippage and unsuccessful settlements + +Solvers can choose not to settle a selected solution, for example, if the desired routing would return significantly fewer tokens than expected. One way to implement this is to set a slippage tolerance $\gamma$: the maximum negative slippage the solver is willing to absorb between bidding and settlement. If on-chain slippage would exceeds $-\gamma$, the settlement does not happen. + +A conservative baseline per submitted solution: + +$$ +\gamma(x) = S(x)-s(x)+\min(c_l,s(x)) +$$ + +The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. Unsetting instead incurs the a penalty $min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. + +For small solutions where $s(x)\leq c_l$, this reduces to $\gamma(x)\approx S(x)$. For larger solutions, it becomes $\gamma(x)\approx S(x)-s(x)+c_l$, meaning the solver tolerates less negative slippage because the cost of unsetting is capped. + +## Fairness filtering + +A batched solution is excluded by the fairness filter if it under-delivers on any directed token pair relative to the per-pair reference outcome (constructed from the best individual-pair solutions across all solvers). + +Two operational implications: + +**Submit individual-pair fallbacks.** If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. A high-scoring batched solution that fails fairness is worth zero, the individual-pair fallbacks ensure the solver still wins the pairs it can. + +**Verify batched solutions pass the filter.** Compute the per-pair reference outcome from the best individual-pair solutions in the auction and check that the batched solution delivers at least that much on every directed pair it touches. + +Individual-vs-batch submission can also be strategic: strong individual-pair bids raise the fairness benchmark and can exclude competitors’ batched solutions, and vice versa. The baseline strategy in this guide does not rely on strategically changing scores to affect the fairness filter, and we do not recommend solvers use the fairness filter as a strategic target. Instead, solvers should compute honest individual-pair solutions, submit batched solutions only when they create additional value, and verify that those batched solutions pass the fairness filter. + +## Reward cap + +The upper reward cap $c_u$ makes the mechanism first-price-like when it binds. Beyond the cap, increasing the induced score no longer increases the solver’s protocol reward, but it can still reduce the value the solver retains. In that regime, shading the score downward can increase expected profit. Doing so safely, however, requires a model of competitor scores: shading too far increases the probability of losing the auction. + +Empirically on Ethereum mainnet ([Dune](https://dune.com/queries/7560960) query, ~2,000 auctions), the cap binds in about a third of winning batches, but the value at stake is usually small and concentrated in tail auctions: + +| Metric | Value | +| ---------------------------- | -------------------- | +| Auctions where cap binds | ~34.8% (510 / 1,464) | +| Median clipped, when binding | \~0.0002 ETH (\~$1) | +| p99 clipped, when binding | \~0.075 ETH (\~$300) | +| Max clipped, single auction | ~0.849 ETH | + +The baseline score remains the protocol's suggested starting point because it does not require predicting competitor behaviour. Solvers are free to use different scoring strategies, including reward-cap-aware shading, based on their own models of competition, execution risk, and expected payoff. + +## Consistency rewards + +[CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff) distributes a weekly consistency budget across solvers based on participation. Penalties paid on unsets feed this budget, so a solver receives back a fraction $\alpha$: their share of the budget at week-end, which is non-trivial to estimate. +The effective per-revert protocol cost is therefore $(1-\alpha)c_l$, not $c_l$. The baseline formula above ignores this. Solvers with a stable consistency share can refine the cap-binding term by replacing $c_l$ with $(1-\alpha)c_l$ which increases optimal bids when the penalty cap binds. The exact $\alpha$ depends on aggregate weekly metrics that themselves depend on other solvers' behaviour, so the refinement only pays off for solvers who can estimate their share reliably and hence is used as an heuristic. + +## Quote rewards + +If a solver won the quote competition for an order [CIP-72](https://snapshot.box/#/s:cow.eth/proposal/0xc1b1252f0c99126b4e09730022faa31a7bb58073a3dc064c19b74d44164c39a7), they must bid at least their quote $q$ in the auction to earn the quote reward. This adds a constraint $s \geq q$ on top of the baseline. + +This means quote rewards should be incorporated into the solver’s expected-value calculation rather than treated separately from bidding. If satisfying the quote-reward condition requires reporting a score above the baseline score, the solver should account for the additional probability of winning and the expected payoff of those extra wins. Whether this is profitable depends on the quote reward, the distribution of competing scores, and the solver’s settlement risk. + +The baseline score in this guide should therefore be read as the starting point before quote-reward incentives. Solvers participating in quote competition should incorporate the quote reward into their own expected-profit model. + +## Practical checklist + +For each candidate solution $x$: + +1. For each candidate solution $x$, estimate $S(x)$, $p(x)$. +2. Compute the baseline score $s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$ +3. Set the settlement slippage tolerance using $\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$ +4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome. +5. For multiple orders on the same directed pair, combine them into one solution. +6. Submit individual-pair fallbacks alongside batched solutions. +7. If quote rewards apply, incorporate the quote constraint and expected reward into the profit model. +8. Submit every viable candidate. + +Deviate from the baseline only with empirical evidence that the reward cap binds materially in the solver’s auctions and that competitor-aware shading captures meaningful profit. From 4648beca068749196f6bd321082c1b17a0f9d3cf Mon Sep 17 00:00:00 2001 From: Architsharma7 <90101251+Architsharma7@users.noreply.github.com> Date: Wed, 23 Sep 2026 17:38:27 +0530 Subject: [PATCH 2/8] added examples, fixed errors and updated rewards.md alongside --- .../reference/core/auctions/rewards.md | 12 +-- .../tutorials/solvers/optimal_bidding.md | 93 +++++++++++-------- 2 files changed, 55 insertions(+), 50 deletions(-) diff --git a/docs/cow-protocol/reference/core/auctions/rewards.md b/docs/cow-protocol/reference/core/auctions/rewards.md index 47a25680a..7f9e18db9 100644 --- a/docs/cow-protocol/reference/core/auctions/rewards.md +++ b/docs/cow-protocol/reference/core/auctions/rewards.md @@ -51,7 +51,6 @@ The performance reward is capped from above and below using the function $$\text 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. - :::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. @@ -60,7 +59,6 @@ There is no guarantee that the per-auction rewards are greater than the costs of ### Consistency rewards - With [CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff), 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 @@ -125,15 +123,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. - -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. - -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. - -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. +For optimal bidding, including how to account for gas costs, settlement risk and the penalty cap in the reported score, see [Recommended Bidding Strategy for Solvers](/cow-protocol/tutorials/solvers/optimal-bidding). ## Price estimation competition rewards (CIPs 27, 36, 57, 72) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 856ed7e19..142af468f 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -1,5 +1,6 @@ --- id: optimal-bidding +sidebar_position: 12 --- # Recommended Bidding Strategy for Solvers @@ -11,29 +12,29 @@ The intended reader is someone running or planning to run a CoW Protocol solver :::info **TL;DR: How to bid?** -For each solution a solver can settle, the recommended bid is a score equal to the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. The solver should also set a threshold on acceptable negative slippage so that a solution is settled only when its realised value remains non-negative, and should submit every solution it can profitably execute. +For each solution a solver can settle, the recommended bid is a score equal to the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. The solver should also set a threshold on acceptable negative slippage, so that a solution is settled unless the loss from slippage exceeds the cost of not settling, and should submit every solution with a positive baseline score. ::: ## Overview -For each candidate solution $x$ the solver can submit, estimate the value it creates, the probability it settles successfully. Use the risk-adjusted score as the baseline bid. This is a dominant strategy in a simplified mechanism explained below and a recommended baseline in production. Deviations from the baseline require data about competitor scores, reward-cap binding, or fairness-filter effects. +For each candidate solution $x$ the solver can submit, estimate the value it creates and the probability it settles successfully. Use the risk-adjusted score as the baseline bid. This is a dominant strategy in a simplified mechanism explained below and a recommended baseline in production. Deviations from the baseline require data about competitor scores, reward-cap binding, or fairness-filter effects. ## The auction setting -The protocol runs a **combinatorial auction**. In each auction, a solver can submit candidate **solutions**. A solution is a commitment to settle a specified set of orders together with a reported **score** $s$. A solution may cover: +The protocol runs a **combinatorial auction** (see [competition rules](/cow-protocol/reference/core/auctions/competition-rules#off-chain-protocol)). In each auction, a solver can submit candidate **solutions**. A solution is a commitment to settle a specified set of orders together with a reported **score** $s$. A solution may cover: - A single directed token pair (handling all orders on that pair). - Multiple directed token pairs (a batched solution, useful when coincidence-of-wants (CoWs) between pairs allow for peer-to-peer trading or when shared gas improves the routing). The protocol filters batched solutions for fairness, then picks the combination of solutions across pairs and solvers that maximises total reported score. -An operationally important constraint is that winner selection cannot choose two solutions that touch the same directed token pair i.e, in each group, all orders have the same sell and buy tokens. A solver should also check whether it is possible to improve these solutions by creating batched solutions containing orders on different directed token pairs. If a solver wants to execute multiple orders on the same directed pair, those executions must be included in one combined solution. Multiple separate solutions on the same directed pair are not automatically aggregated by winner selection. +An operationally important constraint is that winner selection cannot choose two solutions that touch the same directed token pair, i.e., the same sell and buy tokens. If a solver wants to execute multiple orders on the same directed pair, those executions must be included in one combined solution. Multiple separate solutions on the same directed pair are not automatically aggregated by winner selection. -For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e. the best outcome the protocol could have achieved without that solver. This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$). +For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e., the best outcome the protocol could have achieved without that solver. This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$) (see [rewards](/cow-protocol/reference/core/auctions/rewards#performance-rewards)). -After winning, the solver is responsible for settling on chain. In the single-solution case, if the settlement does not land before the deadline, the settlement is **unset**: the solver pays the protocol $\min(\text{reference score}, c_l)$. With multiple winning solutions, partial settlement failures require the corresponding more general accounting. This is why solvers should adjust reported scores for the risk of an unset. +After winning, the solver is responsible for settling on chain. If the solver is the only winner of the auction and the settlement does not land before the deadline, the settlement is **unset**: the solver pays the protocol $\min(\text{reference score}, c_l)$. With multiple winning solutions, partial settlement failures require the corresponding more general accounting. This is why solvers should adjust reported scores for the risk of an unset. -This per-solution view provides a useful approximation for reasoning about how expected settlement risks should enter reported scores. +This single-winner view provides a useful approximation for reasoning about how expected settlement risks should enter reported scores. ## Score and value @@ -44,7 +45,7 @@ There are two main ways to assign value to a solution. Conflating them is the mo - $S(x)$: the solver’s estimate of total score-relevant value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route). - $s(x)$: the score reported to the protocol for solution $x$. -The reported score induced by the solution $x$ is sum of three components: +The reported score induced by the solution $x$ is the sum of three components: $$ s(x) = (\text{user surplus}) + (\text{protocol fee}) + (\text{partner fee}) @@ -52,14 +53,27 @@ $$ The user receives only the user surplus component. The remaining two are value generated by the trade that the protocol and any integrating partner collect. -The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also instead transfer the amount to itself immediately in the settled token). The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring. +The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also transfer the amount to itself immediately in the settled token). The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring. + +**Example.** The user sells 10 ETH and asks for at least 17,000 USDC. The solver's router finds a route that returns 17,110 USDC for the 10 ETH, and settling costs 10 USDC in gas: + +| | USDC | +| ------------- | -------: | +| Route output | 17,110 | +| User's limit | − 17,000 | +| Gas | − 10 | +| **Value $S$** | **100** | + +The solver now decides how to share these 100 USDC. Part goes to the user as surplus, part pays the order's fees, and the rest stays with the solver. The first two parts make up the score. + +If the order pays 10 USDC in fees and the solver promises the user 60 USDC of surplus, the score is $s = 70$ and the solver keeps $S - s = 30$. ## Recommended baseline bid For each candidate solution $x$ the solver can submit, estimate: - $S(x)$: net value the solution delivers -- $p(x)$: probability the settlement succeeds until auction deadline (does not become unset) +- $p(x)$: probability the settlement succeeds before the auction deadline (does not become unset) - $c_l$: lower penalty cap. The recommended baseline should account for both settlement risk and the fact that the solver's downside on an unset is capped. Use this as the baseline score: @@ -80,7 +94,7 @@ A strategy is dominant if it is the best choice regardless of what other solvers The intuition is that, in this regime, when the relevant caps do not bind and fairness filtering is ignored, changing the reported score only changes whether the solution wins. It does not change the solver’s payoff conditional on that solution winning: lowering the score may lose profitable wins, while raising it may win unprofitable ones. -When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, the cap on the unset penalty lets the solver bid more aggressively: +When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, so the cap on the unset penalty lets the solver bid more aggressively: $$ s_{\text{base}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) @@ -90,23 +104,26 @@ The recommended baseline is therefore the larger of the uncapped risk-adjusted s ## Worked example -Consider a solver in an Ethereum mainnet auction ($c_l = 0.01$ ETH) who has computed three candidate solutions: +Continuing with the 10 ETH order, suppose the solver settles 90% of its wins in time ($p = 0.9$) and the order's penalty cap is $c_l = 45$ USDC. The penalty cap here is chosen large to make the effect visible; real penalty caps depend on the chain and the token pair (see [penalty caps](/cow-protocol/reference/core/auctions/rewards#penalty-caps)). -- **Solution A**: WETH→USDC pair. $S(A) = 0.15$ ETH, $p(A) = 0.97$ -- **Solution B**: WBTC→USDC pair. $S(B) = 0.20$ ETH, $p(B) = 0.96$ -- **Solution C**: batched solution combining both pairs, internalising CoWs between sellers. $S(C) = 0.42$ ETH, $p(C) = 0.94$ +| | USDC | +| --------------------------------------------------------------- | -----: | +| $p \cdot S = 0.9 \times 100$ | 90 | +| $S - \frac{1-p}{p} \cdot c_l = 100 - \frac{0.1}{0.9} \times 45$ | **95** | +| **Baseline bid $s_{\text{base}}$** | **95** | -Applying the penalty-cap-adjusted baseline: +The solver bids 95: it promises the user 85 USDC of surplus (95 minus 10 in fees) and keeps 5. -| Solution | $s_{\text{base}}$ (ETH) | -| -------- | ----------------------- | -| A | 0.1497 | -| B | 0.1996 | -| C | 0.4193 | +To see why 95 is right, compare it with bidding the full value (100) and with ignoring the penalty cap (90). The value of a win is $0.9 \cdot (100 - s_{\text{ref}}) - 0.1 \cdot \min(s_{\text{ref}}, 45)$: -The solver submits all three solutions. The protocol picks whichever combination maximises total score, subject to fairness filtering. If C survives the filter and its score beats other solvers’ contributions on the same pairs, the protocol picks C. If C is filtered out, A and B can still win their respective pairs. +| Competition $s_{\text{ref}}$ | Value of a win, without cap | Value of a win, with cap | Bid 100 | Bid 90 | Bid 95 | +| ---------------------------: | --------------------------: | -----------------------: | ---------- | -------- | ---------- | +| 85 | +5 | +9 | Wins, +9 | Wins, +9 | Wins, +9 | +| 93 | −3 | +1.8 | Wins, +1.8 | Loses, 0 | Wins, +1.8 | +| 97 | −7 | −1.8 | Wins, −1.8 | Loses, 0 | Loses, 0 | +| 105 | −15 | −9 | Loses, 0 | Loses, 0 | Loses, 0 | -Submitting every viable candidate is generally the right move once the solver has already computed the corresponding routes: each submitted solution adds an option for the protocol. +Bidding 100 wins an auction that loses money in expectation. Bidding 90 misses a profitable one. Bidding 95 takes every profitable win and skips every loss. ## Slippage and unsuccessful settlements @@ -118,7 +135,14 @@ $$ \gamma(x) = S(x)-s(x)+\min(c_l,s(x)) $$ -The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. Unsetting instead incurs the a penalty $min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. +The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. Unsetting instead incurs a penalty $min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. + +**Example.** Continuing the previous example, the solver won the 10 ETH order with a score of 95, keeping 5 USDC. Its tolerance is 100 − 95 + 45 = 50 USDC: the 5 USDC it kept, plus the 45 USDC penalty that settling avoids. + +| Negative slippage | If the solver settles | If it does not settle | Decision | +| ----------------: | --------------------: | --------------------: | ------------- | +| 30 | 5 − 30 = −25 | −45 | Settle | +| 70 | 5 − 70 = −65 | −45 | Do not settle | For small solutions where $s(x)\leq c_l$, this reduces to $\gamma(x)\approx S(x)$. For larger solutions, it becomes $\gamma(x)\approx S(x)-s(x)+c_l$, meaning the solver tolerates less negative slippage because the cost of unsetting is capped. @@ -128,11 +152,11 @@ A batched solution is excluded by the fairness filter if it under-delivers on an Two operational implications: -**Submit individual-pair fallbacks.** If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. A high-scoring batched solution that fails fairness is worth zero, the individual-pair fallbacks ensure the solver still wins the pairs it can. +**Submit individual-pair fallbacks.** If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. A high-scoring batched solution that fails fairness is worth zero. The individual-pair fallbacks ensure the solver still wins the pairs it can. **Verify batched solutions pass the filter.** Compute the per-pair reference outcome from the best individual-pair solutions in the auction and check that the batched solution delivers at least that much on every directed pair it touches. -Individual-vs-batch submission can also be strategic: strong individual-pair bids raise the fairness benchmark and can exclude competitors’ batched solutions, and vice versa. The baseline strategy in this guide does not rely on strategically changing scores to affect the fairness filter, and we do not recommend solvers use the fairness filter as a strategic target. Instead, solvers should compute honest individual-pair solutions, submit batched solutions only when they create additional value, and verify that those batched solutions pass the fairness filter. +Individual-vs-batch submission can also be strategic: strong individual-pair bids raise the fairness benchmark and can exclude competitors’ batched solutions, and vice versa. The baseline strategy in this guide does not rely on strategically changing scores to affect the fairness filter, and solvers are not advised to use the fairness filter as a strategic target. Instead, solvers should compute honest individual-pair solutions, submit batched solutions only when they create additional value, and verify that those batched solutions pass the fairness filter. ## Reward cap @@ -151,16 +175,8 @@ The baseline score remains the protocol's suggested starting point because it do ## Consistency rewards -[CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff) distributes a weekly consistency budget across solvers based on participation. Penalties paid on unsets feed this budget, so a solver receives back a fraction $\alpha$: their share of the budget at week-end, which is non-trivial to estimate. -The effective per-revert protocol cost is therefore $(1-\alpha)c_l$, not $c_l$. The baseline formula above ignores this. Solvers with a stable consistency share can refine the cap-binding term by replacing $c_l$ with $(1-\alpha)c_l$ which increases optimal bids when the penalty cap binds. The exact $\alpha$ depends on aggregate weekly metrics that themselves depend on other solvers' behaviour, so the refinement only pays off for solvers who can estimate their share reliably and hence is used as an heuristic. - -## Quote rewards - -If a solver won the quote competition for an order [CIP-72](https://snapshot.box/#/s:cow.eth/proposal/0xc1b1252f0c99126b4e09730022faa31a7bb58073a3dc064c19b74d44164c39a7), they must bid at least their quote $q$ in the auction to earn the quote reward. This adds a constraint $s \geq q$ on top of the baseline. - -This means quote rewards should be incorporated into the solver’s expected-value calculation rather than treated separately from bidding. If satisfying the quote-reward condition requires reporting a score above the baseline score, the solver should account for the additional probability of winning and the expected payoff of those extra wins. Whether this is profitable depends on the quote reward, the distribution of competing scores, and the solver’s settlement risk. - -The baseline score in this guide should therefore be read as the starting point before quote-reward incentives. Solvers participating in quote competition should incorporate the quote reward into their own expected-profit model. +[CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff) distributes a weekly consistency budget across solvers based on participation. Penalties paid on unsets feed this budget, so a solver receives back a fraction: their share of the budget at week-end. +The exact value of the share depends on aggregate weekly metrics that themselves depend on other solvers' behaviour. The baseline formula above ignores these effects. ## Practical checklist @@ -172,7 +188,6 @@ For each candidate solution $x$: 4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome. 5. For multiple orders on the same directed pair, combine them into one solution. 6. Submit individual-pair fallbacks alongside batched solutions. -7. If quote rewards apply, incorporate the quote constraint and expected reward into the profit model. -8. Submit every viable candidate. +7. Submit every viable candidate. -Deviate from the baseline only with empirical evidence that the reward cap binds materially in the solver’s auctions and that competitor-aware shading captures meaningful profit. +The reward cap, consistency rewards and quote rewards can also affect how profitable a bid is. Solvers are free to experiment with moving away from the baseline to account for them. From c9c370d457af35d95a4ecee4e30cc527b29a6827 Mon Sep 17 00:00:00 2001 From: Architsharma7 <90101251+Architsharma7@users.noreply.github.com> Date: Wed, 23 Sep 2026 18:00:12 +0530 Subject: [PATCH 3/8] fixed typo --- docs/cow-protocol/tutorials/solvers/optimal_bidding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 142af468f..06c972f7e 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -182,7 +182,7 @@ The exact value of the share depends on aggregate weekly metrics that themselves For each candidate solution $x$: -1. For each candidate solution $x$, estimate $S(x)$, $p(x)$. +1. Estimate $S(x)$, $p(x)$. 2. Compute the baseline score $s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$ 3. Set the settlement slippage tolerance using $\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$ 4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome. From 42d7a9ac1b593cba037e68fad39fcd19362d383e Mon Sep 17 00:00:00 2001 From: Archit Sharma <90101251+Architsharma7@users.noreply.github.com> Date: Thu, 24 Sep 2026 09:07:32 +0530 Subject: [PATCH 4/8] Update docs/cow-protocol/tutorials/solvers/optimal_bidding.md Co-authored-by: Felix Leupold <1200333+fleupold@users.noreply.github.com> --- docs/cow-protocol/tutorials/solvers/optimal_bidding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 06c972f7e..6526a5434 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -42,7 +42,7 @@ Let $x$ denote a candidate solution: the set of orders to be executed, their eff There are two main ways to assign value to a solution. Conflating them is the most common source of confusion. -- $S(x)$: the solver’s estimate of total score-relevant value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route). +- $S(x)$: the solver’s estimate of total value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route). - $s(x)$: the score reported to the protocol for solution $x$. The reported score induced by the solution $x$ is the sum of three components: From f413123495a02e8bb109a2bd92f71872f0dc3f0c Mon Sep 17 00:00:00 2001 From: Architsharma7 <90101251+Architsharma7@users.noreply.github.com> Date: Thu, 24 Sep 2026 09:27:18 +0530 Subject: [PATCH 5/8] updated docs - optimal bidding --- .../tutorials/solvers/optimal_bidding.md | 137 ++++++++++++------ 1 file changed, 92 insertions(+), 45 deletions(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 06c972f7e..2530b6094 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -5,42 +5,62 @@ sidebar_position: 12 # Recommended Bidding Strategy for Solvers -This guide describes a recommended _baseline_ bidding strategy for solvers in CoW Protocol’s combinatorial auction, that is, the bid each solver should submit by default for a given solution, optimal under the standard assumptions that a solver values its own solution truthfully and does not model competitor behaviour. It gives a per-solution baseline formula, the inputs required to compute it, and the cases where deviating from this baseline may be profitable but requires additional information or assumptions, which is what the later sections cover. +This guide describes a recommended bidding strategy for solvers in CoW Protocol’s combinatorial auction, that is, the bid each solver should submit by default for a given solution, optimal under the standard assumptions that a solver values its own solution truthfully and does not model competitor behaviour. +It gives a per-solution formula, the inputs required to compute it, and the cases where deviating from this recommendation may be profitable but requires additional information or assumptions, which is what the later sections cover. The intended reader is someone running or planning to run a CoW Protocol solver who wants a self-contained operational reference. :::info **TL;DR: How to bid?** -For each solution a solver can settle, the recommended bid is a score equal to the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. The solver should also set a threshold on acceptable negative slippage, so that a solution is settled unless the loss from slippage exceeds the cost of not settling, and should submit every solution with a positive baseline score. +For each solution $x$ a solver can settle, estimate its value $S(x)$ net of execution costs, the probability $p(x)$ that the settlement lands on chain before the deadline, and the penalty cap $c_l$ of its orders. +The recommended bid is then the score + +$$ +s_{\text{rec}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right) +$$ + +that is, the value the solution is expected to deliver, adjusted downward for the probability that the settlement does not land on chain. +The score should be neither inflated to win more auctions nor reduced to retain more value: under the standard mechanism, the reported score determines only whether the solution wins, not the solver's payoff conditional on winning. +After winning, a solution is settled only as long as the loss from slippage does not exceed the unset penalty. +The solver should submit every solution that creates positive value, i.e., $S(x) > 0$. ::: ## Overview -For each candidate solution $x$ the solver can submit, estimate the value it creates and the probability it settles successfully. Use the risk-adjusted score as the baseline bid. This is a dominant strategy in a simplified mechanism explained below and a recommended baseline in production. Deviations from the baseline require data about competitor scores, reward-cap binding, or fairness-filter effects. +For each candidate solution $x$ the solver can submit, estimate the value it creates and the probability it settles successfully. +Use the risk-adjusted score as the bid. +This is a dominant strategy in a simplified mechanism explained below and a robust starting point in production. +Deviations from it require data about competitor scores, reward-cap binding, or fairness-filter effects. ## The auction setting -The protocol runs a **combinatorial auction** (see [competition rules](/cow-protocol/reference/core/auctions/competition-rules#off-chain-protocol)). In each auction, a solver can submit candidate **solutions**. A solution is a commitment to settle a specified set of orders together with a reported **score** $s$. A solution may cover: +The protocol runs a **combinatorial auction** (see [competition rules](/cow-protocol/reference/core/auctions/competition-rules#off-chain-protocol)). +In each auction, a solver can submit candidate **solutions**. +A solution is a commitment to settle a specified set of orders together with a reported **score** $s$. +A solution may cover: - A single directed token pair (handling all orders on that pair). - Multiple directed token pairs (a batched solution, useful when coincidence-of-wants (CoWs) between pairs allow for peer-to-peer trading or when shared gas improves the routing). The protocol filters batched solutions for fairness, then picks the combination of solutions across pairs and solvers that maximises total reported score. -An operationally important constraint is that winner selection cannot choose two solutions that touch the same directed token pair, i.e., the same sell and buy tokens. If a solver wants to execute multiple orders on the same directed pair, those executions must be included in one combined solution. Multiple separate solutions on the same directed pair are not automatically aggregated by winner selection. - -For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e., the best outcome the protocol could have achieved without that solver. This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$) (see [rewards](/cow-protocol/reference/core/auctions/rewards#performance-rewards)). +For each winning solver, the protocol computes a performance reward by comparing the selected outcome with the reference outcome, i.e., the best outcome the protocol could have achieved without that solver. +This reward is bounded by the lower penalty cap ($c_l$) and the upper reward cap ($c_u$) (see [rewards](/cow-protocol/reference/core/auctions/rewards#performance-rewards)). -After winning, the solver is responsible for settling on chain. If the solver is the only winner of the auction and the settlement does not land before the deadline, the settlement is **unset**: the solver pays the protocol $\min(\text{reference score}, c_l)$. With multiple winning solutions, partial settlement failures require the corresponding more general accounting. This is why solvers should adjust reported scores for the risk of an unset. +After winning, the solver is responsible for settling on chain. +If the settlement does not land before the deadline, the settlement is **unset** and the solver pays the protocol a penalty of at most $c_l$. +This is why solvers should adjust reported scores for the risk of an unset. -This single-winner view provides a useful approximation for reasoning about how expected settlement risks should enter reported scores. +For simplicity, the rest of this guide assumes the solver is the only winner of the auction. +In that case, the penalty for an unset is $\min(\text{reference score}, c_l)$ (see the [performance reward formula](/cow-protocol/reference/core/auctions/rewards#performance-rewards) for the general case). ## Score and value Let $x$ denote a candidate solution: the set of orders to be executed, their effective executed amounts, and the routing/liquidity sources used to execute them. -There are two main ways to assign value to a solution. Conflating them is the most common source of confusion. +There are two main ways to assign value to a solution. +Conflating them is the most common source of confusion. - $S(x)$: the solver’s estimate of total score-relevant value created by solution $x$, net of execution costs (gas, AMM fees, slippage against liquidity sources used in the route). - $s(x)$: the score reported to the protocol for solution $x$. @@ -51,11 +71,14 @@ $$ s(x) = (\text{user surplus}) + (\text{protocol fee}) + (\text{partner fee}) $$ -The user receives only the user surplus component. The remaining two are value generated by the trade that the protocol and any integrating partner collect. +The user receives only the user surplus component. +The remaining two are value generated by the trade that the protocol and any integrating partner collect. -The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also transfer the amount to itself immediately in the settled token). The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring. +The solver retains the difference $S(x) - s(x)$, typically held as buffers in the settlement contract and reconciled weekly (a solver could also transfer the amount to itself immediately in the settled token). +The guidance below assumes scores correspond to actual economic value in the unit the protocol uses for scoring. -**Example.** The user sells 10 ETH and asks for at least 17,000 USDC. The solver's router finds a route that returns 17,110 USDC for the 10 ETH, and settling costs 10 USDC in gas: +**Example.** The user sells 10 ETH and asks for at least 17,000 USDC. +The solver's router finds a route that returns 17,110 USDC for the 10 ETH, and settling costs 10 USDC in gas: | | USDC | | ------------- | -------: | @@ -64,11 +87,13 @@ The solver retains the difference $S(x) - s(x)$, typically held as buffers in th | Gas | − 10 | | **Value $S$** | **100** | -The solver now decides how to share these 100 USDC. Part goes to the user as surplus, part pays the order's fees, and the rest stays with the solver. The first two parts make up the score. +The solver now decides how to share these 100 USDC. +Part goes to the user as surplus, part pays the order's fees, and the rest stays with the solver. +The first two parts make up the score. If the order pays 10 USDC in fees and the solver promises the user 60 USDC of surplus, the score is $s = 70$ and the solver keeps $S - s = 30$. -## Recommended baseline bid +## Recommended bid For each candidate solution $x$ the solver can submit, estimate: @@ -76,10 +101,11 @@ For each candidate solution $x$ the solver can submit, estimate: - $p(x)$: probability the settlement succeeds before the auction deadline (does not become unset) - $c_l$: lower penalty cap. -The recommended baseline should account for both settlement risk and the fact that the solver's downside on an unset is capped. Use this as the baseline score: +The recommended bid should account for both settlement risk and the fact that the solver's downside on an unset is capped. +Use this as the score: $$ -s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right) +s_{\text{rec}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right) $$ The two terms correspond to two regimes. @@ -87,34 +113,39 @@ The two terms correspond to two regimes. When the penalty cap does not bind, settlement risk discounts the value of the execution directly: $$ -s_{\text{base}}(x) = p(x)\ S(x) +s_{\text{rec}}(x) = p(x)\ S(x) $$ -A strategy is dominant if it is the best choice regardless of what other solvers submit. This is the dominant strategy in the simplified mechanism where the reward cap does not bind and fairness filtering is ignored, and it is a robust baseline in production. In this setting, that means the solver does not need to predict the reference score or model competitor behaviour to choose the baseline score. - -The intuition is that, in this regime, when the relevant caps do not bind and fairness filtering is ignored, changing the reported score only changes whether the solution wins. It does not change the solver’s payoff conditional on that solution winning: lowering the score may lose profitable wins, while raising it may win unprofitable ones. - When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, so the cap on the unset penalty lets the solver bid more aggressively: $$ -s_{\text{base}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) +s_{\text{rec}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) $$ -The recommended baseline is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score. +The recommended score is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score. + +A strategy is dominant if it is the best choice regardless of what other solvers submit. +This is the dominant strategy in the simplified mechanism (where the reward cap does not bind and fairness filtering is ignored) since the solver does not need to predict the reference score or model competitor behaviour to choose their score. + +The intuition is that, given the reward mechanism's second-price characteristics, changing the reported score only changes whether the solution wins. +It does not change the solver’s payoff. +Lowering the score may lose profitable wins, while raising it may win unprofitable ones. ## Worked example -Continuing with the 10 ETH order, suppose the solver settles 90% of its wins in time ($p = 0.9$) and the order's penalty cap is $c_l = 45$ USDC. The penalty cap here is chosen large to make the effect visible; real penalty caps depend on the chain and the token pair (see [penalty caps](/cow-protocol/reference/core/auctions/rewards#penalty-caps)). +Continuing with the 10 ETH order, suppose the solver settles 90% of its wins in time ($p = 0.9$) and the order's penalty cap is $c_l = 45$ USDC. +The penalty cap here is chosen large to make the effect visible; real penalty caps depend on the chain and the token pair (see [penalty caps](/cow-protocol/reference/core/auctions/rewards#penalty-caps)). | | USDC | | --------------------------------------------------------------- | -----: | | $p \cdot S = 0.9 \times 100$ | 90 | | $S - \frac{1-p}{p} \cdot c_l = 100 - \frac{0.1}{0.9} \times 45$ | **95** | -| **Baseline bid $s_{\text{base}}$** | **95** | +| **Recommended bid $s_{\text{rec}}$** | **95** | The solver bids 95: it promises the user 85 USDC of surplus (95 minus 10 in fees) and keeps 5. -To see why 95 is right, compare it with bidding the full value (100) and with ignoring the penalty cap (90). The value of a win is $0.9 \cdot (100 - s_{\text{ref}}) - 0.1 \cdot \min(s_{\text{ref}}, 45)$: +To see why 95 is right, compare it with bidding the full value (100) and with ignoring the penalty cap (90). +The value of a win is $0.9 \cdot (100 - s_{\text{ref}}) - 0.1 \cdot \min(s_{\text{ref}}, 45)$: | Competition $s_{\text{ref}}$ | Value of a win, without cap | Value of a win, with cap | Bid 100 | Bid 90 | Bid 95 | | ---------------------------: | --------------------------: | -----------------------: | ---------- | -------- | ---------- | @@ -123,28 +154,38 @@ To see why 95 is right, compare it with bidding the full value (100) and with ig | 97 | −7 | −1.8 | Wins, −1.8 | Loses, 0 | Loses, 0 | | 105 | −15 | −9 | Loses, 0 | Loses, 0 | Loses, 0 | -Bidding 100 wins an auction that loses money in expectation. Bidding 90 misses a profitable one. Bidding 95 takes every profitable win and skips every loss. +Bidding 100 wins an auction that loses money in expectation. +Bidding 90 misses a profitable one. +Bidding 95 takes every profitable win and skips every loss. ## Slippage and unsuccessful settlements -Solvers can choose not to settle a selected solution, for example, if the desired routing would return significantly fewer tokens than expected. One way to implement this is to set a slippage tolerance $\gamma$: the maximum negative slippage the solver is willing to absorb between bidding and settlement. If on-chain slippage would exceeds $-\gamma$, the settlement does not happen. +Solvers can choose not to settle a selected solution, for example, if the desired routing would return significantly fewer tokens than expected. +One way to implement this is to set a slippage tolerance $\gamma$: the maximum negative slippage the solver is willing to absorb between bidding and settlement. +If negative slippage would exceed $\gamma$, the settlement does not happen. -A conservative baseline per submitted solution: +A conservative tolerance per submitted solution: $$ \gamma(x) = S(x)-s(x)+\min(c_l,s(x)) $$ -The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. Unsetting instead incurs a penalty $min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. +The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. +Settling yields approximately $S(x)−s(x)− \gamma$. +Unsetting instead incurs a penalty $min(s(x),c_l)$. +The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. -**Example.** Continuing the previous example, the solver won the 10 ETH order with a score of 95, keeping 5 USDC. Its tolerance is 100 − 95 + 45 = 50 USDC: the 5 USDC it kept, plus the 45 USDC penalty that settling avoids. +**Example.** Continuing the previous example, the solver won the 10 ETH order with a score of 95, keeping 5 USDC. +Its tolerance is 100 − 95 + 45 = 50 USDC: the 5 USDC it kept, plus the 45 USDC penalty that settling avoids. | Negative slippage | If the solver settles | If it does not settle | Decision | | ----------------: | --------------------: | --------------------: | ------------- | | 30 | 5 − 30 = −25 | −45 | Settle | +| 50 | 5 − 50 = −45 | −45 | Indifferent | | 70 | 5 − 70 = −65 | −45 | Do not settle | -For small solutions where $s(x)\leq c_l$, this reduces to $\gamma(x)\approx S(x)$. For larger solutions, it becomes $\gamma(x)\approx S(x)-s(x)+c_l$, meaning the solver tolerates less negative slippage because the cost of unsetting is capped. +For small solutions where $s(x)\leq c_l$, this reduces to $\gamma(x)\approx S(x)$. +For larger solutions, it becomes $\gamma(x)\approx S(x)-s(x)+c_l$, meaning the solver tolerates less negative slippage because the cost of unsetting is capped. ## Fairness filtering @@ -152,15 +193,18 @@ A batched solution is excluded by the fairness filter if it under-delivers on an Two operational implications: -**Submit individual-pair fallbacks.** If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. A high-scoring batched solution that fails fairness is worth zero. The individual-pair fallbacks ensure the solver still wins the pairs it can. +**Submit individual-pair fallbacks.** If a solver has a batched solution covering multiple pairs, also submit the underlying individual-pair solutions. +A high-scoring batched solution that fails fairness is worth zero. +The individual-pair fallbacks ensure the solver still wins the pairs it can. **Verify batched solutions pass the filter.** Compute the per-pair reference outcome from the best individual-pair solutions in the auction and check that the batched solution delivers at least that much on every directed pair it touches. -Individual-vs-batch submission can also be strategic: strong individual-pair bids raise the fairness benchmark and can exclude competitors’ batched solutions, and vice versa. The baseline strategy in this guide does not rely on strategically changing scores to affect the fairness filter, and solvers are not advised to use the fairness filter as a strategic target. Instead, solvers should compute honest individual-pair solutions, submit batched solutions only when they create additional value, and verify that those batched solutions pass the fairness filter. - ## Reward cap -The upper reward cap $c_u$ makes the mechanism first-price-like when it binds. Beyond the cap, increasing the induced score no longer increases the solver’s protocol reward, but it can still reduce the value the solver retains. In that regime, shading the score downward can increase expected profit. Doing so safely, however, requires a model of competitor scores: shading too far increases the probability of losing the auction. +The upper reward cap $c_u$ makes the mechanism first-price-like when it binds. +Beyond the cap, increasing the induced score no longer increases the solver’s protocol reward, but it can still reduce the value the solver retains. +In that regime, shading the score downward can increase expected profit. +Doing so safely, however, requires a model of competitor scores: shading too far increases the probability of losing the auction. Empirically on Ethereum mainnet ([Dune](https://dune.com/queries/7560960) query, ~2,000 auctions), the cap binds in about a third of winning batches, but the value at stake is usually small and concentrated in tail auctions: @@ -171,23 +215,26 @@ Empirically on Ethereum mainnet ([Dune](https://dune.com/queries/7560960) query, | p99 clipped, when binding | \~0.075 ETH (\~$300) | | Max clipped, single auction | ~0.849 ETH | -The baseline score remains the protocol's suggested starting point because it does not require predicting competitor behaviour. Solvers are free to use different scoring strategies, including reward-cap-aware shading, based on their own models of competition, execution risk, and expected payoff. +The recommended score remains the protocol's suggested starting point because it does not require predicting competitor behaviour. +Solvers are free to use different scoring strategies, including reward-cap-aware shading, based on their own models of competition, execution risk, and expected payoff. ## Consistency rewards -[CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff) distributes a weekly consistency budget across solvers based on participation. Penalties paid on unsets feed this budget, so a solver receives back a fraction: their share of the budget at week-end. -The exact value of the share depends on aggregate weekly metrics that themselves depend on other solvers' behaviour. The baseline formula above ignores these effects. +[CIP-85](https://snapshot.box/#/s:cow.eth/proposal/0xb488c343df3ba5f3857a4c7a920a74e18c13a2cdce99d27af34216803da6abff) distributes a weekly consistency budget across solvers based on participation. +Penalties paid on unsets feed this budget, so a solver receives back a fraction: their share of the budget at week-end. +The exact value of the share depends on aggregate weekly metrics that themselves depend on other solvers' behaviour. +The formula above ignores these effects. ## Practical checklist For each candidate solution $x$: 1. Estimate $S(x)$, $p(x)$. -2. Compute the baseline score $s_{\text{base}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$ +2. Compute the recommended score $s_{\text{rec}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$ 3. Set the settlement slippage tolerance using $\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$ 4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome. -5. For multiple orders on the same directed pair, combine them into one solution. -6. Submit individual-pair fallbacks alongside batched solutions. -7. Submit every viable candidate. +5. Submit individual-pair fallbacks alongside batched solutions. +6. Submit every solution that creates positive value, i.e., $S(x) > 0$. -The reward cap, consistency rewards and quote rewards can also affect how profitable a bid is. Solvers are free to experiment with moving away from the baseline to account for them. +The reward cap, consistency rewards and quote rewards can also affect how profitable a bid is. +Solvers are free to experiment with moving away from the recommended bid to account for them. From 61d76e033cbf1160080e3a21a74b4fc7176b4ae1 Mon Sep 17 00:00:00 2001 From: Archit Sharma <90101251+Architsharma7@users.noreply.github.com> Date: Thu, 1 Oct 2026 15:23:13 +0530 Subject: [PATCH 6/8] Update docs/cow-protocol/tutorials/solvers/optimal_bidding.md Co-authored-by: Felix Henneke --- docs/cow-protocol/tutorials/solvers/optimal_bidding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 9e321f866..d113777c1 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -125,7 +125,7 @@ $$ The recommended score is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score. A strategy is dominant if it is the best choice regardless of what other solvers submit. -This is the dominant strategy in the simplified mechanism (where the reward cap does not bind and fairness filtering is ignored) since the solver does not need to predict the reference score or model competitor behaviour to choose their score. +The recommendation above is a dominant strategy in a simplified mechanism where the reward cap does not bind and only one order is settled. A solver does not need to predict the reference score or model competitor behaviour to choose their score. The intuition is that, given the reward mechanism's second-price characteristics, changing the reported score only changes whether the solution wins. It does not change the solver’s payoff. From 43258fe549c62afbb7e72e2272fdca92e29905ae Mon Sep 17 00:00:00 2001 From: Archit Sharma <90101251+Architsharma7@users.noreply.github.com> Date: Thu, 1 Oct 2026 15:23:36 +0530 Subject: [PATCH 7/8] Update docs/cow-protocol/tutorials/solvers/optimal_bidding.md Co-authored-by: Felix Henneke --- docs/cow-protocol/tutorials/solvers/optimal_bidding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index d113777c1..14c3766a3 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -172,7 +172,7 @@ $$ The solver compares the payoff from settling through adverse slippage with the realised payoff from unsetting. Settling yields approximately $S(x)−s(x)− \gamma$. -Unsetting instead incurs a penalty $min(s(x),c_l)$. +Unsetting instead incurs a penalty $\min(s(x),c_l)$. The slippage tolerance is therefore the point at which the solver is indifferent between these two outcomes. **Example.** Continuing the previous example, the solver won the 10 ETH order with a score of 95, keeping 5 USDC. From 7e6c6bd128a13f23da9d7ee9a1d6c4e33dc996ec Mon Sep 17 00:00:00 2001 From: Architsharma7 <90101251+Architsharma7@users.noreply.github.com> Date: Thu, 1 Oct 2026 15:49:57 +0530 Subject: [PATCH 8/8] applied last remaining suggestions --- .../cow-protocol/tutorials/solvers/optimal_bidding.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md index 14c3766a3..272e2d260 100644 --- a/docs/cow-protocol/tutorials/solvers/optimal_bidding.md +++ b/docs/cow-protocol/tutorials/solvers/optimal_bidding.md @@ -116,13 +116,14 @@ $$ s_{\text{rec}}(x) = p(x)\ S(x) $$ -When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, so the cap on the unset penalty lets the solver bid more aggressively: +When the lower penalty cap **does** bind, the loss from an unsuccessful settlement is bounded by $c_l$, so the cap on the unset penalty lets the solver share more surplus with the user: $$ s_{\text{rec}}(x) = S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) $$ The recommended score is therefore the larger of the uncapped risk-adjusted score and the penalty-cap-adjusted score. +Every solution with $S(x) > 0$ has a positive recommended score $s_{\text{rec}}(x) > 0$, so it is a valid solution and should be submitted. A strategy is dominant if it is the best choice regardless of what other solvers submit. The recommendation above is a dominant strategy in a simplified mechanism where the reward cap does not bind and only one order is settled. A solver does not need to predict the reference score or model competitor behaviour to choose their score. @@ -133,7 +134,9 @@ Lowering the score may lose profitable wins, while raising it may win unprofitab ## Worked example -Continuing with the 10 ETH order, suppose the solver settles 90% of its wins in time ($p = 0.9$) and the order's penalty cap is $c_l = 45$ USDC. +Continuing with the 10 ETH order, the solution creates a value of $S = 100$ USDC to be shared. +Suppose the solver settles 90% of its wins in time ($p = 0.9$) and the order's penalty cap is $c_l = 45$ USDC. +These are the three inputs to the formula. The penalty cap here is chosen large to make the effect visible; real penalty caps depend on the chain and the token pair (see [penalty caps](/cow-protocol/reference/core/auctions/rewards#penalty-caps)). | | USDC | @@ -145,6 +148,7 @@ The penalty cap here is chosen large to make the effect visible; real penalty ca The solver bids 95: it promises the user 85 USDC of surplus (95 minus 10 in fees) and keeps 5. To see why 95 is right, compare it with bidding the full value (100) and with ignoring the penalty cap (90). +The table looks at four cases of what competitors do, each summarised by the reference score $s_{\text{ref}}$, the best score the protocol could reach without this solver. The value of a win is $0.9 \cdot (100 - s_{\text{ref}}) - 0.1 \cdot \min(s_{\text{ref}}, 45)$: | Competition $s_{\text{ref}}$ | Value of a win, without cap | Value of a win, with cap | Bid 100 | Bid 90 | Bid 95 | @@ -229,12 +233,11 @@ The formula above ignores these effects. For each candidate solution $x$: -1. Estimate $S(x)$, $p(x)$. +1. Estimate $S(x)$ and $p(x)$, and compute $c_l$ as the sum of the [penalty caps](/cow-protocol/reference/core/auctions/rewards#penalty-caps) of all orders in the solution. 2. Compute the recommended score $s_{\text{rec}}(x) = \max\!\left( p(x)\ S(x) ,\ \ S(x) - \tfrac{1 - p(x)}{p(x)} \big(c_l\big) \right)$ 3. Set the settlement slippage tolerance using $\gamma(x) = S(x)-s(x)+\min(c_l,s(x))$ 4. For batched solutions, verify the fairness filter passes against the per-pair reference outcome. 5. Submit individual-pair fallbacks alongside batched solutions. -6. Submit every solution that creates positive value, i.e., $S(x) > 0$. The reward cap, consistency rewards and quote rewards can also affect how profitable a bid is. Solvers are free to experiment with moving away from the recommended bid to account for them.