I disagree with this. Ideally, we would like that the solvers do not treat batches differently based on what they think others will solve, what slippage accruals they have, etc. The only apparent reason for having 99% of the time a slippage of -1$ seems to be systematic behavior on the solver part. As evident from the charts in the OP post, standard behavior of the slippage is very different from that (even though asymmetric in nature due to possibility to revert). On the other hand, if the solver makes a huge loss, this isnât a loss to users or the COW DAO, so I think we should ignore that and hope that the solver does better next time.
1 Like
Thereâs a lot of interesting discussion here. Hereâs my 2 cents on it:
-
Rewards not being properly calibrated is a major cause for pennying having been an optimal solver strategy. I think it is clear that the reward scheme needs to be reworked in the short term. But, it is not the only cause. Even if we accurately reflect execution risk in a new COW reward scheme, solvers that have accrued positive slippage still have incentive to do pennying. Gas prices have been fairly low recently, and in presence of very low gas prices, it is increasingly easy for a solver to accrue positive slippage by decreasing slippage tolerance and paying less for revert risk.
Therefore, it is easier to accrue such positive slippage buffer in the weekly accounting process and then penny it down. However, such practice causes UX concerns for users and should be discouraged. In general, I believe solvers should not âtransfer valueâ across batches, and we donât have other easy measures in the short term other than banning pennying. Note that making the slippage accounting process symmetric (e.g. solvers get positive slippage) isnât sufficient until rewards are âideally setupâ. -
I think that from a long-term perspective, solvers would be running an auction where they effectively are competing on giving users the best exchange rate. Such an auction can be run with COW incentives or without them (where the solvers gets most of the fees to compensate gas costs). Nonetheless, I think we need a short-term solution.
-
Not allocating any rewards in case of negative slippage seems to me like an overreaction. While easy to implement, a standard distribution of slippage is such that negative slippage occurs close to 50% of the time, therefore Iâd argue it necessarily needs to result in solvers quoting too conservatively, harming users.
Altogether, I am in favour of banning pennying and running some analytics on it, leading to slashing in case of strong misbehavior.
2 Likes
[NOTE]: This is an unpdated copy of post that I deleted after noticing that the number of times we have incurred negative slippage is 30% instead of 50% as originally written - in the 20% difference there was zero slippage. I also clarified that the first action (redesign the reward structure) implies not explicitly forbidding pennying. Apologies for those who already voted in the original post.
Following the discussion above I would like to collect some input on the preferred course of action so we can reach a decision. There are essentially the three proposals:
Redesign the reward structure (and not forbid pennying)
[+] Seems to be the long term solution to the problem
[-] deserves more research and requires technical developments, so it is not a âquick fixâ.
Forbid pennying by a DAO rule
[+] Relatively straightforward to implement.
[-] Escalates the problem to the DAO and possibly involves slashing.
Do not reward solvers for batches with negative slippage.
[+] Relatively straightforward to implement.
[~] Itâs not clear if reporting the mean is incentive dominant.
[-] Honest solvers donât get rewards appoximately for 30% of times just because of network volatility.
[-] Say solver A has a better solution than solver B, however solver B wins by pennying and incurring negative slippage. Then solver B wonât get the rewards, but so does not solver A. In a sense the solver that is pennying can indirectly hurt an honest solver.
[-] Pennying offsets the slippage by a negative amount, which does not necessarily means the final slippage will be negative. For example a trade that achieves high positive slippage because of network volatily can still accomodate a bit of negative because of pennying and still have a positive combined slippage. On the other hand, admittedly it is a risky game for the solver to try to guess which trades have positive slippage and try to estimate if it is possible to do pennying on them, so this might be a lesser problem.
What is your opinion on what we should do in the short term future to forbid pennying?
- Redesign the reward structure (and not forbid pennying).
- Forbid pennying by a DAO rule.
- Do not reward solvers for batches with negative slippage.
0 voters
Iâve been reading the thread and so far I think @tbosman mentioned all arguments in favor of not forbidding pennying (or âputting patch on the reward schemeâ) and proceed to redisgn the reward structure. On my end, I think putting a patch on the reward scheme feels sloppy. Although, I do believe the team will be able to enforce some order among solvers, the competition stops being a trusteless environment and the team will need to invest time making sure the rule is being enforced. I mean, in many cases, solvers will encounter settlements in which even pennying 0.1 - 0.2 USD will lead to a win. The detail at which the team and solvers will have to look into who is pennying will not be trivial.
I do understand that changing the reward scheme to a setting in which penning has no impact is quite an endeavour. However, being the idealistic person I am, I would prefer to see a new scheme being worked on asap. This is why I casted my vote in favour of redesigning the reward structure instead of pushing a patch to the DAO.
Anyways, I think this is a good moment to raise a concern regarding âapprovalsâ and âallowancesâ in the solutions. Letâs say, I found a solution that makes use of Uniswap V2. UniV2âs router does not have any allowance on the settlement contract. Hence, in order for my solution to work, I must include an approval (~28k gas) in the output. If I am not mistaken, this will impact the ranking of my solution, even though it could benefit other solvers that will make use of UniV2 later on. Furthermore, if the approval has an impact on my solution, then I would need to choose another venue that may have enough allowances at the expense of user surplus or higher cost of execution compared to the original UniV2 solution. The reason why this is relevant to the discussion at hand is that currently solvers could decide to incur negative slippage (increase the clearing price) to cover the cost of the approval and make sure it does not have an impact on the solution.
I think approvals should not be a decisive factor on the solution. Specially, because they might benefit other solvers. Right now, a solver can ignore the risk of including an approval in the solution thanks to the flexibility of incurring negative slippage at will. If we are going to forbid this, then I think it is important to propose a solution to this issue.
Why do you believe that changing the COW reward scheme itself can in fact lead to a situation where pennying is no longer optimal, in context of my first bullet point above? (Solvers still have an incentive to âtransfer accrued positive slippageâ to other batches.)
1 Like
A new reward scheme can definitely impact the way in which pennying stops being a key factor in the competition. @tbosman wrote about a reward scheme in which top solutions that are within a certain distance from each other are considered equal and, therefore, the winner among them is selected at random.
If this distance is set equal to the ETH value of the COW tokens that will be rewarded, any of those two solvers would need to increase the clearing prices above the reward value to be considered different than the other and ensure a 100% probability of winning the reward. Increasing the clearing price above the reward value is irrational though.
Regarding the positive slippage accrued, I agree thatâs an issue that should be dealt with as part of the new reward/accounting setup as well. In the past, we have discussed settings in which (a part of) the positive slippage is distributed equally among solvers at the end of the accounting period instead of adding it to the âslippage balanceâ of the solver that originated the transaction. If positive slippage is distributed equally among solvers, then it would be up to them to decide how they want to spend their (expected) positive slippage during the week. If (for whatever reason) one of them wishes to spend it to win some batches more than others, then so be it. That solver probably has a good reason to do so. Specially if the winner is chosen at random as suggested above.
I think itâs all about magnitude here. Pennying can be positive-sum but how much of the pennying currently has been so? And pennying 10-20 cents is still much better than pennying $2-5 and will have an impact in much fewer cases. Likewise, is the approvals thing really a big deal? How often is this decisive? You can also approve just enough for your solution so it doesnât benefit other solvers if you want. 
1 Like
Also when we fix the reward scheme and we think that pennying then brings net benefits to the protocol, we can of course lift the ban.
1 Like
Whatever reward scheme we come up, it would also need to address the asymmetry in solver slippage accounting, otherwise pennying will still be optimal. I am not sure there is clarity as to whether solvers should get positive slippage, users should get it, or solvers should get some of it back based on a target metric. The current form of pennying does not help the protocol in any way, it is basically solvers spending additional $5 to get $15 over another solver who has just as good solution, so I think we need to address it more timely than trying to fix all issues at once.
Rewarding based on the difference between solutions etc. is interesting for sure, and I like that it highly incentivizes innovation, but it does come with a number of additional considerations that we are not ready to fully analyse over next couple months. One being that total COW payouts become highly unpredictable. So, I am not sure it really should impact our current thinking.
2 Likes
Agree 100% here. We are trying to address systematic âbribesâ that happen for a significant % of batches. Everybody would be fine if additional cost occasionally happens due to an approval, and practically speaking this wonât be detectable using statistical analysis either.
1 Like
What was the original reasoning behind the current system of slippage accounting anyway? Iâm relatively new to the community so Iâm not too familiar with that. I guess there was a desire to abstract slippage from users and it was undesirable to give positive slippage to solvers for fear they would deliberately start extracting it?
I would like to see some stats on the difference between best and second best solutions. How large is the variance really? Outliers can be taken care of with a cap I would think.
Thanks for your input Filius.
As we are moving to the solver-driver co-location architecture, soon it will be possible to send the approvals transactions outside of the settlement transaction, in which point they will incur no slippage.
1 Like
Well I think itâs clear that Filius and I have a very different experience/viewpoint than the rest here, but itâs also unlikely that we will sway the majority right now.
I think itâs better to move quickly and just test something out than keep debating this. I 'd rather have clarity so I know what to build and what not to. Hence I voted for banning the rule.
Maybe to make the most out of it itâs worth tracking some topline metrics and see how they are affected after the rule changes. In particular average surplus per batch/total surplus per day (to account for difference in batch size) and overall net slippage across all solver would be interesting to watch.
I did a quick analysis on the diff between first and second here (should be double checked by someone) here: **"Pennying" as a strategy to win more auctions, and how to deal with it - #12 by tbosman **
Note variance is not relevant for total pay out, itâs depends on the average between first and second place, and thatâs slightly lower than what we are currently paying out on average. So capping wouldnât even be necessary from the get go, although it would provide a safety buffer.
I imagine that if we set it high enough it would not cause any strategic behavior from the start. We can always revisit it when that starts happening to see if it needs to be relaxed (I could imagine that once things get more competitive, a larger share of value will get added through infrequent, but high-value solutions).
Right I saw that thanks for your work! I was just seeking to shed light on the concerns that this would lead to very unpredictable total COW payouts per week. Also I was thinking about the cap more as a per batch cap than a weekly cap. I think that would lead to less strategic behaviour and should still mitigate most outliers.
Great discussion so far! I agree that restructuring the rewards might take some time, so I also tend towards a ban (still havenât voted though). However, I would still like some concrete rule regarding pennying, so that we know that at least we will reduce its effect, serving as a temporary patch until we have some more robust solution.
What I mean is that even if there is a CIP that passes that says that pennying is not allowed, we could also include some (non-complete) list of cases where we automatically flag as pennying, so that we make things more concrete, and not simply say that the DAO (might) act upon certain cases of pennying.
Referencing the 30% of batches with negative slippage, some simple rule like the following could be a candidate: if at least, say, 35% of the batches settled by a solver fall into the [-$6, $0) interval in terms of slippage, then the solver is automatically flagged for pennying. Of course all these quantitative rules still allow for solvers maximally exploiting things within the given limits, but I do believe this will already make solvers much less aggressive when it comes to pennying.
Yeah agreed we need a per batch cap and not a weekly cap, weekly would lead to more strategic behavior. At the moment there is no per weekly cap for rewards either, so in principle the reward payout is unbounded: it scales linearly with the number of trades. Kind of averages out over the weeks though.
I am pretty sure we can get predictable enough payouts with a second price auction as well, especially if we are prepared to adjust the parameters a bit over time to keep on target.
Would need a better data analysis though. I am happy to do it if someone from the team can get me an export of the datasource behind the solver_competition endpoint? Would that be easy to do? @harisang @marcovc @marco
1 Like
Yeah I would be much in favor of some concrete rules. Any particular reason to cap it below at -6 though? Why not put a bound on the percentage of negative slippage in general?
This is the major issue to me. Everything else is just a side effect. Rewards canât scale linearly with the amount of trades because more trades currently means more batches but it shouldnât be (if we want more CoWs we need more trades per batch, and more batches should be great but not if the majority are single settlement trades, e.g. the average batch size is consistently sub 1.5). Nevertheless, while solvers keep focusing on single trades (because the reward scales linearly with trades) they will not bother much with CoWs/Batches.
That said, any attempt to change/improve the reward mechanism needs to focus on batches and CoWs (not on rewarding trades). Low effort settlements gives zero value to Cowswap (unfortunately not many people think like this). Anyway, recently I donât even use Cowswap anymore since I get better trades using Uniswap.
This doesnât have anything to do with the solver competiton. Iâm pretty sure the solvers will get that UniV3 price (or better) if they get your order. As far as I know the price quoted by the front end is fetched from a subset of âtrustedâ solvers that are not necessarily winning the auctions. Might need someone from the team to confirm this though. Not 100% sure how that part works.
But I understand why you would prefer executing directly from UniV3. The price you get quote by the front end is what you would get when executed.
1 Like