CIP-7: Allowing External Solvers

Governance Closed Proposals
, ,
1 
CIP: 7
title: Allowing External Solvers
author: fleupold
status: Voting
created: 2022-04-18

Update 26/04/2022

This proposal has been moved to the voting phase. Voting is available on cow.eth snapshot here

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 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 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.

Specification

Let’s revisit the current off-chain architecture (thanks to Ryan Sproule for the drawing):

1595Ă—1047 122 KB

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

  1. Its self custodial solver reward address
  2. The bonding pool’s address which may get slashed in case of misbehavior
  3. 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 your 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 Gnosis). At this point the driver can already start testing your solver using “shadow” traffic.
  3. 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)
  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 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.

Rationale

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.

7 Likes
2

Can you speak to other known or potential vectors for abuse there are here?

Separately, what exactly would be the conditions/process for a solver to be slashed? is this voted on by the DAO retroactively?

1 Like
3

The use of a bonding system is inevitable. The question will always be, how big should the bond be. Larger bonds will increase the barriers to entry for independent developers. Most probably members of the community will have a tough time getting access to such an amount of capital without having to contact VCs (angel investors) or getting approved by a bonding pool.

VC Route

Say, they approach a VC to help them cover the bond. Then, the VC will ask for proof that the solver is worth the investment. In this case, it will be crucial for community members to have access to metrics of how their solvers performed in the “shadow” run environment managed by CoW. That way, solvers can estimate their expected rewards and sketch an investment proposal. Is the CoW team working on a setup to make shadow run metrics public?

Bonding Pool Route

Here the Bonding Pool will probably replace the role of the VC (angel investor). I believe there will be some sort of return required by the Bonding Pool in exchange of the capital it is providing as bond. How to enable these sort of dynamics between bonding pools and solvers? How will a solver know who to contact in case there is a bonding pool available? In theory, there is no reason why Bonding Pool holders should reveal their identity (?). Either way, performance metrics from the shadow environment will also be crucial to awake any interest from these pools.

Overall, I agree that a bonding system is necessary, but this proposal will certainly make it harder for community members to deploy their solvers. Can we think of an alternative route that may not require the bond upfront? Say, by means of in-person interviews, identity checks, expected performance, etc? Consider the following setup:

  1. User must be approved based on in-person interview, identity check and validated expected performance from the shadow environment.

  2. User agrees to share 100% of the rewards with the a default pool until it covers 1M USD in rewards.

  3. When the solver achieves 1M in rewards, it can detach from the default pool to its own pool by paying some % fee to the pool that hosted it.

This is just an example. I understand it also has its complications, but I’m just trying to think of a more permissive way for community members to deploy their solvers.

4

Generally speaking we see two types of attack vectors:

  1. The inventory of the settlement contract, which comes from fee accrual and which is used to reduce gas costs via by trading internal buffers rather than interacting with AMMs for smaller amounts, can be “stolen”.
  2. The surplus of user orders (different between limit and execution price) until misbehaviour is noticed may be extracted by a malicious miner - this risk is somewhat mitigated by having the “driver” manage the submission keys.

Yes, the exact penalty would be voted on by the DAO. It should be mainly based on the created damage (to the protocol and users) and act in the best interest of the protocol to make sure benign solvers are not scared away (e.g. if there was a small bug in the code).

This proposal basically tries to combine the two routes (trustless and trust-ful, based on identity checks etc.) by offloading the judgement to the bonding pools. We expect Gnosis and CowServices to run such a bonding pool and to whitelist solvers based on the criteria you mentioned.

2 Likes
5

I’m wondering what do people think about using $1M worth of COW instead of interest bearing USDC as the underlying collateral?

On the one hand it would give a use case for holding/buying COW, on the other hand misbehaviour by a solver could have a negative impact on the token price and therefore reduce the value of the “insurance fund” after an incident.

2 Likes
6

It’s important that some of the collateral is COW but probably not all to reduce risk. We could do 50% USDC + 50% COW. To reduce risk even more, we could re-balance the bonding pool every quarter (or any time-period people believe is better).

V0 re-balancing concept, assuming 50% distribution (after some thought this solution can be quite punishing for the bonding pool owners, not something we should follow but I will keep it there for brainstorming reasons - nothing more):

  1. If there’s more COW than $500k in the bonding pool, the surplus moves back to the Solver Rewards Safe (replenishing the Reward Safe with some COW, it’s not going to make a big difference considering how much COW solvers get every week).
  2. If the amount of COW is less than $500k, some of the next rewards are captured and distributed to this “bonding pools” instead of going to solvers.

