CIP-2: Solver Rewards

CIP: 2
title: Solver Rewards
author: Felix Leupold
status: Active
created: 2022-02-21

Update 11/03/2022

Vote passed with 65M votes in favour (134k against) and has been executed at: Ethereum Transaction Hash (Txhash) Details | Etherscan

Simple Summary

The purpose of this proposal is to ensure continued solution submission by solvers powering CoW Protocol by refunding them the gas cost for solution submission plus a fixed 100 CoW reward for every winning settlement. This proposal is aiming at solvers operating on mainnet only.

Motivation

One of the core parties in the CoW Protocol are the so-called solvers: Entities that compete for the best execution of user orders and eventually submit the on-chain transaction settling their trades. Solvers are run by external parties (currently still controlled by Gnosis) and incur significant costs in the form of transaction gas fees from their operation.

With CoW Protocol spinning off from Gnosis, it is imperative to quickly set up an adequate incentive scheme so that solvers continue to participate in the protocol.

Cow Protocol Revenue & Cost Structure

At the moment CoW Protocol is charging users a fixed fee per order denominated in the sell token. That fee is taken atomically as part of the settlement transaction if and only if the order is executed. The fee is currently computed by the protocol’s orderbook API by estimating the gas costs the user would incur by trading on a DEX Aggregator and converting that gas fee into the sell token.

The fees are collected in the settlement contract. Solvers have access to those balances and could therefore withdraw the fees. However, due to the fact the the protocol currently subsidizes trades, fees don’t fully cover the expenses solvers incur (cf. Dune):

While the exact amount of the subsidy - and therefore the expected loss - is easily configurable, changing the subsidy strategy is outside the scope of this proposal.

On top of revenue in the form of fees and cost in the form of gas costs, solvers and the protocol have a few other operational factors that affect their profitability (we ignore server costs as they tend to be minor):

  • Failed transaction costs: Failed settlements yield no trading fee, but still cost gas.
  • Positive/Negative Slippage: Orders are executed at the price the solver reported in the off-chain competition. The actual achieved price on-chain may differ (e.g. when the AMM’s price moved in the meantime, or the solver got sandwiched, etc). Currently the protocol keeps positive slippage and pays negative slippage from the token balances it accrues from fees.
  • Inventory Risk: Since the fee is taken in the sell token but gas costs are paid in ETH, revenue is not captured in the same unit as cost. Fluctuations in token prices may therefore affect the value of ETH or USD stored in the contract. Moreover, some solvers currently fill orders from existing balance in the settlement contract to avoid the gas cost involved with interacting with an AMM. Moving funds across buffers also incurs an inventory risk.

How to reward Solvers?

We suggest to begin by rewarding solvers with a fixed CoW token promise (100 COW per solved batch) and to refund them their entire successfully executed settlement transaction cost. Reimbursements will be done in ETH and gas costs can be easily tracked via Dune.

In return, all balances that are accrued inside the settlement contract are considered protocol revenues and belong to the CoW DAO (>$11M revenue to date) going forward. However, all fees accrued before the target date for this CIP still belong to Gnosis. Gnosis will withdraw as many balances as it deems reasonable from the settlement contract prior to the target date. As of then, the balances fully belong to CoW Protocol.

Inventory Risk

In order to minimize the inventory risk of balances held in the contract, we propose to restrict the list of tokens with which solvers are allowed to perform gas cost optimizations by not routing the trades via an AMM (“internal buffers”) to a hardcoded token list of tokens the protocol is willing to hold.

Moreover, solvers are only allowed to replace trades at a “real” exchange rate they found on-chain. Failure to prove the existence of such liquidity on any of the blocks between the start of the auction and the solution submission, results in the deduction of the traded amounts (in ETH) from the gas refund.

Slippage

Solvers are expected to not incur negative slippage on average over all trades during the reward period. While positive and negative slippage may occur on a per batch basis, when tallied up over the entire reward period, a total negative slippage may be withheld from the reward. A total positive slippage belongs to the protocol. Slippage will be tracked using a Dune dashboard.

Specification

COW DAO will fund a Gnosis Safe that is controlled by the Cow Protocol development team with 500 ETH and 7M COW (~10 weeks of runway) and whitelist this Safe as a solver on the protocol. The team will periodically withdraw tokens of which the contract holds significant balance (>$1000) and convert them into ETH. The converted ETH together with the initial funds will be used by the team to - once a month - refund all participating solver addresses the equivalent of their gas amounts spent.

To summarize the rules of the refunds:

  1. As of March 1st, solvers receive a full refund on all ETH spent on gas for successful Mainnet settlements
  2. Additionally, solvers receive 100 COW tokens for every successful Mainnet settlement.
  3. Payments happen in the first week of each month (first payout would happen in April).
  4. Solvers are allowed to trade internal balances only from a specified token white list (e.g. this list)
  5. Positive and negative slippage for each solver is tallied up over the whole rewards period. Profits stay in the protocol, losses will be deducted from the gas refund.

Rationale

With CowSwap spinning off from Gnosis it needs a quick and pragmatic solution for keeping solvers incentivised to pay large amounts of ETH per week in transaction fees. This proposal is very close to the previous modus operandi where a large portion of the operational cost would be covered by swapping internal balances for ETH, and previously Gnosis (now the CoW DAO) would provide ~50 ETH per week in additional funds to cover the loss mainly arising from fee subsidies.

While Gnosis solvers are no longer willing to cover these costs without a reward, they are generally still very much aligned with the success of the protocol and can be trusted to operate in good faith. While we believe a more sophisticated and adversary prone reward system is needed in the future, we would like to focus our short term development on building out new core features and bringing more people to CoW Protocol while at the same time offering a basic but appealing reward system for solvers.

We want to make it as easy as possible for external solvers to join the CoW Protocol. By not having them deal with the complexities from inventory risk and slippage we think new participants are more encouraged to join.

We believe that this proposal is both simple and effective for all parties involved and therefore achieves these goals.

14 Likes

I support this proposal, and think it’s well thought out. Having reviewed the specified token list it seems too restrictive. Isn’t it more practical to use the curated token list integrated into most DEX’s at tokenlist.org to support traders using the protocol?

6 Likes

I agree that the token list proposed may not be ideal. For example it contains sEUR which is very illiquid and thus “risky”. When it comes to narrowing down the tokens in the list, I think careful research should be done and possibly also having a fixed set of rules for a token to be included there. For example:

To be supported for internal balances the token must be:

  1. Sufficiently Paired: exist within a liquidity source paired directly with a “base token” where base token is a very short fixed list of trusted tokens (say for example { WETH, USDC, DAI, USDT, WBTC, GNO, CoW }

  2. Sufficiently Deep: have at least T total USD in a Liquidity source natively supported by the protocol.

  3. Sufficiently Supported be in the intersection of at least N token lists from tokenlist.org (the list suggested by @netrunner.eth)

These are just a few ideas. Without having looked very closely, I can say that sEUR likely fails 2/3 of the above.

I might also suggest making the list somewhat dynamic - since some of these conditions above can change from one block to the next.

4 Likes

I would like to point some concerns about this specific topics.
Assuming it’s highly expected Solvers will sell part (if not all) of this distribution to pay their expenses, 1)+2) will create a Monthly Selling pressure on the COW token for a specific short period (first week of each month). Diluting this distribution into weekly payments is eventually better for everyone. Less delay between payments should help Solvers to keep doing what they do and a regular weekly distribution seems less impactful for the market.

I’m considering the token distribution would be between 420k-560k COW per week. Doing that payment on a Monthly basis, it would be something between 1.8m and 2.5m COW tokens on the first week of each month (correct me if I’m wrong).

From a market perspective I guess another solution would be if this COW tokens are converted into ETH (sold) on a daily basis and then the payment is done with that ETH instead of COW tokens. Nevertheless a weekly payment is probably better for Solvers. I’m not a solver so I can only guess.

I understand the urgency of this matter so I will not add anything else besides that I’m not sure if this reward mechanism aligns with the idea that the CoW protocol will do better with larger batches. I guess this rewards can/should work until a better solution is found.

4 Likes

Thank you for the comments so far. Both the concrete choice of the white list as well as the payout cadence are definitely things that are easy to adapt.

Alex Herrmann from our team did an analysis recently which actually suggests “less is more” when it comes to the effectiveness of the internal buffer whitelist for achieving gas savings. I hope he can share his work here.

Regarding the payout cadence, the reason was mainly to reduce manual effort. Doing these payouts once a month is easier than once a week (we are really looking for a senior production engineer to help us automate these kinds of processes).
The argument about condensed CoW sell pressure is valid. I’d argue that the main expense is gas which is already being paid for separately (you are right that the way the DAO raises this ETH may cause sell pressure). At least from Gnosis we heard they would only sell CoW if they had to cover gas costs from it (but of course this may not be true for other future solvers).
Another upside of a shorter accounting period would be that solvers don’t have to advance that much gas.

2 Likes

why only on mainnet? :cry:

My understanding is that this proposal is only for Mainnet, and not that that there are no solver rewards planned for other networks.

Specifically, Mainnet is more urgent at the moment because of the high gas costs, so we need a plan to reimburse solvers for gas fees in order to keep them operational. On other networks (like Gnosis Chain for example) the gas costs are so low that this is not as urgent (100$ of gas money can keep you running for months).

