With the current penalty scheme, most small orders are heavily penalized since the solver has an asymmetric penalty / reward and their p_success should be higher than the 92% target of the backtesting. The issue for those orders is that another component suffers: the executed price. The higher the penalty/reward ratio leads to more underbidding which covers most of the times an adverse price movement and we have a big p_success.
On a large order, we have many times the opposite. Since penalty / reward is small, a solver often might overbid or tightly bid in general with the risk of not transmitting when price movement is adverse or not positive, lowering p_success. This approach though leads to much better executed prices.
Definitely increasing the potential penalty on a larger side order would increase the p_success. But I think that this increase would be much smaller than the 92% estimate which might not take into account a lot of factors other than adverse price movement and at a very big tradeoff, a much worse execution price. As flash well described above there are many more intricacies in larger orders that result in them having naturally a lower success rate, with only one component of it being the tight bidding. The biggest issue though is that the cost of that p_success improvement would be disproportionate for the end user in terms of execution price since the p_success on large orders depends at a much smaller fraction on the bidding aggressiveness than it does on small ones. A single ( and simple ) liquidity source route is much more controllable and this is very rarely the case with big orders.
I think there is a big asymmetry between applying the same bps penalty cap on a $100 order and on a $1M order and this change suggests a change on a $1M order from 0.19bps to a 6bps penalty for ethereum mainet. I don’t have any concrete suggestion other than to examine the data more closely and to not do huge jumps. A quick thought is to adjust the max bps according to the dollar value of the order.