CIP-Draft: EBBO (fairness) specifications, reimbursement procedures and escalation mechanisms

Governance
1 
CIP: <to be assigned when moved to phase 2>
title: EBBO (fairness) specifications, reimbursement procedures and escalation mechanisms
author: Chris (c3rnst), Haris Angelidakis, Felix Henneke
status: Draft
created:  2024-09-26

Simple Summary

CoW DAO’s vision is to always give the user the best possible outcome and thus become the primary price finding venue for digital assets. With the current technical state of the protocol, it can, however, happen that the realized executions are not best possible from the users’ point of view. Because of that, CoW DAO decided to protect its users with the application of social consensus rules, and specifically with the rule often referenced as EBBO (Ethereum’s Best Bid and Offer), that (roughly) specifies that the surplus a trade receives should be at least as large as the surplus that can be obtained when using publicly available onchain liquidity (cf. CIP-11 and CIP-20).

The current mechanism allows for the slashing of misbehaving solvers to enforce these social consensus rules. It has indeed happened that a few trades were unfavorable to CoW Protocol users; while respecting each user’s limit price, the surplus received was lower than the maximum surplus possible (given the state of publicly available onchain liquidity at the time of the trade). In light of a recent large-volume trade that got a suboptimal execution (and a backrun that followed it), this CIP shall now further formalize what constitutes an EBBO violation, make reimbursement procedures and escalation mechanisms clearer and mandate retroactively and for the future the teams involved as well as authorize the guideline with the successful passing of this CIP.

This CIP shall bring procedural clarity in case an EBBO violation occurs:

I. Reimbursement procedures
II. Escalation mechanism: Slashing of a solver bond
III. EBBO violation calculation

Details

As a reminder, within the protocol infrastructure it is hard-coded that users always get at least their limit price. The “best possible” outcome refers to the highest surplus possible, above the limit price.

One reason for unfavorable settlements with lower surplus to users is the Ethereum’s Best Bid and Offer (EBBO) violation of solvers. CIP-20 outlined the EBBO mandate reasoning: “We want to avoid the situation of solvers decreasing surplus [to users] and will therefore monitor and enforce EBBO (Ethereum’s Best Bid and Offer) rules more strictly, see the social consensus rules in CIP-11.”

CIP-44 is a critical cornerstone in the technical decentralization, allowing solvers to have more control and making this feasible by reduced bonding requirements to still maintain security guarantees. With the move towards more independent solver-driver infrastructure and hence more decentralization, this CIP addresses the need to define the escalation for misbehavior by proposing an implementation to rely on CoW DAO governance as the ultimate resolving body.

I.(a) Reimbursement procedures

  1. A 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). 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.

  2. The core team calculates the (minimum) value lost to users in a given settlement due to the EBBO violation (cf. section III).

  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 (cf. section II).

I.(b) Addition for non co-located drivers

For all CoW DAO bonded and non co-located drivers, MEV blocker rebates from trade settlements are accumulated in the CoW DAO owned MEV Blocker Rebates Safe. As per decision of CoW DAO, the rebates from the MEV Blocker Rebates Safe are redirected to the CoW DAO Treasury Core unit (cf. CIP-33), which is also a one-out-of-two owner of the MEV Blocker Rebates Safe next to CoW DAO itself.

With the successful passing of this proposal, the MEV blocker rebate that is directly associated with the execution of the order in question, if any, shall be used to refund the solver (to clarify: if the MEV blocker rebate is smaller than the solver’s reimbursement to the user, it is used fully to refund the solver to that extent. If the MEV blocker rebate is bigger than the solver’s reimbursement to the user, only the actually reimbursed amount is refunded to the solver). Refunds will be handled by the CoW DAO Treasury Core Unit within a few weeks after the reimbursement is made, and will be sent to the solver address from which the reimbursement has happened. For avoidance of doubt, the CoW DAO Treasury Core unit has autonomy on selecting any position to be liquidated for this purpose in case the MEV Blocker Rebates Safe does not have sufficient accumulated funds.

II Escalation mechanism: Slashing of solver bond

  1. If a solver team does not reimburse a user as per request by the core team within the said timeline, 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.

  2. 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].

  3. 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.

  4. 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.

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.

III EBBO violation calculation

The intention is to formalize the concrete rules already specified in the public documentation, and hence for the core team to be specifically mandated with these in mind and for solvers and the community to have the ability to hold the core team accountable on the basis of the specification.

This section includes a description of what constitutes a certificate of an EBBO violation. Not each EBBO violation needs a CIP, however, the escalation via slashing then does need a CIP, which then also requests the core team to submit the calculation performed (attaching the certificate).

Calculation of EBBO violation

A certificate for an EBBO violation consists of a list of reference routings, one for each block between the start of the auction and when the settlement happened onchain.

A reference routing for a trade at a given block is an execution (i.e., successful simulation) of that trade at the top of the block which only uses liquidity from base protocols and routes through base tokens (see below for definition base protocols and base tokens). The minimal surplus received by users in those routings is used as reference surplus (concretely, one goes over all (routing, block) pairs in the provided list and looks at the worst routing wrt surplus, and this one is used to compute the reference surplus).

