You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The driver needs a new component that tries to figure out which tokens are not correctly supported by the driver.
Instead of using a test based on trace_callMany (current approach) we should implement heuristics in the driver that associates reverting solutions with the tokens involved.
If a token occurs very frequently in solutions that fail to simulate the likelihood of it being the cause for it (e.g. by taking fees when the solver doesn't expect it) is very high.
So after the driver encoded and simulated a solution it should associate all involved tokens either with success or failure. If a token reaches a configurable threshold of failures it should be considered unsupported. This is a very simple heuristic and might need to be improved as we go.
Details
Because each solver might support different kinds of tokens we need 1 such component per solver.
The component should have 2 modes: enabled and logOnly. That way we can see how the component would behave without it actually affecting the driver until we are confident it's working well.
Orders trading tokens that are considered unsupported should be filtered out by the driver.
There should be a way to manually specify a list of unsupported and supported tokens as an escape hatch in case the solution causes issues in the future.
The component should initially run in logOnly mode for all solvers.
The text was updated successfully, but these errors were encountered:
Background
The driver needs a new component that tries to figure out which tokens are not correctly supported by the driver.
Instead of using a test based on
trace_callMany
(current approach) we should implement heuristics in the driver that associates reverting solutions with the tokens involved.If a token occurs very frequently in solutions that fail to simulate the likelihood of it being the cause for it (e.g. by taking fees when the solver doesn't expect it) is very high.
So after the driver encoded and simulated a solution it should associate all involved tokens either with success or failure. If a token reaches a configurable threshold of failures it should be considered unsupported. This is a very simple heuristic and might need to be improved as we go.
Details
Because each solver might support different kinds of tokens we need 1 such component per solver.
The component should have 2 modes:
enabled
andlogOnly
. That way we can see how the component would behave without it actually affecting the driver until we are confident it's working well.Orders trading tokens that are considered unsupported should be filtered out by the driver.
There should be a way to manually specify a list of unsupported and supported tokens as an escape hatch in case the solution causes issues in the future.
The component should initially run in
logOnly
mode for all solvers.The text was updated successfully, but these errors were encountered: