CIP-87: Penalty Cap Redesign - #655
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: Team Run ID: 📝 WalkthroughWalkthroughThe solver rewards documentation references CIP-XX, updates chain-specific performance caps, defines lower caps from unsettled orders, and clarifies penalty guidance for late or absent settlement. ChangesSolver rewards
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/cow-protocol/reference/core/auctions/rewards.md`:
- Line 155: Update the solver guidance paragraph to replace “revert risk” with
“settlement-failure risk,” ensuring the reported-score adjustment explicitly
covers both late and absent settlement cases represented by the penalty caps.
- Line 44: Update the user-facing definition near the upper cap c_u to replace
“onchain” with “on-chain,” leaving the rest of the sentence unchanged.
- Around line 51-55: Update the definition of c_l in the rewards documentation
to explicitly define unsettled_i as the winning auction-order pairs from solver
i’s solutions that were not fully settled. Specify that each pair contributes
its penalty cap for the unexecuted portion, including the appropriate
partial-fill accounting, rather than treating only entirely unsettled orders as
contributors.
- Around line 59-65: Update the penalty-cap definition near
\textrm{penaltyCap}_o to remove the claim that \bar{c} equals the native-token
equivalent of 20 USD. Describe \bar{c} using the chain-specific lower-cap values
and terminology established by the actual CIP or implementation contract,
without introducing a price source or rounding rule.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d27cfbc0-0ab7-476c-a86a-9bed96b891f0
📒 Files selected for processing (1)
docs/cow-protocol/reference/core/auctions/rewards.md
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 <noreply@anthropic.com>
nit: since you changed the "revert"s in the other sections to "did not settle" / "were not settled", it make sense to change it here too to maintain consistency. |
|
I changed the docs to conform to the rule implemented in the backend: cowprotocol/services#4773 This is a deviation from the initial proposal in the CIP text. It is within the mandate of the core team to change the computation of the cap. Therefore this does not violate the CIP. |
| - `quote`: the winning quote for that order. | ||
| - `penaltyCapNative`: a stringified integer denoting the cap on the penalty a solver can incur for winning this order but not settling it within the auction deadline, measured in terms of the smallest denomination of the native token of the chain. See the [solver rewards](/cow-protocol/reference/core/auctions/rewards#penalty-caps) page for how this cap is computed and used. |
There was a problem hiding this comment.
suggested change:
penaltyCapNative: a stringified integer denoting the cap on the penalty a solver can incur if this order is included in a winning solution that fails to settle within the auction deadline, measured in the smallest denomination of the chain's native token. See the solver rewards page for how this cap is computed and applied.
|
|
||
| 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 |
There was a problem hiding this comment.
Every order has a penalty cap associated with it in each auction, expressed in the native token of the chain --> Every order has a penalty cap, computed per auction using that auction's native prices.
| - 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 on-chain by the solver in that auction. $$\beta$$ is determined by the following values: |
There was a problem hiding this comment.
change to:
The upper cap
4 participants
Documentation change reflecting the penalty cap redesign CIP draft: the chain-specific absolute penalty cap is replaced by a per-order penalty cap.
This PR would be merged, after filling in the
CIP-XXplaceholders, if the CIP were to pass.Summary by CodeRabbit