added optimal bidding strategy page to docs tutorials - #657
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
There was a problem hiding this comment.
One thing I would change in the tutorial is to be more detailed in the explanation of the initial formula for bidding, and way less detailed in explaining how some other aspects of the competition change behavior. The latter seems somewhat unnecessary for a tutorial, while also inviting lots of subtle errors. I would not be confident in proposing how consistency rewards change strategy, or what solvers should do in the face of upper reward caps. Instead, I would frame it as "these other things have impact on bidding as well, feel free to experiment with changing your strategy away from the baseline".
Of the extensions, only slippage seems to fall into the scope of this tutorial. The worked example should be extended to that.
I think that the approach of the knowledge sharing session worked well. I.e. going from routing, to value, to risk adjusted bid, to slippage tolerance.
I added a Claude review below which touches on a few valid points and lots of nitpicks.
Review by Claude, run by @fhenneke.
Reward cap, consistency rewards, quote rewards
These three sections restate mechanism details at a level of precision that introduces errors:
c_uis treated as an exogenous chain parameter. It isβ · protocolFee(excluding partner fees) over the solver's solutions settled in that auction, so it is not independent of the solution.- The
(1−α)·c_lrefinement omits that an unset also lowers the settlement success rate, which multiplies the consistency metric. The page therefore understates the cost of an unset. - The quote-reward condition is not
s ≥ q. Per CIP-72 the requirement is that the quoting solver proposed an execution of that order at least as good as the quote and that it was not removed by fairness filtering, plus three further conditions (fill-or-kill market order, verified quote, order executed). A score and a quoted amount are different quantities.
Suggest replacing the three sections with one stating that the reward cap, consistency rewards and quote rewards also affect the profitability of a bid, linking to the rewards reference.
The same applies to the Dune table, which will go stale. The text says ~2,000 auctions, the table says 1,464.
Corrections
- Unset penalty. The page states
min(reference score, c_l). Per the rewards reference it ismin(referenceScore_i − score of the other winners, c_l), which collapses tomin(referenceScore, c_l)only when the solver is the sole winner of the auction, not when it has a single winning solution. - Score composition. The page has
s(x) = user surplus + protocol fee + partner fee. the-problem definesscore(o) = (U(o) + f(o))·p(b)withfthe protocol fee, and the rewards page says "protocol fee (excluding partner fees)" for the cap. Whether partner fees enter the score needs confirming; if they do, the-problem should state it as well. - Positive score is a validity condition.
s_basecan be zero or negative for low-value, low-pcandidates, which conflicts with "submit every viable candidate". - Slippage tolerance. The derivation substitutes the reported score for the reference score without saying so, and drops the reward term, which is only valid under that substitution.
- Worked example. Solution C is
0.42 − (0.06/0.94)·0.01 = 0.419362, so0.4194, not0.4193. c_l = 0.01 ETHis hardcoded. It is chain-specific and may change (#655). Link the chain table instead.
Duplication
rewards.md § Solver's strategy already covers truthful bidding, the cap's first-price logic and fairness-filter strategy. The third paragraph of "The auction setting" is close to verbatim from it.
Framing
The TL;DR ("the score should be neither inflated ... nor reduced") reads as prescriptive. Consider stating once that this is a starting point rather than a competition rule, and that the optimal strategy for this mechanism is not known.
Nits
- No internal links.
rewards,the-problem,competition-rules#off-chain-protocolandaccountingare candidates. - No
sidebar_positionin the frontmatter; every sibling page has one, so this page sorts last. -
$min(...)$renders as italic min; use$\min(...)$. - "If on-chain slippage would exceeds
$-\gamma$ ": grammar, and the sign conflicts with "maximum negative slippage". - "is sum of three components" → "is the sum of"; "incurs the a penalty"; "an heuristic" → "a heuristic"; "i.e," → "i.e.,".
- Overview: "estimate the value it creates, the probability it settles successfully" is missing a conjunction.
- Checklist item 1 repeats the section's lead-in ("For each candidate solution
$x$ ").
|
|
||
| ## 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. |
There was a problem hiding this comment.
estimate the value it creates, the probability it settles successfully. --> estimate the value it creates, and the probability it settles successfully.
| - $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: |
There was a problem hiding this comment.
is sum of three components --> is the sum of three components
|
|
||
| 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. |
There was a problem hiding this comment.
could also instead transfer --> could also transfer
| \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. |
There was a problem hiding this comment.
Unsetting instead incurs the a penalty --> Unsetting instead incurs a penalty
|
|
||
| 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. |
There was a problem hiding this comment.
is worth zero, the individual-pair fallbacks ensure the solver still wins the pairs it can. --> 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. |
There was a problem hiding this comment.
we do not recommend solvers use the fairness filter" → drops into first-person "we" for one sentence; rest of the doc is third-person/imperative. Suggest you pick one voice
| ## 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. |
There was a problem hiding this comment.
an heuristic --> a heuristic
|
|
||
| For each candidate solution $x$: | ||
|
|
||
| 1. For each candidate solution $x$, estimate $S(x)$, $p(x)$. |
3 participants
Description
Adds a solver-facing guide to the docs tutorials covering the recommended baseline bidding strategy for CoW Protocol's combinatorial auction
ref: Notion