This post provides an overview of the current rules of the solver competition and proposes the following changes to be added in the short-term:
- Social consensus (implicit rules)
Global token conservation constraints
- Local token conservation constraints
At CoW Protocol, we are aiming at achieving fair and cost-efficient trading by having a set of solvers competing to solve the Batch Auction Problem. The rules of the competition align solvers with these goals, ultimately driving value accrual for the CowDAO.
The solver department of the CoW Protocol development team has been continuously working on improving the Rules of the Solver Competition. In this proposal, we want to:
- Summarize the rules that are currently implemented and documented
- Propose to add a set of social consensus rules as well as two types of constraints in order to address issues with the current rules as well as prevent potential attacks on the mechanism
Here’s an overview of the current rules and the additions we are proposing:
Objective function maximizes total surplus + fees - costs
User orders respect limit price and max buy/sell amount, uniform clearing prices
Liquidity orders matched at limit price
One set of internal buffers for all solvers
A solution containing no or only “new” user orders is invalid
Social consensus (implicit rules)
Global token conservation constraints
Local token conservation constraints
The current batch auction problem is described here. In this section, we will summarize the status quo of the main rules that need to be respected by solvers. While these have worked reasonably well in practice, we will describe some of the drawbacks as an introduction to some of the suggested changes.
The objective function that is currently used for scoring each solution reads
maximize: total user surplus + fees - costs.
The maximization of total user surplus does not in all cases distinguish between fair and unfair solutions. A solution may be optimal from the perspective of maximizing the sum of all individual surpluses and yet be unfair. We are addressing cases of unfairness both as part of the social consensus rules to be added, as well as via an explicit check in the backend (see further below for details).
CoW Protocol supports two different kinds of orders - user orders and liquidity orders.
User orders are eligible to receive surplus relative to their limit prices as they are matched at uniform clearing prices, and their aggregated surplus is maximized (via the objective function). User orders need to pay fees to cover execution costs.
Liquidity orders, which are meant for market makers, are always matched at limit price, i.e., they are not eligible for surplus. However, liquidity orders currently do not need to pay any fees. They should therefore only be matched if they improve the objective function by increasing total user order surplus, or decreasing costs.
A set of internal buffers is available to all solvers, consisting of a set of eligible tokens that the settlement contract holds at the time. Solvers may replace valid AMM interactions by interactions that trade directly with the internal buffers at the same exchange rate, thus potentially saving on execution costs.
Since the internal buffers currently belong to the protocol and not to the individual solvers, there is a risk of malicious solvers exploiting the buffers for their own advantage. We propose that such behavior should be punished as per the proposed social consensus rules.
A solution that does not settle any user orders is not considered valid for the solver competition. Moreover, in order to leave ample time for potential CoWs, solutions that only contain “new” orders (i.e., orders that have been in the system for less than 30 seconds), are considered invalid.
The above-mentioned rules do not guarantee all aspects of desirable solver behavior, in particular with respect to the fairness of solutions. There are “non-written” behavioral solver rules following from CoW Protocol’s mission of pioneering a fair DEX. While these other rules are not implemented in the backend, we propose that CowDAO enforces them by
- transparently communicating the social consensus as to what kind of solver behavior is not allowed
- checking settlements by solvers retrospectively
- slashing solver bonds (via a DAO vote) in case violations to the social consensus were found
For now, we suggest to consider the following types of malicious behavior:
One concern with the current rules is that total user surplus does not directly consider clearing exchange rates outside CoW Protocol. As of the date of this post, CoW Protocol settles only a minority of total volume on Ethereum and as such, the uniform clearing prices (exchange rates) should be in line with what the users would get elsewhere (i.e., if they traded against publicly available liquidity offered by prominent protocols, such as Uniswap, Balancer, or Curve).
As an example, consider two user orders of the same size that can be matched directly against each other (i.e., without requiring external liquidity). The current objective function yields the same value for every clearing price between the two orders’ limit prices. Hence, there is some leeway for solvers to decide how to settle this trade, in particular how to distribute the surplus between the orders. This is commonly known as bargaining problem. However, the current exchange rate on the external market indicates where the clearing price should be, as illustrated in the following picture:
Here, the external market is represented by the trading curve of an AMM. A solution that sets the clearing price, e.g., to either o1’s or o2’s limit price is considered unfair and thus invalid, because one of the orders would then receive less than if matched against the AMM. By contrast, the fair clearing price clearly coincides with the current spot price of the AMM (or should at least be set between the prices offered according to its buy- and sell-curve).
Practically, we suggest considering at least the AMMs that are passed as part of the batch instance as the external market price reference.
Moreover, there is another situation in which two orders are matched against external liquidity in independent trading cycles and where surplus can be distributed in an unfair manner. We suggest adding an explicit constraint to mitigate it as part of this proposal (see the “local token conservation” section below).
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).
The internal buffers may only be used to replace legitimate AMM interactions available to the general public for the purpose of saving transaction costs.
Solvers may choose to include encoded transactions in their solution, by providing relevant calldata, but when doing so they must also truthfully specify the amounts transferred by each encoded transaction. This is required for the backend to be able to verify the proposed token conservation constraints, and can be checked retrospectively.
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.
A very natural requirement for a solution is that, for each traded token, the amount of units bought of that token is equal to the amount of units sold of that token. In other words, no tokens can be “created” or “destroyed” within an executed settlement (that is, before removing AMM interactions that can be fulfilled using the internal buffers). As it considers the sum of the traded amounts of all orders and all external liquidity, we refer to this condition as “global token conservation”. While this constraint has already appeared in the documentation (see here) and we have notified solver teams to respect it, it is currently not explicitly checked and enforced by the backend as part of the solution validation. This, in turn, poses a risk especially regarding a potential abuse of internal buffers. Therefore, in order to ensure correctness of the solutions and prevent buffer exploits, we propose to add the global token constraint for all tokens to the rules of the solver competition and implement a corresponding check in the backend.
As mentioned above, unfair shifting of user surplus from one order to another can happen in the case where two orders are trading against external liquidity on independent trading cycles. This means that an order that was necessary for generating a certain surplus might not end up “receiving” it. In order to mitigate such undesirable behavior, it needs to be ensured that for every user order, no external tokens “enter” or “exit” the trading cycles that the order is part of (and consequently, no surplus can be shifted between orders on independent trading cycles). This condition is referred to “token conservation per order" or “local token conservation”, and described in much greater detail in this technical blog post.
In order to provide stronger fairness guarantees for the users, we propose to add the local token conservation constraint for all user orders to be executed to the rules of the competition and implement the corresponding check in the backend.
We consider the proposed additions to the rules of the solver competition an important step towards a mechanism that provides verifiably fair solutions and that protects users and the protocol from potentially malicious solver behavior.
We are looking forward to feedback on these proposed changes by our CoWmunity!
Removed “Proposed Update #2: global token conservation” from the proposal (controversial and needs more research).