UPDATED DEFINITION OF CERTIFICATE

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 below for 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. The time between providing a different block and receiving the new reference routing does not count towards the 72 hours of I.(a) 4.

At the moment, the following protocols and tokens are considered base protocols and base tokens:

Ethereum Mainnet:

  • base protocols: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2

  • base tokens: WETH, DAI, USDC, USDT, COMP, MKR, WBTC, GNO

Gnosis:

  • base protocols: Honeyswap, Sushiswap, Baoswap, Swapr, Balancer v2

  • base tokens: WXDAI, HNY, USDT, USDC, sUSD, WBTC, GNO, STAKE, xOWL, WETH

Arbitrum One:

  • base protocols: UniswapV2/V3, SushiSwap, Swapr, BalancerV2

  • base tokens: WETH, USDC, USDT, DAI, GNO

Base protocols and base tokens for existing chains may only be updated via a new CIP, while lists created by the core team can be proposed without a CIP when the protocol expands to a new chain. The format of the certificate is up to the discretion of the core team.

There is no specific threshold as to when the team triggers the reimbursement procedure to not open a loophole for participating solvers to aim for misbehavior below the threshold.

6 Likes
2

I would add “or there is reasonable concern that more damage may occur”.

A certificate for an EBBO violation consists of a list of reference routings, one for each block between the start of the auction and when the settlement happened onchain.

I think this is overly complex and it will create a lot of work to generate such a certificate. Moreover it might be that top of block execution is different to what any reasonable solver could have achieved mid-block if there is a lot of CEX/DEX arb at the time.

Imo an EBBO violation can be triggered by showing an execution using any of the blocks between the auction start and solution submission block (in any index). A solver can the rebuttal this claim by specifying the assumptions (block number, state) they made to calculate their route. If given that state there indeed exists no EBBO violation (no other route using base liquidity would yield a better price) the claim is void, otherwise it is valid.

1 Like
3

In practice, one can still propose a single route, and then the current proposal would simply look at how this route simulates in every block between auction creation and onchain execution. This should not be too complicated and still kills false positives, in cases where even at the top of a block in the defined range, the execution that claims to be a certificate of an EBBO violation is actually worse than what happened onchain (and thus the solver should be given the benefit of the doubt that they actually considered that block when computing their execution).

Assuming solvers do very refined risk management and actually predict their solution will not be at the top of a block and thus negative slilppage might occur, then what you suggest makes sense. Of course, that implies that every solver, when faced with an EBBO violation claim, would check every candidate block/index combination with the hope that the proposed certificate is not valid for that block/index. So, because of that, one could simply redefine what a certificate is by taking the worst case execution not only over all candidate blocks but also over all slots in these blocks. I am personally fine with this definition as well; this would mean checking potentially hundreds of simulations but this is still very doable, so if there is consensus around this, we could add this modification.

1 Like
4

I understand that the protocol and base token can be updated through a CIP. However do you plan to update the current list? The current list still contains like DAI and MKR, or we just plan to treat them as USDS and SKY since they should be 1:1.

1 Like
5

Good point. If there is consensus about the proposal that

Base protocols and base tokens for existing chains may only be updated via a new CIP, while lists created by the core team can be proposed without a CIP when the protocol expands to a new chain.

then maybe we can keep things as is for the scope of this CIP and then have a follow-up CIP soon that only focuses on the updating of these lists, so that we don’t open a parallel discussion on these choices for this CIP.

2 Likes
6

I like this approach. It makes it fairer for solvers, as the position in the block can be varied. It also makes it a bit easier to check since the part about finding the exact block position is moved to the solver, who knows which state of the blockchain they provided a routing for.

The wording of th CIP could be changes as follows:

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 below for definition 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 challanged by the solver who is accused of the EBBO violation by providing a different block (and index). In this case, a reference routing on this block (and index) is proposed by the core team and used as certificate instead. The new certificate cannot be challanged again. The time between providing a different block and receiving the new reference routing does not count towards the 72 hours of I.(a) 4.

I think it is overall simpler to only look at two blocks (and idices). Since finding optimal routing is already complex enough, doing it for all blocks and indices seems unnecessarily complicated. Moving the responsibility for finding a suitable block to solvers sounds reasonable. They know best what state of the blockchain they used for their execution. And they are the ones who are best at finding optimal routes. Having a back and forth is not ideal but has happened in practice anyways.

7

I agree that it is conceptually easier to define the certificate the way you are defining it, so we can use that definition, as in practice, in any case, a certificate will converge to being a single execution at a single block, and then either the solver or some other entity checking that execution on other blocks/indexes as well.

Since finding optimal routing is already complex enough, doing it for all blocks and indices seems unnecessarily complicated. Moving the responsibility for finding a suitable block to solvers sounds reasonable. They know best what state of the blockchain they used for their execution. And they are the ones who are best at finding optimal routes.

This is a good point, so that we actually push the responsibility of checking the certificate to the potentially offending solver.

I will update the original text to reflect this change then by esssentially copy-pasting your proposed modification.