CIP-17: Making slippage symmetric

CIP: 17
title: Making slippage symmetric
author: harisang
created: 2022-12-07

Simple summary

This post proposes that the protocol treats slippage incurred by solvers symmetrically; in the case of negative slippage, a solver would be penalized with an amount equal to the negative slippage incurred (as is the case now), while in the case of positive slippage, the protocol would reimburse the solver with an amount equal to the positive slippage generated.

Motivation

Slippage management in CoW Protocol is the sole responsibility of solvers. A settlement can incur slippage as follows: the winning solution reports the uniform clearing price vector, which locks prices at the moment the winning solver is chosen. However, from the moment the winner is picked offchain until the moment the winning solution is mined onchain, several seconds might pass and in the meantime, there can be market shifts. Thus, a solution that expects a certain amount of tokens to be returned by an AMM interaction might end up receiving less, or more, from that AMM interaction. The case where the settlement contract receives more is a case of "positive" slippage for the solver, while the case where the settlement contract receives less, and thus has to use some of its own internal buffers to cover the difference, is a case of "negative" slippage for the solver.

The protocol tracks all instances of slippage on a per solver basis, and during each week's payout, it accounts for all positive and negative slippage each solver incurred, and aggregates this into a single value for each solver which we call weekly net slippage. This weekly net slippage is computed by converting all token imbalances to ETH, by using the price with respect to ETH of each token involved at a slippage settlement, where the price is estimated around the time the settlement took place. Here is an example query demonstrating how slippage is computed and aggregated; we clarify that these queries are being improved over time so we propose that the latest version of such a query is used for the slippage accounting. Weekly net slippage is always denominated in ETH, and can be either positive, zero, or negative.

In each week's payout (currently taking place on Tuesdays each week), the solvers that end up with a negative weekly net slippage are penalized by this negative slippage value (i.e., they pay this amount back to the protocol) while solvers that end up with positive weekly net slippage do not gain anything, and the slippage accounting is reset. This means that in the case where solvers have positive net slippage, this is not paid out to them and it also cannot be used to balance out potential future negative slippage, so from the solver's perspective, it is lost.

In other words, slippage is currently treated asymmetrically. One of the reasons this was set up in such a way is because slippage in any case is inherently stochastic, so solvers would, more or less, see a net slippage close to zero if they settle enough batches; i.e., on expectation, net slippage should be close to zero. This means that solvers would most likely not view slippage as a source of consistent profit.

However, this asymmetry also creates some issues.

1. As we move towards a more decentralized stage of the competition, having this asymmetry in slippage is a decentralization barrier, as the protocol interferes with what would otherwise be fully managed by each solver, separately. A counter-argument for this is that there is inherent risk with accumulating slippage in tons of different tokens and then aggregating this to a single ETH value; in particular, in the weekly accounting, positive slippage in a random token can balance out negative slippage in ETH, which means that the protocol accepts the risk of treating all tokens in a uniform way. Nevertheless, we believe that making slippage symmetric and thus allowing solvers to fully manage and own their net slippage is one step towards the right direction.

We note here that solvers can already fully own the slippage they generate/suffer, by using an intermediate contract that will be responsible for executing all AMM/liquidity interactions (and there is at least one solver already implementing this strategy). However, this adds some gas overhead, and until the competition reaches a stage where each solver will have their own separate contract, we think that the protocol should allow solvers to fully own their positive slippage.

2. From an external point of view, a case could be made that the protocol attempts to profit, whenever possible, from the positive slippage that solvers might generate; however, this is not in the protocol's intentions.

3. A solver that has accumulated significant positive slippage might be tempted to aggressively spend it, by setting, for example, very loose slippage tolerances in order to avoid reverts. However, we do not believe this adds any real value to the protocol, on average it does not benefits users and in most cases simply results in overspending and sloppy slippage management. This can be made worse by the fact that slippage accounting is reset each week, so positive slippage cannot be used to balance out potential negative slippage across different weeks.

In other words, this limited time window in which slippage is accounted for can potentially skew the distribution of slippage and not make it centered around zero, which can incentivize solvers in the wrong ways. Since doing payouts and accounting regularly is a practical necessity, making slippage symmetric completely removes the distortion that a limited time horizon might create.

Positive slippage in the past 3 months

To get an idea of how much positive slippage was kept in the protocol, we checked positive slippage generated by solvers during a 12-week period (September 22- November 22), and it turns out it is 23.368 ETH. Data was collected using this query, that is used for the weekly slippage accounting.

A more detailed weekly breakdown is the following:

• Sep 6-13: +0.572
• Sep 13-20: +0.990
• Sep 20-27: +2.569
• Sep 27-Oct 4: +0.470
• Oct 4-11: +0.009
• Oct 11-18: +2.975
• Oct 18-25: +1.597
• Oct 25-Nov 1: +0.258
• Nov 1-8: +2.625
• Nov 8-15: +8.049 (FTX hacker trades)
• Nov 15-22: +1.521
• Nov 22-29: +1.733

Specification

We propose that we remove this asymmetry and make slippage treatment completely symmetric, as we believe that the benefits far outweigh the risks. In particular, using the slippage accounting methods that are already used in the protocol, solvers should be reimbursed for positive slippage while they should be penalized (as they are, now) for negative slippage. In the case of negative slippage, the protocol would deduct the slippage amount in ETH from the gas reimbursements (as it is the case now), while in the case of positive slippage, the protocol would send this positive slippage, measured in ETH, in the rewards address of each solver, along with the COW rewards sent each week.

Rationale

There were a few options regarding the implementation of this proposal. For example, the protocol could decide to not pay out positive slippage, but instead keep accounting of the positive slippage for larger time windows (and not just weekly ones). However, we believe that this might still create wrong incentives for solvers, as positive slippage would still not be fully owned by them. Thus, we propose that positive slippage is explicitly payed to solvers, and the simplest way to do this is by sending the corresponding ETH amount to the solver rewards addresses, so that solvers have full control over it.