I would expect a future proposal to include a plan for solver rewards on other chains.

4 Likes

Maybe we should consider to add the obligation for solvers to become eligible for rewards only if they also run the same solver on Gnosis Chain

3 Likes

We can add a reduced CoW reward for Gnosis Chain into the proposal (maybe 10 CoW per solution?). The reason for not including Gnosis Chain is as @nlordell said, plus that we thought it might be worthwhile to try the mechanism on mainnet first. Given the cheap gas fees and lower activity on gchain, we might have to also consider the “value” of a batch for the reward to avoid wash trading by solvers.

As long as Gnosis is running most of the solvers, we can be pretty sure they will support Gnosis Chain even without a reward.

2 Likes

Powerful plateform
Nice project ever with great potential. congratulations to the team for their efforts and dedication and highly appreciated the visionary thought of the projector and it will create history :metal:it will go to moon​:rocket:

Agree, daily, or at least shorter time intervals as a month, sellings will be better for the market, but independent of the time intervals it would also save gas if COW for all solvers are changed in batches and distributed as ETH.

1 Like

I can probably understand what the proposal said, and I feel it is more suitable for the main network. After all, the GAS of ETH is too high.

Given the urgency of this proposal (Gnosis needs reassurance that it will receive gas refunds in order to continue running solvers as of March 1st), I’d like to move the proposal to to a vote shortly after the participation agreement vote has started and potentially re-iterate on details later on.

Unless there is more discussion items, I’d suggest to move to the next stage later this week with the following 2 changes:

  1. Accounting period for the payouts shall be 1 week instead of 1 month
  2. The concrete token list shall be the top 50 traded tokens on CowSwap so far that have a Dune price feed. The only tokens in that list that are not part of the already allowed buffer list are TOKE, RBN, SYN and FOLD which all have proven to be real tokens.

Please feel free to comment with an alternative token list together with an explanation why this would be better suited.

3 Likes

I also think this is a good enough reason to not include the Gnosis Chain COW solver rewards in the proposal for now, since I don’t feel like there has been enough discussion on how to structure those rewards in a way that we can provide wash trading (given the very low gas costs on Gnosis Chain at the moment).

Regarding the changes:

  1. Agreed.
  2. I would slightly prefer a stricter list at first and then we could have future proposals to add more tokens. That being said I don’t really feel strongly, nor have any good reason besides intuition for this so for me this isn’t a “blocking concern” for me. However, I would propose we snapshot the list now. I noticed it is based on # of trades using it as a buy token, so it is quite easily gameable.
1 Like
  1. The concrete token list shall be the top 50 traded tokens on CowSwap so far that have a Dune price feed . The only tokens in that list that are not part of the already allowed buffer list are TOKE, RBN, SYN and FOLD which all have proven to be real tokens.

I think the concrete instance of the list should not be part of the proposal. Maybe the community gets new insights and then wants to quickly change the list. E.g. one token could have a hidden bug that only reveals itself in the future, and then we want to have the flexility to remove it quickly.

I think the list should be posted in the get_auction endpoint of the orderbook service.

Agreed on snapshotting the list. I have taken a snapshot of that list yesterday before posting. I will also add the CoW token (0xDEf1CA1fb7FBcDC777520aa7f396b4E015F497aB) to this list.

I think the list should be uploaded to IPFS and pinned under an ENS name that is controlled by the same multisig that is doing the payouts. This way changes to the list can be done quickly without inflating the auction response and there will still be an onchain record on when this list changed.

If you propose to keep the concrete list outside of this proposal, what do you suggest as a rule for internal buffer trading instead? Should solvers not be allowed to do any internal buffer trading? Or should they allowed to trade with any token they want? For gas reasons, only the latter makes sense in my opinion. Would the DAO be okay with that (trusting solvers to chose a sensible list internally)?

I think this is a great idea. Using an IPFS record in an ENS domain is a great way to stay transparent (all changes to the list are public, as the record updates are part of the blockchain) while allowing us to quickly respond and update the list if needed.

I think this an idea worth discussing. I’m not sure it would be ideal to include it the get_auction response (because of how static this information is), but having a convenience API endpoint for downloading the list served up buy api.cow.fi is a good idea in my opinion.

Since the solvers are assumed to be non-adversarial for now, I think this is also OK for the moment. However, once other solvers start participating, then I do think we should have a formal list (hosted on IPFS as you suggested, I think that was a very good idea for this). With that in mind, maybe it does make the sense to keep the actual list out of the proposal so that its scope is smaller. We are already assuming the solvers would act in good faith, so they should pick a sensible list for this. Also, this helps the Gnosis solver team keep on working towards optimizing buffer usage and be more dynamic about the actual list.

