CIP-7: Allowing External Solvers

Simple Summary

As of March the protocol is rewarding solvers with 100 CoW per solved batch. This has accelerated the interest of the community to participate in the competition and run their own solvers.

Currently, solver addresses need to be allow-listed in order for the settlement contract to accept their transactions. The allow-list is owned by CoW DAO. Additionally, solvers can be added and removed by a "manager address", which is currently the same Safe that is doing the rewards payouts.

This proposal aims to formalize the process with regards to how solvers can get added to the allowlist. In summary, given the potential damage a malicious solver could incur on the protocol, we require solvers to be part of a “bonding pool” which provides an equivalent of $1M (split between COW and cUSDC) as a guarantee in case of misbehavior.

When malicious behavior is suspected, all solvers that are part of the affected bonding pool may immediately be suspended and the DAO is consulted as to whether the bond should be slashed (to make up for potential damages caused to traders and/or the protocol).

Motivation

One of the main value propositions of CoW Protocol comes from the so-called “solver competition”. Not only does it ensure that “trader surplus” (difference between limit price and price at execution) is given back to the trader rather than being extracted by miners and searchers, it also allows for crowdsourcing of new onchain liquidity sources.

In order to be able to compete in terms of price and cost with other fast moving protocols and aggregators in the space, it is important to ensure that external people are incentivized to contribute to the price competition and liquidity discovery.

CIP 2 laid the groundwork for this by rewarding the winning solver with 100 COW tokens per batch. However, at this point only select solvers are allowed to participate in the competition. The main reason for this is that there is still a significant amount of “damage” a malicious solver could induce on the protocol and therefore some trust is needed.

While the users’ funds and limit prices will always be respected by the smart contract code, important rules of the competition are only enforced off-chain (e.g. uniform clearing prices, choosing the solution with the highest surplus, fair surplus distribution). Moreover, the settlement contract contains significant balance in the form of collected trading fees.

While CoW Protocol absolutely wants to open up the competition in a permissionless manner, it needs to do so with care and security deposits in place. At the same time, it wants to keep the barrier to entry low, so that people with little resources can contribute to the competition as well.

Specification

Let’s revisit the current off-chain architecture:

Users place orders into the CoW orderbook via the API. A centralized component periodically polls the current orderbook and sends requests to each registered solver to find a solution for this batch. All submitted solutions are ranked by the "driver" with regards to the defined objective value and the winning one is submitted on chain (the driver stores a submission address key for each solver).

While in the future it may be nice if each solver was responsible for submitting solutions themselves (which would allow for competition on the submission strategy), this would require significant engineering of the system and can therefore likely not be achieved in the timeframe envisioned for this proposal.

We therefore propose that the driver remains the manager of the “submission keys” for each solver and carries out the ranking and selection of valid solutions. The driver verifies that the solution simulates successfully on the latest block, that clearing prices for user orders are indeed uniform and that the posted prices don’t differ drastically from the prices estimated by the orderbook (the concrete rules for what constitutes a valid solution may evolve in the future). This measure already drastically reduces the damage that a malicious solver can cause (e.g. by ignoring the ranking of the competition). Yet, even the most sophisticated checks in the driver cannot guarantee that a solution is not causing any harm to the protocol. In order to ensure good intent, solvers should be bonded by a collateral consisting of $500,000 worth of cUSDC and 1.5M COW tokens (worth ~$500k). The bond should be stored in a Gnosis Safe where the sole owner is the CoW DAO. In order to be more capital efficient each creator of such a “bonding pool” may vouch for more than just one solver. However, if one of their solvers is suspected to act maliciously all solvers that belong to the same pool will get suspended until the DAO decides if and how to use the bonding pool’s funds to recover any damage.

A solver is therefore defined by two components

1. The bonding pool’s address which may get slashed in case of misbehavior
2. The solutions submission address (managed by the driver)

The process for allowlisting a solver from a developer perspective would then be as follows:

1. Get a solver running based on testing traffic (instructions are beyond the scope of this proposal)
2. Provide your solver’s API endpoint and the Ethereum address you want to receive rewards via the CoW Discord and receive your solver’s public submission key (private key will be managed by the "driver" component).
3. Create your own or get the creator of an existing bonding pool to vouch for your solver (by signing a transaction containing your solver’s submission key).
4. Your submission address will be added to the solver allowlist and enabled by the driver in production. You need to make sure to fund the submission address with sufficient ETH to cover the gas costs (gas costs for successful transactions are refunded to your submission address on a weekly basis). COW rewards are paid to the bonding pool (negotiation for a payout/forwarding structure between implementors and pools are beyond the scope of this proposal).

The listing process may eventually be automated by smart contracts. Initially we suggest that the solver reward Safe remains responsible for updating the allowlist as soon as a solver has been vouched for by a bonding pool and unlist them when they suspect misbehavior.

Any penalty to the bonding pool should be decided upon and executed by the DAO. The DAO shall refund the bonding pool's balance to the initial creator upon request (after unlisting all its solver and verifying no wrong doing was done). Bonding pools can also "un-vouch" for solvers via an onchain message (they remain penalizable for its actions until the solver is removed from the allow-list or vouched for by another pool).

Rationale

The protocol needs to have reasonable insurance against malicious solvers. At the moment the trust put into solvers stems from Gnosis' continued support and engagement in the protocol. In the absence of such established trust, it is believed that a bond of ~$1M USD provides sufficient security guarantees.

By using “bonding pools” the system is made permissionless but still allows entities with less resources to get allow-listed as long as an existing pool vouches for them. This way we can allow for both trustless and delegated trust-based solvers.