For the first thought, the idea is to send the computed rewards for each order to the solvers so would you override that if the solvers send a “safe” solution? That might give them a strong incentive to not send a “safe” solution then.
Well safe in the explicit sense of having all interactions internalized. Doing that also saves gas, so your solution is more competitive. As we have seen empirically, solvers have a strong incentive to lower their expected rewards if it means they increase their win probability due to the competition.
Yeah maybe that would be beneficial. I think it’s easier to just lower the revert risk when an order buys a token amount that the settlement contract has and is selling an approved token. That handles almost all of the safe solutions, doesn’t it?
Hey, can you direct me to where you’ve seen the arbitrage bot exploits you’re referencing?
There are several bots that exclusively pump stables coins back and forth on cowswap, at prices better than the mid prices. Here is one that operates on DAI-USDC:
https://explorer.cow.fi/address/0xb00098Ba6EedaEd1D4Ab31e7fa14cb969CccE653
As you can see most of the orders expire. This is either because the opportunity which appeared to be there when the price got offered is gone by the time solvers get to it, or some solver tried to fill it and reverted. Another option is that the order got filled with a lot of slippage. Eg here: Ethereum Transaction Hash (Txhash) Details | Etherscan
In this case it would actually have been more cost effective for the solver to set a higher slippage tolerance, as they had to make up $38 worth of slippage, but the tx cost was only $10 (so less still if it had reverted midway).
This is what I am talking about when I say exploiting the difference between gas cost and gas cost including reverts. These trades were really possible when queried, but you are basically betting that no arbitrage bot will outbid you to claim it before you, which happens rarely.
For this particular bot 64% of the batches they were involved in the last seven days failed. This doesn’t take into account successful batches with significant slippage, so the actual fraction of toxic batches is even higher.
Btw: interesting to know if there any searchers monitoring this forum. If we see an uptick in this strategy after today that might point to it.
1 Like
Thanks for the suggestions TBosman!
After talking with the team we realized indeed we can already push for considering a special case when all interactions are internalized, in which case we can hardcode the probability of revert to zero. This has the effect that in such batches the solvers receive only the expected profit T.
I suggest changing the text
Potential extensions:
- Revert risk is close to null when the solution can be settled using internal buffers exclusively. Successfully estimating whether this is the case would allow for awarding lower rewards for these batches.
to
Revert risk is close to null when the solution can be settled using internal buffers exclusively. We propose that when all interactions are internalized then a hardcoded p=0 is used in the rewards formula, to make sure that solvers get the only the expected profit T in such case. The team will work to implement this addenda to the CIP as soon as possible, but it might happen that it won’t be ready immediately when the CIP passes.
1 Like
To address the case of settlements without external interactions, I added a paragraph in the draft that reads as follows:
October 6 UPDATE: Following the discussion below, we add the following to the proposal. In the case where a settlement is (potentially) using internal buffers and zero external interactions, then the “rewards” value specified in the input json per order will be ignored when computing the reward; instead, this value will be replaced by the value T (per executed user order contained in the batch). We also clarify that liquidity orders provided in the input json that have no atomic execution, i.e., where the corresponding field “has_atomic_execution” is set to FALSE, will be treated as internal interactions. This, in particular, means that a perfect CoW between a user order and such a liquidity order will be treated as a purely internal settlement, and thus, will lead to a reward of value T.
If there are no objections to the proposal as a whole, and to this specific update in particular, then I would like to move the proposal for voting in the beginning of the next week. This is based on the fact that the draft has been around for several weeks, and people seem to agree that it would improve upon the current state of things.
2 Likes
The CIP is now live!
3 Likes
Guess everyone is aware by now but posting here for completeness. The CIP has passed, and starting this week (i.e., yesterday), rewards will be computed based on the new scheme.
Thank you everyone for your participation!
1 Like
I’ve mentioned this before but what do people think about replacing T with the gap between the first and second solvers’ objectives? That would solve a lot of the problems around pennying and incentivizing solvers properly while also being simpler to implement and understand than things like the auction scheme. Would be interesting to see some simulations on this!
1 Like