1 Like

Within the cowswap team, we also did a small study on the optimal token-list:

We re-simulated the current trades from cowswap with different buffer configurations and then derived specific key metics for the protocol. Each buffer configuration had two parameters: a certain number of market makable buffer tokens and the overall USD value held within the buffers.
In the simulations, the solvers would only trade against buffers if the buffer token is within this market makable buffer token list. The initial buffer distribution was set by funding each buffer token with an equivalent USD amount.

For each given configuration, we calculated with the help of the simulation the following key metrics:

  • The ratio of AMM trades that can be replaced by internal buffer trades vs all AMM trades
  • The ratio of trading volume that was traded in replaced AMM trades vs the total volume
  • The yearly revenue for the protocol, assuming the AMM fees of the replaced AMM trades would be pocketed by the cowswap protocol
  • A rough estimation of the gas savings compared to the current situation: Currently, we have roughly 1000 buffer tokens and 1M USD value spread between them.

The simulation result-table for re-simulating the transactions between 10th of FEB and 18th of FEB can be seen here:

Buffer Investment [USD] AllowListed Buffer-Tokens Ratio Internal Interactions vs Total # Interactions Ratio Internally Matched Vol Fee Revenue [USD/Year] Ratio of saved gas costs compared to non-buffer trading Expected Gas savings compared to today
$1,000,000 10 0.2463 0.21 1583284.96 0.86 8.00%
$1,000,000 15 0.2517 0.2 1511037.26 0.85 9.00%
$1,000,000 22 0.2572 0.2 1483512.41 0.85 9.00%
$1,000,000 44 0.2486 0.16 1194866.39 0.86 8.00%
$1,000,000 49 0.2489 0.16 1154903.6 0.86 8.00%
$1,000,000 88 0.2448 0.14 1015372.02 0.86 8.00%
$1,000,000 143 0.2286 0.12 893138.36 0.87 7.00%
$1,000,000 275 0.2083 0.1 705112.88 0.88 6.00%
$1,000,000 1500 0.0956 0.04 310684.01 0.94 0.00%
$1,300,000 10 0.255 0.23 $1,691,912 0.85 9.00%
$1,300,000 22 0.2777 0.22 $1,636,452 0.84 10.00%
$1,300,000 275 0.2393 0.11 $837,385 0.86 8.00%
$1,300,000 1500 0.1136 0.05 $353,391 0.93 1.00%
$10,000,000 10 0.3748 0.49 $3,611,276 0.79 15.00%
$10,000,000 22 0.4288 0.45 $3,306,199 0.76 18.00%
$10,000,000 275 0.5225 0.32 $2,374,118 0.71 23.00%
$10,000,000 1500 0.3142 0.15 $1,119,091 0.82 12.00%
$50,000,000 10 0.4567 0.6 $4,419,057 0.75 19.00%
$50,000,000 22 0.5481 0.67 $4,930,706 0.7 24.00%
$50,000,000 275 0.6925 0.53 $3,877,010 0.63 31.00%
$50,000,000 1500 0.5372 0.32 $2,342,214 0.71 23.00%

The table shows two points:

  • If a smaller overall USD value is held within the buffers, it’s valuable to concentrate the buffers into just a few buffer tokens.
  • If we increase the overall USD value in buffer tokens, we can significantly reduce the gas costs and increase the ratio of internally settled volume.

Currently, we don’t wanna increase the overall USD buffer value, as this would also increase the inventory risk -among other risks - for the protocol.

I am happy to answer any question to this small study. People can also find the code used for it here

2 Likes

Thanks for posting this analysis.

I will move the proposal forward with the change that it’s up to the development team to specify & adapt the token list that can be used for internal buffer trading as it sees in the best interest of the protocol.

For the moment we are going to use this list (top 50 bought tokens from snapshot + CoW) and will work towards making the process of which list is used more transparent (by having a pinned ENS name and/or API endpoint serving the current list).

To summarize, the actual onchain transaction that will be voted on is:

  • Fund this dedicated “solver reward” Gnosis Safe which is controlled by the development team with 500 ETH and 7M CoW. This should secure 10 weeks of solver rewards.

This Safe will then be used to withdraw and store the accrued protocol fee and make rewards payouts to the solvers once a week (on Tuesday). Solvers receive the gas cost they spent on successful settlements (@bh2smith already created a Dune query for this here).
Damages to the protocol balances from bad internal trading or negative slippage (averaged over the week) will be deducted from the refund (we are still working on the query). The list of tokens that can be traded with from internal buffers can be adjusted by the development team.

4 Likes

Proposal is live: Snapshot

1 Like