V1 re-balancing concept, assuming 50% distribution:

  1. If there’s more COW than $500k in the bonding pool, the surplus is used to buy more USDC (keeping $500k in COW).
  2. If there’s less COW than $500k and more than $500k in USDC, some extra USDC is used to buy more COW (if possible to get it back to $500k in COW but always keeping at leat $500k in USDC).

I don’t have doubts about the need of a “bonding pool” to put funds of solvers at stake (or something similar with a slashing mechanism). My doubt is more how should we reward solvers once this mechanism is in place? We can keep everything as it is, or we can do some adjustments to reward each “bonding pool” instead of rewarding solvers directly.

Since we don’t want all solvers using the same “bonding pool” because it’s not very decentralized. If we reward this entities/organizations/groups (clearly assuming their centralization) and let each one redistribute their rewards to solvers, investors, whoever it will probably create more competition. Even if it doesn’t create more competition, any slashing mechanism will be applied to the “bonding pool”, not to a single solver, meaning they should be able to find a solution potentially retaining rewards from some individuals that may be more accountable than others.

Also, giving rewards to this entities (instead of sending rewards directly to solvers) will allow them to apply different strategies. Some of this entities may take a share of the solvers reward allowing solvers to join without much upfront money while some may require them an upfront investment without taking any rewards from them.

1 Like
7

I think its a good idea to have the bonding pool at least partially in COW to give some usecase to the token.

2 Likes
8

Agree it’s important for some collateral to be COW but setting the bar to $1m worth of COW would be counterproductive in regards to decentralization. A new entrant would face prohibitive slippage in current market conditions (quick cowswap check for a $1m COW buy puts slippage at 30%).

1 Like
9

I like the idea of splitting the bonds 50/50 between COW and some yield bearing USDC (I’d suggest we require the bond owner to replenish missing CoW balance in case price goes down and request excess CoW balance if the price goes up). I also think it’s an interesting idea to reward these pools directly (rather than the solvers).

I would like to add to the proposal that the CoW DAO should actually fund an initial bonding pool itself which should be managed by a committee (CoW Services initially). We received real interest and some promising implementations from serious participants after the ETH Amsterdam workshop and would like to enable them to contribute as soon as possible.
Most participants do not have access to this type of capital and would therefore be candidates for a more traditional trust-relationship. The DAO could retain ~5-10% of the accrued rewards in return for providing the bond.

3 Likes
10

I agree with the re-balance mechanism and also the CoW DAO bonding pool suggestion. Nevertheless, this 5-10% retention seems low to me (assuming this solvers don’t put any capital at risk).

For instance if CoW DAO bonding pool only retains 5% of the weekly rewards from solvers in the bonding pool (while the solver doesn’t invest a single COW or USDC), why would a group of investors own a bonding pool retaining 10% or even more of the rewards?

If we start rewarding bonding pools (instead of solvers directly) and if we fund a Bonding Pool we should consider:

  • How many solvers can we accept in our bonding pool at the same time? We may not set a limit but we should consider this possibility because we will take risk, the more solvers we have in the same bonding pool higher is the risk we take.
  • For How Long we will allow them (we probably want them to move to their own bonding pool sooner than later)?
  • For How Long can a Solver stay in our bonding pool without solving anything (if we allow solvers not efficient enough for many months we can be taking unnecessary risk)?
  • Should we give more than just one way to join the bonding pool, as example: No Capital, we take X% of rewards. Or should we consider different levels of retention considering their capacity to put some capital at risk (if so, should we make more than one bonding pool for each type of solvers, eventually limiting this to just 2 bonding pools for solvers with and without capital)?
  • And eventually more. We probably will be better discussing that in a CIP just for the CoW DAO Bonding Pool?
1 Like
11

Agree, that it makes sense to separate the process of how solvers can be added and a concrete bonding pool in two different CIPs.

If there are no objections, I’d move this proposal into Phase 2 tomorrow. To summarize:

  • Bonding pools place $500k cUSDC and 1.5M COW token into a Safe that is owned by CoW DAO
  • Bonding pool creators can then signal liability for individual solver addresses, which will subsequently be allow-listed as solvers by the allow-list manager (Solver Rewards Safe)
  • Bonding pool creators can also signal the removal of solvers from their liability (they remain liable until the solver is removed)
  • If misbehaviour is suspected, all solvers belonging to the liable bonding pool get temporarily suspended. The DAO will vote on concrete penalties.
  • If bonding pools want to exit, all solvers they are liable for will first get unlisted and a vote to refund their bonds will be passed to the DAO.
  • CoW rewards will be paid out to the bonding pool owners (who forward them to their solvers). Gas refunds will be paid out to the solver’s submission address directly.

The proposal will not result in any on-chain transaction, but rather define the process on how the allow list should be managed going forward.

2 Likes
12

Snapshot proposal is live: Snapshot

1 Like