Guidelines for solver-computed fees for long-standing limit orders as implied by past CIPs

Technical
1

Introduction

For the last several months, CoW Protocol has enabled the support of the so-called out-of-market limit orders. These are orders that come with a user-specified limit price and are not (in most cases) meant to be executed right away, as this user-specified limit price is usually not achievable at the time the order is placed. For such orders, it does not make much sense to specify a fixed fee when the order is created, as the order’s onchain execution might happen much later in the future. For this reason, such an order is signed with zero fee, and then, if its limit price becomes achievable and a solver proposes to execute the order, the solver is also asked to specify a fee (in the sell token) for this order. This fee, as in the case of market orders, is only supposed to capture the gas of executing this order (by itself) and is not meant to actively generate revenue for the protocol. However, explicit rules around the computation of these fees are not included in any CIP.

The purpose of this post is to clarify the situation with these solver-computed fees and claim that there are already rules implied by the social consensus rules contained in CIP-11 and in the corresponding forum post. Quoting the forum post, the following social consensus rule was included:

  1. Other malicious behavior
    Malicious solver behavior is not limited to the above examples. Slashing can still happen for other reasons where there is intentional harm caused to the user and/or the protocol at the discretion of the CowDAO.

Limit order fees

Going back to the fee discussion, currently there is no protocol fee, in the sense that the protocol is not setting fees so as to actively and explicitly generate revenue. Given this, and the rule above that specifies that both users and the protocol should be treated fairly, we claim that the guideline implied by the above is that solver-computed fees for long-standing limit orders should be set in such a way so that the following are (approximately) satisfied:

  1. The sum of fees of all orders within a batch cover the execution cost of the settlement that executes the batch, unless the settlement also contains orders that are paying very low fees, so that a limit order ends up overpaying.

  2. To address this last point of overpaying, the fee of an order should cover the execution of the order by itself but not more than that.

Given the above, we believe that a solver that systematically and on purpose deviates from the above and abuses limit order fees (either at the expense of users or the protocol) is effectively violating social consensus rules, and such a behavior should be considered a slashable offence.

Monitoring

The core team has been monitoring how solvers are doing with fee computations, and we are happy to observe that the protocol has already reached a state where solvers are making very good estimates of fees and in most cases the deviations from the above described “ideal state” are small. Nevertheless, and since most of the monitoring currently takes place after a settlement is executed, we need to continue monitoring and potentially add more checks in place. For these reasons, with this post we would like to raise awareness around this topic and have a reference point in case we ever run into issues around fee computations.

1 Like