We certainly hope that it will in the long run be reasonable to do these kind of manual integrations for solvers in order to be competitive (CoW protocol’s vision is to be the primary price finding layer for most trading volume on Ethereum).
DEX Aggregators already do this kind of work for different protocols and we expect the revenue potential for CoW solvers to be on par with the revenue potential of aggregators.
1 Like
Yeah agree with you on that point. I guess we can probably make it work somehow by having stricter slippage tolerances. One follow-up question: are you thinking of putting penalties on both positive and negative slippage?
How we deal with positive slippage is still not clear to me, and I guess it is a big topic by itself.
I agree that the way we currently deal with positive slippage makes some sense, and it helps solvers balance things out a bit. So, we could continue doing the accounting, while potentially penalizing a bit (e.g., in terms of slightly reducing the rewards) for positive slippage settlements. I guess the high level goal of this is in no way to be aggressive against solvers, but push solvers to make more reasonable decisions regarding slippage management. Also, ideally we would like to reduce a bit the phenomenon of a solver getting lucky early on and then gambling away the positive slippage it has accumulated, as this can create frustration on other very robust solvers that simply were not lucky enough, but end up losing tons of batches because of this. The counterargument to this, of course, is that solvers that simply aim to get lucky most likely will not be viable in the long run, as they will end up having some very bad weeks as well.
Got it. I agree, there is an incentive to price cut when solvers have a reservoir of positive slippage, and it’s creating this whole meta game for solvers which doesn’t contribute much to protocol. It didn’t catch this was the main issue being addressed here. IMO would be great if we can eliminate this dynamic, and we probably can without too many negative side effects.
So to get back to @marco, generally in favor, though I think it might be useful to be a bit more specific about that goal in the CIP.
That said, let me throw out another penalty mechanism: suppose we award solvers no reward if there was negative slippage at all (up to some small tolerance to allow for numerical error etc.).
I suspect this would make truthful reporting (to be defined below*) close to the dominant strategy. Would need to check the data, but I am pretty sure the distribution of transacted amount is extremely concentrated around the median for most trades. I.e. most of the time you transact exactly what you simulated. It’s just that the expectation!=median here due to the asymmetric tails.
This means that if you report an amount higher than the median value, you might win more batches, but those batches will almost certainly not bring you any profit (and might lose you money, if it reverts), plus you stop winning money on the batches you already were winning.
Truthful reporting*: a rational solver would report exactly the median, while making sure make sure that the expectation is nonnegative by appropriately setting the slippage limits (which shouldn’t affect the median, generally).
Now, if we leave slippage accounting as is (with averaging), there is still room for strategic behavior. Eg a solver with slippage reservoir might set absurdly high slippage limits just to get a tiny reduction in transaction failure cost (though this is an order of magnitude smaller opportunity than winning more batches). It wouldn’t really affect who wins batches, but from the protocol’s perspective, we might prefer to keep that money and use it to offset fee subsidies or whatever.
High-level, we don’t want a solver to pick up 1000$ worth of slippage to save a 50$ gas cost transaction, but anything below 50$ of slippage would have been fine.
An obvious mechanism that achieves this is penalizing negative slippage 1 to 1 on a batch level. In that case, rational solvers should set their slippage tolerance such that the value equals their expected transaction cost.
Note: obviously, these changes will result in a drastic decrease in rewards and increase in penalties for solvers. All that money flows back into the protocol though. Plus, solvers are incentivized to be more sensible regarding slippage, which I think should lead to more revenue from positive slippage. Overall it should be possible to adjust the rewards such that the net effect on solvers is 0, while net profit for the protocol goes up.
Thanks everyone for your input and discussion!
We understand that the global token conservation constraint is controversial and needs more research, so we have decided to cut it out of this proposal. Nonetheless, we’d like to establish a basic framework of acceptable vs. undesired solver behavior and thus move ahead soon with the remainder of the proposal.
1 Like