CIP: 10
title: Solver Rewards II
author: Ben Smith <ben@cow.fi> (@bh2smith)
status: passed
created: 2022-06-03
Voting is now live on snapshot
Update (2022-06-13)
There has been much discussion regarding the possible adjustment to reward distribution which has lead us to determine that capping is not ideal (cf @tbosman’s post here). It is clear, however, that the per batch reward mechanism does not accurately capture the risks involved when settling large batches. The idea for this proposal will be to set a B COW per batch reward plus a T COW per trade. These numbers in a way to keep total issuance the same as the first 12 weeks of the program. Simulations according to this formula:
B * total_batches + T * total_trades = total_issuance
Simulations were performed via this parameterized query taking the total number of batches and trades, and solving T above.
Any choice here ensures that COW token issuance is not decreased, but rather shifted so that larger batches (with higher solver risk) are more accurately rewarded. Results are:
It is expected that the following proposal will move into voting phase on Wednesday, June 15, 2022 provided there are no major objections.
Projected Proposal:
-
Transfer 12M COW from CoW DAO (
0xca771eda0c70aa7d053ab1b25004559b918fe662) to the Solver Rewards safe (0xA03be496e67Ec29bC62F01a428683D7F9c204930) and -
Change the reward scheme from 100 COW per batch to
BCOW per batch +TCOW per trade. This change is intended to be made for the accounting period beginning 2022-06-21 according to the implementation drafted in CIP-10: Solver Rewards Scheme Change by bh2smith · Pull Request #38 · cowprotocol/solver-rewards · GitHub
Please vote on the following poll
- 25 COW / Batch + 53 COW / Trade
- 30 COW / Batch + 49 COW / Trade
- 40 COW / Batch + 42 COW / Trade
- 50 COW / Batch + 35 COW / Trade
- Keep 100 COW / Batch + 0 COW / Trade
Simple Summary
Based on a projected consumption rate of ~2M COW per month, we propose the transfer of 12M COW to fund the next 6 months of solver rewards. This proposal also introduces discussion points on adjusting the per-batch COW rewards schema since, currently, they are economically unsustainable. Data is provided demonstrating the risk-reward ratio for solvers and shows an alternative distribution plan that would deterministically last for 12 months by capping the weekly distribution at 200K COW.
Reward Data Thus Far
The COW Rewards Safe was initially funded with 7M COW & 500 ETH at transaction tx. During the first 12 weeks (3 months) of payouts we have distributed the following:
- Payout History with an outgoing total of 5,467,600 COW (averaging 456k per week and projected to ~24M annually)
- Totals Query
Rounding the 3 month total outgoing COW to 6M results in a projected estimate of 12M for the next 6 months with the potential remainder of 1 or 2 weeks of buffered funds.
Questions and Considerations
While the proposal is primarily intended to get the proposed funding (before the current COW rewards balance is depleted ~2 weeks), we also attempt to initiate discussion with regards to the following two questions: Should the DAO
- increase, decrease or keep the current distribution rate?
- consider an alternative (more refined) per-batch distribution?
The decision here, at its root, revolves around finding the fine balance between rewarding risk incurred by solvers while simultaneously bringing value to the protocol. We outline some statistics here on the risks and costs associated with operating a solver along with the burdens incurred by the protocol’s treasury.
At the current price of COW the rewards are valued at ~$17 per batch not including the solver risks (penalty for negative slippage and failed transactions). Slippage occurs when the protocol receives more from, positive, or pay more to, negative, an AMM than expected (i.e. when solving a batch). Slippage can be both positive and negative. Solver’s net slippage, when negative, is withheld from transaction cost reimbursement at the end of each accounting period. In addition to slippage risk, there is also the failed transaction risk, whose cost is not reimbursed by the rewards program.
From the protocol’s perspective there is a cost associated with subsidizing the trading fees to account for protocol overhead that is directly proportional to the number of trades per batch. More specifically, the protocol subsidizes the gas cost overhead of its own smart contracts as a batching layer between the AMMs. A certain number of trades per batch are required to make up for this subsidy. In essence, single order batches result in costs to the protocol.
We examine these stats thus far in each of the above mentioned risk areas:
Risks & Costs
Solver Slippage
Since inception of the reward program, slippage penalty costs, while expected to be 0, total $111,863 over 54,601 batches (averaging $2.05 per batch). This data (built from this parameterized query) is taken from the weekly totals in this spreadsheet. To regenerate the results, simply put the accounting period StartTime into the query linked above. The per trade average slippage cost is $1.36 based on 81,832 trades.
In addition to these averages, it is important to note that larger trades incur higher risk of negative slippage. It would be nice to incorporate trade size into the equation when determining rewards. However, due to unreliable price feeds for arbitrary tokens we are unable to accurately assign value to every trade.
Solver Failed Transactions
Currently the per batch average failed transaction cost is $2.15 (deviating by $1.72) with individual solver average costs ranging from $0.16 (Naive Solver) to $5.48 (Otex).
The per trade failed data shows an average cost of $1.69 (deviating by $1.36) and ranging from $0.09 to $4.42.
- Total Average Failed Tx Cost
- Per Solver Average Failed Tx Cost
- Failed tx Cost Averages, Extrema and Deviations
In addition to the statistical averages noted above, higher risk occurs during times of high price volatility. That is, if a quote is given to a user based on the network state at block N, but the trade isn’t settled until block N + K, even when K = 1, the transaction has a much higher likelihood of failure. One deterministic aspect that could be incorporated into the reward mechanism could be making it a function of gas prices, however exploration of this idea is beyond the scope of this post.
Protocol Costs
Since the inception of the reward program 75% of all settled batches contain only a single trade. Here is a chart query showing the batch size distribution for this time frame.
Single order batches are an expense to the protocol since the fees are subsidized to offset protocol overhead when it comes to transaction costs (i.e. fees collected for a single trade are less than batch execution cost). This means that rewards given for these batches are a loss both in COW and ETH.
This simple statistic shows the cost coverage (fees collected / cost incurred) trends for batches based on size (i.e. number of trades). It is expected to have an upward trend as the number of trades increases but we also see that, on average, the protocol only becomes net positive for batches with more than 5 trades.
At this moment, it is clear that the protocol costs substantially exceed the risk/cost realized by the solver competition.
The combined average cost for both solver risk categories is $3.36 while the reward per batch is currently about $17 (with COW token valuation of 17 cents).
The current average cost per batch for the protocol is ~$16 (= 17 - 0.86) derived as cost in COW - revenue from fees. Note, that fee revenue is calculated from May 4 since we have recently reconfigured the fee subsidy model so prior data does not resemble the current state of operations. For more detailed historical data, please visit the daily average per batch revenue chart. Unfortunately, sustaining these rewards at the current distribution rate is not economically viable for the protocol in its infancy (i.e. during a time before network adoption has been realized).
Certainly protocol adoption is key to driving the batch sizes up, but in the meantime we could strive to reduce the per batch cost of rewards while keeping the competition attractive!
Adjustments to the Reward Scheme
In the original proposal CIP-2: Solver Rewards and currently, the rewards were specified as 100 COW tokens per batch. This was considered a reasonable first approach to reward distribution with limited complexity that could be quickly implemented and launched. However, from the data shown so far we have seen that this distribution scheme bears a substantial cost to the protocol that is not long term sustainable.
Some immediately apparent, straight-forward, yet good alternatives:
-
Rewards per trade instead of per batch:
This would be easily implementable with minor changes to the current setup. It is completely deterministic and reproducible and, since the number of trades correlates directly with protocol expenses, can be seen as a good first step in the right direction. -
Capped weekly rewards distributed proportionally according to some measure:
This alternative works well together with any adjustment made to the way solvers are scored while simultaneously given more certainly to the distribution rate over time.
Example Simulation (Trades per Batch)
For example, if we rewarded T (<= 50) tokens per trade rather, then single order batches would not be such a burden on the protocol. We can simulate the total outgoing COW rewards based on the total number of trades 76636 (total outgoing COW / number of batches quoted above)
| COW Reward / Trade | Total Outgoing COW (first three months) | Solver Reward / Trade $ |
|---|---|---|
| 30 | 2.3M | 2.05 |
| 35 | 2.7M | 2.90 |
| 40 | 3.1M | 3.75 |
| 50 | 3.8M | 5.45 |
Where Solver Reward is calculated at a 17 cent COW price and deducts the per trade average cost for slippage 1.36 and failure 1.06 (cf. computation in spreadsheet).
So, if we were to take an approach like this (as is also indicated by the batch-trade distribution chart), a 35 token per trade reward would essentially double the projected time frame for which the proposed funds would last.
Of course, this is just a simple example of an alternative mechanism for reward distribution and preservation of protocol value with the prospect to eliminate raw loss. Other suggestions are welcome for discussion here.
Summary
We remind the reader that this proposal’s primary goal is to top up the Solver Reward Safe 0xA03be496e67Ec29bC62F01a428683D7F9c204930 with 12M COW to sustain the next 6 months of rewards.
If possible it would be nice to include a concrete adjustment plan based on the data and discussion provided here. For example, a proposal of the form
capped weekly distribution of 200k COW with proportionality measure determined by number of trades
would ensure that 12M COW lasts for 12 instead of 6 months.
If no consensus is reached for the adjustment plan, this request for 12M should be moved quickly into voting (as there are only 2 weeks left for the current program).
In pseudo transaction format, that is
Transfer(
token=0xDEf1CA1fb7FBcDC777520aa7f396b4E015F497aB,
from=0xca771eda0c70aa7d053ab1b25004559b918fe662,
to=0xA03be496e67Ec29bC62F01a428683D7F9c204930,
amount=12000000000000000000000000,
)
Plus, potentially, a reconfiguration of the Solver Rewards Distribution Project depending on how the discussion goes.
Happy discussing!
Based on the discussion so far, it has become clear that one thing left out from the original post is the added risk incurred by solvers for high value trades. The additional risk is both due to slippage and likely hood of failure. Below are two polls which, together could help shape a reward restructuring proposal (cc @voyta.eth , @Filius , @prometheus , @tbosman - since you have been the most active so far).
Cap weekly rewards or not?
- Cap at 200k
- Cap at 250k
- Do not Cap
Metric for which rewards are computed
Note that basing solver rewards based on tiers comes with a 1.6% error margin. See here for supporting data.
- Reward per Batch
- Reward per Trade
- Per Trade Reward Tier (with trade size tiers)
