CIP-52 (EBBO Updates) (#432)

This PR updates the documentation to accommodate for the changes
proposed in
[CIP-52](https://snapshot.org/#/cow.eth/proposal/0x0f2f1fde68d85081a7d60f7ac99dafbdabdbf8c8cf55961f2609b3dff429a24a),
that is currently live and open for voting.

Note that this PR should be merged ONLY if CIP-52 successfully passes.

docs/cow-protocol/reference/core/auctions/competition_rules.md

@@ -43,6 +43,7 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz
   - buy token / base token
   - sell token / buy token
 
+  ### Base protocols and tokens
   The following detail sections list the protocols and base tokens that are considered for Ethereum Mainnet and Gnosis Chain:
 
   <details>
@@ -59,6 +60,15 @@ At CoW DAO's discretion, systematic violation of these rules may lead to penaliz
     - **Base tokens**: [`WXDAI`](https://gnosisscan.io/token/0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d), [`HNY`](https://gnosisscan.io/token/0x71850b7e9ee3f13ab46d67167341e4bdc905eef9), [`USDT`](https://gnosisscan.io/token/0x4ECaBa5870353805a9F068101A40E0f32ed605C6), [`USDC`](https://gnosisscan.io/token/0xDDAfbb505ad214D7b80b1f830fcCc89B60fb7A83), [`sUSD`](https://gnosisscan.io/token/0xB1950Fb2C9C0CbC8553578c67dB52Aa110A93393), [`WBTC`](https://gnosisscan.io/token/0x8e5bbbb09ed1ebde8674cda39a0c169401db4252), [`GNO`](https://gnosisscan.io/token/0x9C58BAcC331c9aa871AFD802DB6379a98e80CEdb), [`STAKE`](https://gnosisscan.io/token/0xb7D311E2Eb55F2f68a9440da38e7989210b9A05e), [`xOWL`](https://gnosisscan.io/token/0x0905Ab807F8FD040255F0cF8fa14756c1D824931), [`WETH`](https://gnosisscan.io/token/0x6A023CCd1ff6F2045C3309768eAd9E68F978f6e1)
   </details>
 
+  <details>
+    <summary>Arbitrum baseline protocols and tokens</summary>
+
+    - **Protocols**:  Uniswap v2/v3, Sushiswap, Swapr, Balancer v2
+    - **Base tokens**: [`WETH`](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1), [`USDC`](https://arbiscan.io/token/0xaf88d065e77c8cc2239327c5edb3a432268e5831), [`USDT`](https://arbiscan.io/token/0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9), [`DAI`](https://arbiscan.io/token/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1), [`GNO`](https://arbiscan.io/token/0xa0b862f60edef4452f25b4160f177db44deb6cf1)
+  </details>
+
+More details about how a certificate of an EBBO violation is computed, and what are the steps taken in case such a violation occurs can be found in [this](/cow-protocol/reference/core/auctions/ebbo-rules) section.
+
 - Inflation of the objective function ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). Using tokens for the sole purpose of inflating the objective value or maximizing the reward is forbidden (e.g., by creating fake tokens, or wash-trading with real tokens).
 
 - Illegal use of internal buffers ([CIP-11](https://snapshot.org/#/cow.eth/proposal/0x16d8c681d52b24f1ccd854084e07a99fce6a7af1e25fd21ddae6534b411df870)). The internal buffers may only be used to replace legitimate AMM interactions available to the general public for the purpose of saving transaction costs, and also to allow for the successful execution of settlements that occur some slippage. However, systematic and intentional buffer trading with tokens that are not safe, although will be accounted for as slippage, is discouraged as it poses a significant inventory risk to the protocol, and solvers that do so can be flagged and potentially slashed. In general, any attack vector to the internal buffers that is created by a solver can be considered a malicious and illegal behavior.

docs/cow-protocol/reference/core/auctions/ebbo_specifics.md

@@ -0,0 +1,43 @@
+---
+id: ebbo-rules
+---
+
+# EBBO violations: details
+
+In this section, we will elaborate on the details about what consistutes an EBBO violation, and what actions are taken by the DAO in case such a violation occurs. The content of this section is based on [CIP-52](https://snapshot.org/#/cow.eth/proposal/0x0f2f1fde68d85081a7d60f7ac99dafbdabdbf8c8cf55961f2609b3dff429a24a).
+
+
+## Certificate of EBBO violation
+
+A certificate for an EBBO violation consists of a reference routing on a block (and log index) between the start of the auction and when the settlement happened onchain. A reference routing for a trade at a given block (and index) is an execution of that trade which only uses liquidity from base protocols and routes through base tokens (see the "Base protocols and tokens" section [here](/cow-protocol/reference/core/auctions/competition-rules) for the definition of base protocols and base tokens). The surplus received by users in this routing is used as reference surplus. The difference between the reference surplus and the surplus actually received by the user is the size of the EBBO violation. This amount needs to be reimbursed to a user.
+
+A certificate for an EBBO violation can be challenged by the solver who is accused of the EBBO violation by providing a different block (and index), within 72 hours of the notification of the violation. In this case, a reference routing on this block (and index) might be proposed by the core team and used as certificate instead. The new certificate, if any, cannot be challenged again.
+
+## Reimbursement procedures
+
+The following steps are taken, in case an EBBO violation is detected, either by the core team’s monitoring infrastructure or a third party reach out (for example by the user themselves or by solvers). We clarify here that in order to avoid reports of very old trades that occurred at a time where the protocol was in earlier phases, violations will be inspected only if they are communicated within 3 months from the incident date.
+
+1. A violation is detected, within 3 months from the incident date.
+
+2. The core team calculates the (minimum) value lost to users in a given settlement due to the EBBO violation, as described in the section above.
+
+3. The core team requests the involved solver team to reimburse the user directly, by informing them about the amount:
+  - The reimbursement is to be done in the surplus token and sent from a responsible solver’s submission / owned address for clarity about who issued the refund. If the solver has no access to their submission account (in case this is managed by the core team), then the core team should transfer any desired amount from the submission account to a solver-related address (i.e. their rewards account), if such a request is made from the solver.
+
+4. Once the incident is communicated, the violating Solver shall process the reimbursement within 72 hours of this notification.
+  - If the violating solver complies, the case is closed.
+  - If the violating solver does not comply, the slashing procedure will be triggered (see section below)
+
+## Escalation mechanism: Slashing of solver bond
+
+In the case where there is an EBBO violation and the solver team responsible for this violation does not reimburse a user as per request by the core team within the said timeline or there is reasonable concern that more damage may occur, the solver will be automatically deny-listed and the core team will post a statement in the CoW DAO Forum for visibility and the opportunity for anyone to comment. The calculation of the amount will be appended in that post. After three days (72 hours), the forum post will be moved to a CoW DAO Snapshot vote as a formal escalation of the violation [note that this overrides the standard 1-week-period a post is usually required to be on the forum only for this type of slashing-CIP].
+
+With a successful passing of the CIP:
+- The solver bond in question is slashed in the amount of refund calculated and triggers repayment to the user;
+- If the vote does not pass, the solver is re-instated.
+
+A solver with a slashed bond can resume activity if the solver bond is replenished. If the solver is part of the CoW DAO bond, CoW DAO may decide in the Solver Bond Slashing CIP to replenish the bond from its own funds. This approach would prevent other bond participants from being negatively impacted.
+
+The CIP vote is then binding for all parties.
+
+We also clarify that if a solver would like to stop operating and obtain the (remainder) of their bond back - which requires a CIP - they can ask to have this transaction included in the same CIP.