CIP-Draft: Solver rewards on all chains

CIP: <to be assigned when moved to phase 2>
title: Solver rewards on all chains
author: Haris Angelidakis, Andrea Canidio, Felix Henneke, Bram van den Berg
status: Draft
created:  2024-11-11

Simple Summary

CoW Protocol is currently operating on Ethereum mainnet, Gnosis Chain and Arbitrum One, and with its state-of-the-art solver competition, users on these chains are provided with a great quality of service. A key driving force behind the evolution of the solver competition has been the solver rewards program that is currently live on mainnet, with the latest specifications described in CIP-36, CIP-38 and CIP-44.

Since the program has worked very well on mainnet, we propose to extend it to the rest of the chains the protocol is operating, namely Gnosis Chain and Arbitrum. This would allow existing solvers to further improve on each of these chains, and moreover, it would incentivize new solvers that are potentially specialized in certain chains and do not necessarily (want to) participate in the mainnet competition to join any non-mainnet competition without having to worry that there are no rewards allocated for them. Ultimately, the protocol will benefit as this would establish very strong competition on a per chain basis.

Specifically, we propose to use the same rewards mechanism that has already worked very well on mainnet, with the only adaptation being the caps, that will become chain-dependent, and will always be denominated in the native currency of each chain. We propose that the initial values of these caps will be [BE DETERMINED IN THE NEXT FEW DAYS AFTER THE CONCLUSION OF SOME EXPERIMENTS]
and each change on those would require a new CIP.

Moreover, and given that bonding pools currently exist only mainnet, we propose that vouching for all solvers, regardless of chain they are operating on, continues to happen on mainnet, thus establishing an onchain link between solver addresses, bonding pools, and respective rewards addresses, making vouching transactions on mainnet the single source of truth for this.

Motivation

In order to maintain best possible service, the protocol is relying on a strong and diverse competition among solvers. As solvers are becoming more and more sophisticated, it is expected that they need funding in order for them to be able to continue operating and providing their services to the protocol. CoW DAO so far has chosen the option of incentivizing and rewarding solvers via a second-price auction mechanism, that allows solvers to truthfully bid (in most cases) in each batch auction the protocol is creating, thus minimizing the potential of solvers gaming the mechanism in order to profit at the expense of users.

However, these incentives are currently available only on mainnet. This means that competition on other chains is not so robust, and solvers, in the lack of other sources of income, could, in principle, start turning the auction into a first-price auction where they deliberately provide slightly worse prices, in order to be able to collect some profit themselves in case they win the auction so that they can cover their expenses.

Thus, it is clear that in order to maintain a healthy competition on all chains that the protocol operates, as well as attract new solver teams that are not necessarily interested in participating in the mainnet competition, a rewards mechanism per chain is needed.

As the current mechanism on mainnet has proved to be very successful, it is natural to continue using that mechanism on other chains as well.

Specification

The proposal consists of the following:

  • Use the solver rewards mechanism that is currently active on mainnet to provide rewards on Gnosis Chain and Arbitrum One, and these rewards should always be paid out to solvers in COW, with the accounting taking place once a week (similar to mainnet). Specifically, the accounting weeks on all chains will be aligned and will be from Tuesday midnight UTC to next Tuesday midnight UTC, similar to how accounting weeks are currently set up on mainnet.

  • At a high level, treat the mechanisms on all chains as a single mechanism that is parameterized by the 4 caps:

    • Upper cap on the per-batch reward
    • Lower cap on the per-batch reward
    • COW cap on the per-quote reward
    • Native-currency cap on the per-quote reward

    This implies that a CIP that proposes a change to the mechanism automatically applies to all chains, unless there is a chain-specific clause in that CIP (such as chain-specific caps).

  • The above unification also means that whenever the protocol deploys on a new chain, the existing rewards mechanism should automatically be enabled on that chain from day 1, with the corresponding caps being selected conservatively by the core team.

  • The guiding principle for selecting caps should be that the amount of rewards being given out every week is fully covered by the average protocol revenue on the corresponding chain on that week, on average. In case of limited data, caps should be conservatively selected so as to prevent severe overspending (where again, overspending is defined with respect to the protocol revenues on the corresponding chain).

  • We propose to use the following caps on Gnosis Chain:

    • TO BE COMPLETED
  • We propose to use the following caps on Arbitrum:

    • TO BE COMPLETED
  • If the CIP successfully passes, we propose to retroactively compute and pay the rewards on Gnosis Chain as proposed by the mechanism for all batch auctions that took place after October 15, 2024, 00:00 UTC. Similarly, we propose to retroactively compute and pay rewards on Arbitrum as proposed by the mechanism for all batch auctions that took place after October 1, 2024, 00:00 UTC.

  • To determine which bonding pool B and rewards address R a solver address S on chain X is linked to, we propose that a vouching transaction on mainnet should be executed that links address S with bonding pool B and rewards address R. Together with the whitelisting of address S on chain X, this would then be interpreted as follows: the bonding pool B that exists on mainnet vouches for the solver address S that operates on chain X, and any rewards that solver S will claim on chain X should be redirected to the rewards address R on the corresponding chain X.

2 Likes

Supportive. I would like the actual CIP vote of any ammendments/changes to the rules to become a vote on whether a pull-request to docs/docs/cow-protocol/reference/core/auctions at main · cowprotocol/docs · GitHub should be merged (starting with this one).

This way we can make sure the rules of the games are clearly specified in Batch Auction mechanism | CoW Protocol Documentation and a solver team doesn’t have to travel back in time and apply all historic CIP in their mind in order to retreive the current rules of the game. At the same time version control will allow to keep a full record of historic rules.

1 Like