Move Solver Rewards Mechanism from Theory to Practice

Thanks for bringing up this issue. We agree that, in some instances, our current mechanism penalizes solvers when the protocol is slow. We are working hard to make the protocol faster, that is, to reduce as much as possible the time between the auction being released, the solutions being received, and the winning solution being settled on chain. A big part of this effort is “solver-driver colocation,” which showed dramatic speed improvements in our recent tests. Also, in a fully colocated world (where solvers run their own “driver”), each solver has full control over the submission and can resubmit a different solution if the route changed.

Our ultimate goal is to make the auction as fast as one block: release the auction immediately after a block is added and settle the winning solution in the subsequent block. This is an ambitious objective. To keep us entirely focused on it, we prefer not to introduce half-baked hotfixes. Also, in the “one action per block” world, the difference between computing the penalty using “reference solution” vs. “reference solution that simulated” would be minimal (remember that penalties are capped anyway).