CIP: 7 title: Allowing External Solvers author: fleupold status: Voting created: 2022-04-18
This proposal has been moved to the voting phase. Voting is available on cow.eth snapshot here
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 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).
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 user rather than being extracted by miners and searchers, it also allows for crowdsourcing of new onchain liquidity sources.
We believe that 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 solvers that are operated by Gnosis (the company that CoW spun out of) 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 we absolutely want to open up the competition in a permissionless manner, we need to do so with care and security deposits in place. At the same time, we want to keep the barrier to entry low, so that people with little resources can contribute to the competition as well.
Let’s revisit the current off-chain architecture (thanks to Ryan Sproule for the drawing):
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 worth $1M USD (or some interest bearing version of it). The bond should be stored in a Gnosis Safe where the sole owner is the Solver Rewards Safe. 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.
Initially, we expect Gnosis and the CoW Services team to run such a bonding pool (and add external contributions based on their judgment), but external contributors are welcome to do so as well.
A solver is therefore defined by three components
- Its self custodial solver reward address
- The bonding pool’s address which may get slashed in case of misbehavior
- The solutions submission address (managed by the driver)
The process for allowlisting a solver from a developer perspective would then be as follows:
- Get your solver running based on testing traffic (instructions are beyond the scope of this proposal)
- 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 Gnosis). At this point the driver can already start testing your solver using “shadow” traffic.
- Create your own or get the creator of an existing bonding pool to vouch for your solver (they will sign a transaction containing your solver’s submission key and rewards key)
- 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 reward address on a weekly basis). Rewards aren’t paid to the submission address as its private key is not under the implementers control.
This process can likely 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 should be decided upon by the DAO and executed by the rewards payout Safe.
The protocol needs to have reasonable insurance against malicious solvers. At the moment the trust put into Gnosis solvers stems from their continued support and engagement in the protocol. In the absence of such established trust, we believe that a bond of $1M USD provides sufficient security guarantees.
Since we don’t want every solver to provide that much capital upfront, we suggest using “bonding pools”. They make the system permissionless but still allow 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.
While the proposed process is already quite complex, we hope it strikes a reasonable balance given the current architecture of the system and the desire to enable external solvers as quickly as possible.
Any suggestions or feedback on how to simplify the approach is of course more than welcome.