Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
# Description Slippage tolerance in the solver is parsed using standard U256::from_str which interprets the string in base 16. 40000000000000000 (0.04ETH) thus becomes 73ETH causing us to set very high slippage tolerance. This PR hot-fixes the parsing to use our custom base 10 serializer. I noticed that we re-implement U256 parsing both in the driver as well as in the solver (and we recently added an implementation in the number crate). Ideally we unify the use. It’s also a bit confusing that we define slippage in both the driver as well as the solver (it’s needed in the driver to encode the baseline liquidity interactions) It would also be great if we can get the linter yell at us if we ever try to serialise a U256 with the default serialiser (I’m not sure how to achieve this though) as this has been the cause for many issues now. ## How to test Load a local solver, print slippage and see it being properly parsed. <!-- ## Related Issues Fixes # -->
- Loading branch information