Great response! Note that there are two polls above in the original post that you could vote on…
1 Like
Hereby, some more thoughts/comments.
@prometheus hereby some thought about the reward for single-order settlements.
From your response I get the feeling you imply:
Single-order Settlement = 0 reward → Solvers won’t win rewards.
The only reason why solvers are submitting single-order solutions for consideration at the moment is because they are being rewarded. If they stop being rewarded, then no rational solver will submit a solution for consideration unless it contains two orders in it. Hence,
Single-order settlement = 0 reward → solvers do not submit solution until two orders can be filled.
I understand this would not be desirable due to speed concerns. In that case, I think the proposal to introduce a premium at cost of the user would be a good solution. It could also get complex though. What if the size of the user’s trade is large? Based on the risks discussions, this premium would also need to be dynamic. Else, no rational solver would care to settle the trade.
Just to align this thought with the thought from @tbosman of modifying the objective function. Not rewarding single-order settlements is an indirect way to modify the objective function. It would be modeled by means of an indicator function that would only take value 1 if an exogenous variable (“order counter”) is larger than 1. In this case, all single-order settlements would have objective value 0.
To summarize this comment, the proposal “no single-order reward + speed premium” could be a good reward scheme, but it definitely needs more detail. How should the premium be defined? What would be the reward for multiple-order settlements? It also lacks treatment of settlement risks mentioned by @voyta.eth
Moving now to the risk topic.
As it has been mentioned by @voyta.eth neither of the new schemes proposed is taking into account the two main risks dealt with by solvers. At the moment, most solvers are ignoring these risks. If they would be taking them into account (which is in their main interest), COW protocol would not be settling any trades above a certain value (specially during intervals in which the gas price is high).
The reward schemes I’ve seen being proposed so far won’t change neither the risk exposure nor the amount of trades included in a settlement. They will only result in smaller margins for solvers and most probably will be replaced by a more complex scheme that takes settlement execution risks into account shortly after.
1 Like
In fact, these issues have been addressed in a direct reply to @voyta.eth here. We have introduced the concept of rewards per trade based on a trade size tier system. The table itself is not necessarily accurate but looking for suggestions.
Since the tier system has been proposed, the original post has been updated with two polls (at the bottom) where you can vote on two separate things:
- To cap the weekly rewards or not
- Whether the rewards be per batch, per trade or per trade with tiers.
The per trade tiered reward system targets mitigating both both types solver risks (failed transaction and slippage).
Currently the vote is to cap the weekly rewards and to implement the tiered per trade metric. Note that with our current price feed 1.6% of all trades cannot be assigned a value, in which case I would propose that we give the base reward (i.e. below 1k).
I believe others have pointed out that it doesn’t need to be scaled linearly and maybe we only need two tiers (below or above 1M).
Really looking forward to some concrete suggestions.
1 Like
In light of moving the conversation forward, this proposal has received plenty of valuable insight to the discussion of adjusting solver rewards. There are currently two polls at the bottom of the original post which would benefit from a few more votes.
The vote is currently at capped weekly rewards with tiered per trade metric. Both of these items require concrete parameters so it would be great if we could land on some values that seem appropriate.
Specifically, for the weight factor assigned to trades based on their size.
At this moment it is unclear whether this proposal should move forward without adjustments to the current per batch payout.
A few potential options for the official snapshot:
Transfer 12M COW to the Rewards Safe +
- without any adjustment to scheme
- with capped weekly reward (no change to per batch metric)
- with capped weekly reward and adjustment to the metric
1 Like
I just realized there is also a proposal to fix the reward per week and distribute them based on the score accumulated. Sorry for responding so late. I think there are some negative side effects here.
- It adds a lot of risk for the solvers.
- It would misalign the interests of the solvers with the protocol
On 1: right now we know exactly how much we stand to win in each batch. We can try to estimate slippage and failure cost (already hard enough) and balance them with the rewards. If we change to the fixed reward we won’t know how much the reward is until the end of the week. So we additionally need to ‘guess’ the average reward for the week. A much harder problem btw. Imagine the number of batches doubles halfway through the week. If you expected the batch frequency to stay stable, that would reduce the rewards by 33% compared to your expectation. Such a change might make many batches unprofitable in hindsight.
On 2: if we fix the rewards, solver profit goes up when traffic goes down and vice versa. I don’t like these reversed incentives in general, we should be working towards the same goal. Concretely it will mean that as traffic goes up, the threshold for solvers to not solve batches goes down, ie and therefore service level will deteriorate.
In my opinion, the risk of spending the rewards faster should be born by cow protocol, not the solvers. After all, if we actually burn through those rewards faster it means protocol adoption has grown faster than expected, a good thing!
If I compare this with the execution risk for large trades, at least there are things I could do technically to mitigate those risks (like quoting more conservative prices as a way to get some slippage protection). When it comes to the batch frequency risk, there isn’t much a solver can do to hedge themselves.
1 Like
Regarding the 1.6% of trades that can’t be assigned a value: how are we computing the slippage for the purpose of determining the solver rewards in those cases? Is there a way to align it with that computation? From the solver’s POV, the risk is primarily driven by the value COW assigns to the trade, not what the ‘true’ value is.
We have already deeply discussed the solver risks and evaluated exactly how they would be mitigated with the tiered per-trade reward scoring. Currently the solvers have greater risk since there is no correlation between the reward and the likely hood of incurring failed transactions or high slippage on large trades. Furthermore, on average the solver costs due to risk factors are substantially lower than the actual reward.
I do not see how this is the case, solvers would still be rewarded with a metric that is partially in correspondence with the number of batches (just giving more weight to the number of trades in a batch).
This capped rewards mechanism is both meant to make the rewards program more deterministically sustainable while also ensuring that the protocol doesn’t burn too much capital while adoption is still underway.
It is important to remember that, in order for the COW token to become more valuable, the protocol itself must generate revenue. This revenue is meant to be directed back to the token to sustain/increase its valuation. This can be done in the form of buyback programs, etc… There is a fine balance between the number of tokens being distributed and the protocol’s ability to sustainably bring value to it.
1 Like
We are in the process of improving our price feeds for the computations. Currently we make use of several factors/prices when evaluating slippage
- The clearing prices provided by solvers in the settlement call data,
- Dune’s
prices.usdtable - a 3rd party price feed coming from coinpaprika. This table is quite accurate (down to the minute), but has a very limited selection of tokens insufficient for the needs of CoW Protocol - Dune’s
prices.prices_from_dex_datawhich gives median prices every hour for a vast collection of tokens.
There has been some discussion around using the orderbook’s quoting endpoint to provide a more complete and intrinsic price feed to the slippage and trade size valuations, but this is still in planning/ideation phase.
1 Like
Last tiers suggested are fine by me. It doesn’t ‘fix’ some concerns but I believe we can vote for this or something similar (If anyone wants to suggest different values/tiers) and keep the conversation open for future improvements.
Changing the reward for something like this is better than keeping the current distribution but in the future we probably should align more the reward system with the protocol revenue. I will try to give more details and ideas on this but in my opinion we can move the proposal to the next phase.
A totally reasonable, simple adjustment here would be to merely proceed with a cap on the weekly rewards and leave the scoring as number of batches. The cap would then imply that per batch rewards aren’t necessarily 100 tokens but rather proportional to the score with the given cap per solver.
Hey, can you elaborate why exactly Ben’s proposal adds risk to the solvers?
Yes, there is an incentives issue coming from the asymmetric solver accounting, but this does not seem directly impacted by changing completely fixed batch reward to a variable reward per amount of transactions. A solver already has incentives to treat slippage differently in different parts of the weekly cycle.
I would agree Ben’s proposal means more risk when there is a batch with 1 transaction that is difficult to settle. At the same time, a solver can quote a worse price to offset that risk, even though that is not ideal solution and could be somewhat difficult to implement.
1 Like
We could also set the weight factor for trades over 1M to be on par with the current per batch reward. This would then amount to reducing that risk factor. I suppose it would make sense to further examine the per batch costs associated with these large batches thus far. Up until now the data is averaged over all and does not isolate large trades.
1 Like
The issue currently is that if we keep things how they are => High Reward compared to the Protocol Revenue; we will end up with a worthless token and a “useless” protocol since Solvers will stop solving if the token becomes worthless, just like they can also stop if they don’t get enough rewards. To be fair, what we have now is a transfer of value between token holders, buyers and the protocol itself moving to Solvers (and traders) because the protocol isn’t (yet) achieving a net positive revenue. I guess we can keep it like that for a while IF we achieve some sustainability. In order to get there we need to reduce the reward issuance.
Once we get here =>
We can adjust the reward again to something better for everyone, at least it’s how I see this issue. Also, I’m not entirely sure about this:
The reward wouldn’t be fixed per week it will use different rules (rewarding trades not batches) unless the weekly cap is achieved (if the cap is achieved then a ratio is applied messing with Solvers revenue expectations for that week). If the cap is an issue we can:
- reduce even more the reward (we just need to keep the reward issuance at a sustainable level) or
- keep a balance of the rewards not distributed in previous weeks and use that balance as needed (but never using future reward allocations).
Btw, this would be great.
1 Like
Thanks @prometheus for the great reply here. I think this captures some relevant points very well. One thing I would like to expand on here that I forgot to earlier is @tbosman’s comment quoted here
While this is partially true, there would be a deterministic way of calculating the current state of rewards at any block (just like there is now). It is total weekly reward cap divided proportionally across the current solver score’s. While I wouldn’t go as far as saying “guess”, the rewards at any given point would be accurate if solvers continue to perform at the same level for throughout the accounting period.
Even with the current scheme, solvers would have to guess their reward because they can’t know in advance how many batches they will settle during the week.
In some sense, solvers could already have a better idea earlier in the week of the their expected outcome if everyone’s performance remains similar.
1 Like
Let me try to give a back of the envelope explanation of the risk incurred (on my phone atm). Currently there are about 10-20 batches per hour. Let’s say 15 to make it simple. With the cap of 200k cow that would put the per batch cow somewhere around 80 cow. This means a solver can lose up to 60 COW per batch won in slippage and failed tx cost, without losing working capital (due to the rule that 25% of cow rewards need to be held, only 75% can be used to cover cost).
Now imagine a solver is losing 50 cow per batch on average for the first few days of the week, expecting it to be covered by the 60 cow reward. Now suppose suddenly there is a spike in volatility and the nr of batches per hour goes to 60 per hour for the rest of the week. As the total rewards are fixed the per batch reward goes down. It would end up closer to 20 cow. This means all of the batches the solver already settled are now losing 30 cow per batch, regardless of how well it performs the rest of the week.
Surely this is a risk that could be born by the solvers, but I don’t see the point as it doesn’t incentivize them to perform better. If anything it means you probably want to be a bit conservative at the beginning of the week, when there is less certainty about the reward per batch, leading to worse service for the users.
Another way of thinking of it is that the total cost born by all solvers scales linearly in the number of batches, while the reward is constant (as long as the cap is hit). This means the total profit/loss distributed across all solvers is something like 200k cow - x *num_batches, where x is the average loss per batch.
Hope this makes sense
3 Likes
A solution like the exponential ramp up/off of the gas price in ethereum would be a lot easier to deal with. Ie we would fix the reward per whatever the numerator is at the start of the week, but change it each week to make sure we hit the average of 200k per week. Not deterministic but should get us close hopefully.
Thanks for the additional insight here. It seems we won’t reach a simple alternative adjustment to the reward scheme in this proposal, so then perhaps we should just move this forward with the initially proposed transfer of COW tokens to top up the rewards.
The discussion itself has been good to have, but perhaps best left to a stand alone proposal.
1 Like
I think @tbosman’s two insights coming from a first hand solver are actually very good and convinced me personally that a cap is not a good idea. Solvers are performing an extremely important and already risky job of the protocol so giving them at auction time certainty about their achieved reward seems important.
Also I find it desirable that as the protocol is gaining more traction, solvers should get more rewards.
If we are on average overpaying solvers for solutions is a different question. I think especially initially higher rewards will ensure a healthy competition in the ecosystem, bearing in mind the first mover risks and pains (rudimentary development support, debugging insights into the competition, etc). But I don’t have a strong opinion on that.
I still think we could experiment with a simple payout scheme variation (per trade, potentially valued by trade volume).
2 Likes
Answering to @bh2smith 's request for concrete suggestions. Hereby an attempt to support the suggestion to stop rewarding single-order settlements or even allowing them without a “speed premium”. Built a quick query to estimate the amount of ETH (or COW) that can be saved on a weekly basis given that no single-order settlements take place.
These are the assumptions:
- ETH/COW = 10000
- The weekly number of single-order settlements is divided by two to derive the number of additional two-order settlements that would be encountered. Hence, I simply assume that all orders in single-order settlements will be part of a two-order settlement.
- Gas price = 50 Gwei
- The cost of a two-order settlement is based on the historical cost of two-order settlements. This should already take into account the saving effects of CoWs in two-order settlements.
The query indicates the protocol would save an average of 60.8k COW on tx costs a week. These cost savings are independent of whether solver rewards are reduced or not, which means the original amount of tokens being rewarded to solvers could be distributed in the per trade reward tier system.
3 Likes
I don’t really think that it is at all the intention to stop rewarding or settling single order batches. In time, when the protocol acquires more adoption, there will likely be less of them overall. In the meantime, we definitely want peoples trades to go through as quickly as possible (even if that means a lot of single order batches). However, it would be nice to reduce the protocol cost of such batches (hence the reward per trade suggestion).
I do very much like the idea of “speed premium”! But we should also remember that the longer an order sits waiting, the more and more likely it becomes that the order is no longer valid at the quoted price.
1 Like