Skip to main content

Solver competition rules

All solvers participating in the solver competition must abide by certain rules. In this section, we outline all these rules, which are naturally split into three classes:

  1. Those enforced explicitly by the smart contract
  2. Those enforced by the off-chain protocol infrastructure
  3. So-called social consensus rules enforced by governance

Smart contract​

  • Limit price constraint: this rule enforces that an order cannot be executed if its limit price is violated.
  • Solver submitting a transaction needs to be whitelisted (the process about how a solver can get whitelisted is described here).

Off-chain protocol​

  • Uniform clearing prices (UCP): this rule is an integral component of the protocol, and specifies that there is one clearing price per token per batch.

  • A solution is valid only if it contains at least one user or CoW AMM order.

  • Every valid solution is associated with a score relative to the amount of surplus it generates for the users (as described in CIP-38. These solutions are ranked in decreasing order of their scores. The solver whose solution has the highest positive score is declared the winner of the batch auction, winning the right to execute its solution on-chain.

  • Deadline: Solvers that win an auction will receive a deadline by which they must settle the auction on-chain. If the transaction is not observed on chain before the deadline block is mined, then the solution will count as not submitted and the solver will be penalized.

  • The solver that provided the winning solution is rewarded according to a second-price auction mechanism that the protocol uses; for more information see here.

  • Internalization of interactions: a solver is allowed to "internalize" interactions. Concretely, if there is enough balance of the sell token of such an interaction in the settlement contract, then a solver can signal an internalization of such an interaction, which effectively means that the protocol is willing to buy and sell tokens stored in the settlement contract. The effect of such interactions is evaluated in what we call slippage accounting (see next point).

  • Slippage accounting: With the exception of protocol, partner and network fees paid by users, any token imbalance within the settlement contract that is the result of a settlement is accounted for under the term "slippage accounting", and is fully owned by the corresponding solver, as specified in CIP-17. More information on the full accounting process, including slippage, can be found here.

note

The deadline for solutions depends on the network and is set as a specific number of blocks after the current block at the time of sending the settle request to the solver:

  • Mainnet: 3 blocks
  • Arbitrum: 40 blocks
  • Gnosis chain: 5 blocks
  • Base: 20 blocks

Governance​

Social consensus rules are not enforced by the smart contract or the autopilot. However, by voting on them in a CoW improvement proposal (CIP), CoW DAO has decided that these rules should be followed to ensure a healthy competition. For that, the core team has developed monitoring tools that check every single on-chain settlement and flag suspicious ones.

caution

At CoW DAO's discretion, systematic violation of these rules may lead to penalizing or slashing of the offending solver.

  • Provision of unfair solutions (CIP-11). Uniform clearing prices computed by solvers should be in line (or even better) than what the users would get elsewhere. This becomes particularly relevant for solutions where CoWs happen, i.e., when some volume is settled as part of a CoW and not by routing through an AMM. This rule is often referenced as "EBBO" (Ethereum Best Bid and Offer), and the AMMs that "should" be considered by solvers when computing an execution route for an order are referenced as "Baseline liquidity". Baseline liquidity is defined with a set of protocols and a set of so-called base tokens, such that for every protocol and every order, the following pairs are considered:

    • sell token / base token
    • buy token / base token
    • sell token / buy token

    Base protocols and tokens​

    The following detail sections list the protocols and base tokens that are considered for Ethereum Mainnet and Gnosis Chain:

    Ethereum mainnet baseline protocols and tokens
    Gnosis Chain baseline protocols and tokens
    Arbitrum baseline protocols and tokens
    • Protocols: Uniswap v2/v3, Sushiswap, Swapr, Balancer v2, Pancakeswap
    • Base tokens: WETH, USDC, USDT, DAI, GNO
    Base chain baseline protocols and tokens
    • Protocols: Uniswap v2/v3, Balancer v2
    • Base tokens: WETH, USDC, DAI

More details about how a certificate of an EBBO violation is computed, and what are the steps taken in case such a violation occurs can be found in this section.

  • Inflation of the score (CIP-11). Using tokens for the sole purpose of inflating the score of a solution or maximizing the reward is forbidden (e.g., by creating fake tokens, or wash-trading with real tokens).

  • Illegal use of internal buffers (CIP-11). The internal buffers may only be used to replace legitimate AMM interactions available to the general public for the purpose of saving transaction costs, and also to allow for the successful execution of settlements that incur some slippage. However, systematic and intentional buffer trading with tokens that are not safe, although will be accounted for as slippage, is discouraged as it poses a significant inventory risk to the protocol, and solvers that do so can be flagged and potentially slashed. In general, any attack vector to the internal buffers that is created by a solver can be considered a malicious and illegal behavior.

  • Local Token Conservation, aka illegal surplus shifts (CIP-11). Due to the nature of batching, a solver can intentionally transfer surplus among orders that share a common token. This is not allowed, and non-trivial surplus shifts can be penalized and can lead to solver slashing.

  • Pennying/overbidding (CIP-13). Pennying or the evolution of it in the context of CIP-20 known as overbidding, is the intentional inflation of the reported score, by a solver, with the hope that their solution will win and that solver rewards, and/or the possibility of positive slippage, will cover the loss that they seem to be committing to. Such behavior does not benefit anyone and thus, systematically doing so can lead to solver slashing.

  • Other malicious behavior (CIP-11). 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 CoW DAO. A concrete example of such is a solver intentionally not including the pre/post hooks associated with an order.