bug: Quote verification process sometimes fails when there is no dust in the settlement contract

[harisang]

Problem

The quote verification process involves simulating calldata provided by the quoter in order to ensure the route proposed is actually valid. As part of the verification process, the protocol is generally fine with extremely small disrepancies/slippage when executing that route, as part of the simulation of the verification process (and this discrepancy is controlled by a threshold parameter).

We observed that in case where there is no dust of the buy token in the settlement contract, the simulation involved in quote verification can fail due to very small inaccuracies/rounding errors on the quoters' side, that might attempt to send even 1 wei more to the user than what their route suggests. On the other hand, in case where there is dust, the quote would pass verification even if it attempted to send, say 10 more wei to the user compared to what the route suggests.

For this reason, we suggest to add an artificial buffer of, say 10 units, of the buy token, in the settlement contract, so as to make the verification process more uniform and not dependent on whether buffers exist or not for a certain token.

Note that due to a similar situation potentially arising for buy orders on the sell token side, a buffer on the sell token side should probably be added as well.

See also here for some relevant context

[fleupold]

How would adding a fake token buffer perform in the actual settlement phase of the auction? Do we have reason to believe that solvers send solutions that wouldn't suffer from rounding errors and reverts in the absence of dust? Otherwise, we are just moving a "no liquidity" issue into a "order will expire" issue.

[harisang]

How would adding a fake token buffer perform in the actual settlement phase of the auction? Do we have reason to believe that solvers send solutions that wouldn't suffer from rounding errors and reverts in the absence of dust? Otherwise, we are just moving a "no liquidity" issue into a "order will expire" issue.

Some potential reasons:

• We expect solvers to actually simulate their routes when solving, as they need to compute/estimate gas costs. I suspect this might not always be the case when quoting. This might mean that a solver would adjust prices so that the whole execution simulates; of course i don't have any evidence for that.
• More solvers are solving compared to quoting; thus another solver (not the quoter) can match the trade.
• Some solvers are collecting fees in the buy token for convenience; in such a case, it is guaranteed that the execution would go through.