Why
We run the order simulation in shadow mode to test whether it could become the order-acceptance signal instead of the signature check. It logs a lot of order simulation disagreement: signature passed, simulation reverted.
Most of those reverts are benign. The protocol lets users place fund-later orders, before they hold the balance or set the approval, so the sim reverts on insufficient balance/allowance even though the order fills once funded. To gate orders on the simulation we have to accept the benign funding reverts and reject only the genuinely broken ones.
A revert reason string can't separate the two. A funding-shaped revert (insufficient allowance/balance) can also come from a broken order, e.g. a flashloan whose repay hook reverts. So the string classifier in #4454 is only a coarse proxy. To separate them we need to know where in the settlement the revert happened: a revert on the user's transfer-in is a fund-later order, a revert on the repay or transfer-out is broken. The revert string doesn't carry that position. A debug_traceCall does.
What we need
Classify a revert by where it happened in the call tree, from a debug_traceCall: reverting wrapper, signature, transfer-in, or transfer-out. That separates benign funding reverts from broken orders precisely and replaces the string heuristic. This is non-trivial and is the prerequisite before the simulation can gate anything.
Next step
The revert reason is already logged, so before investing in the trace work we size the problem from the logs: pull the disagreement logs, classify funding vs other with a small script, and join each funding-classified order to its outcome (did it settle once funded?). If a lot of those orders never settle, the funding bucket is hiding broken orders and the trace work pays off. Caveat: orders that never settle also include fund-later orders the user abandoned, so this is an upper bound on broken.
Status
#4454 (string classifier) is a coarse first pass. It is paused, and we may not merge it: if the data step above covers the measurement we go straight to the trace-based classifier.
Related
Why
We run the order simulation in shadow mode to test whether it could become the order-acceptance signal instead of the signature check. It logs a lot of
order simulation disagreement: signature passed, simulation reverted.Most of those reverts are benign. The protocol lets users place fund-later orders, before they hold the balance or set the approval, so the sim reverts on insufficient balance/allowance even though the order fills once funded. To gate orders on the simulation we have to accept the benign funding reverts and reject only the genuinely broken ones.
A revert reason string can't separate the two. A funding-shaped revert (insufficient allowance/balance) can also come from a broken order, e.g. a flashloan whose repay hook reverts. So the string classifier in #4454 is only a coarse proxy. To separate them we need to know where in the settlement the revert happened: a revert on the user's transfer-in is a fund-later order, a revert on the repay or transfer-out is broken. The revert string doesn't carry that position. A
debug_traceCalldoes.What we need
Classify a revert by where it happened in the call tree, from a
debug_traceCall: reverting wrapper, signature, transfer-in, or transfer-out. That separates benign funding reverts from broken orders precisely and replaces the string heuristic. This is non-trivial and is the prerequisite before the simulation can gate anything.Next step
The revert reason is already logged, so before investing in the trace work we size the problem from the logs: pull the disagreement logs, classify funding vs other with a small script, and join each funding-classified order to its outcome (did it settle once funded?). If a lot of those orders never settle, the funding bucket is hiding broken orders and the trace work pays off. Caveat: orders that never settle also include fund-later orders the user abandoned, so this is an upper bound on broken.
Status
#4454 (string classifier) is a coarse first pass. It is paused, and we may not merge it: if the data step above covers the measurement we go straight to the trace-based classifier.
Related