Sorry for the late reply, was a bit swamped.
Very nice work! Think something like this is a great first step to move the reward structure more towards the right shape, and we can iterate from there.
Some thoughts:
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.
This can be determined deterministically based on the solution submitted, no? If all amms/interactions are marked INTERNAL, and there are no atomic liquidity orders, the batch is buffer settled otherwise it’s not. Solvers will know if their solution is a buffer batch as well, so it will be clear upfront what their reward is going to be.
I would be in favor of including this in this round if possible. Perhaps just set revert risk to some fixed, very small number in that case (1%?).
Secondly, is it feasible to propagate these revert estimates to the user in any way? Eg something like new_fee = old_fee/(1-p_revert)? Not sure how much work this is re analysis and implementation, but I think there is a potential risk if the fee we quote to the user and the cost we reimburse to solvers diverges a lot, because it means we are effectively subsidizing the difference between tx cost on success and the full transaction cost including reverts.
We have already seen arbitrage bots exploit this difference. Right now it results in a loss for the solver, which gives them an incentive to detect and avoid such cases. When we reimburse it, that incentive disappears. Good for solvers, but bad for the protocol I think.
If it’s too complex to attach to this CIP we can just see how it pans out in practice though.