- It has two three methods to be created:
- new: where the user can pass any custom StrategyEncoder
- tycho_router: where the default SplitSwapStrategyEncoder with Tycho Router will be used
- direct_execution: where the user can encode only the execution data and integrate this into their workflow.
- This replaces StrategyEncoderRegistry
- EVMTychoEncoder holds directly the StrategyEncoder and not the registry (per one init of the EVMTychoEncoder there is only one possible StrategyEncoder)
- Update quickstart
- Update bin (add subcommands to bin to create a different instance of EVMEncoderBuilder)
--- don't change below this line ---
ENG-4246 Took 33 minutes
Took 38 seconds
Took 38 seconds
- In preparation for also using this for the executor encoder.
This also make test setup much easier for swap grouping - not having to init the encoder every time.
As far as we know, Uniswap V4 has no support for optimizing split swaps - only sequential swaps. We must make sure we don't accidentally group split swaps too - as this will likely revert due to mismatched input and output values.
To achieve this, a small refactor was necessary with the introduction of a SwapGroup object, and a separate method to create a vec of these objects. This then separates all logic related to combining protocol data nicely and cleanly into its own method with its own tests.
TODO:
- Deal with split swaps and add test for split swap scenario
- Clean up all existing PR comments
We use the same validation for both SplitSwapStrategy and UniswapV4Strategy - so, instead, put the validation into a Validator trait that gets initialized in both swap strategies in order to avoid duplication.
- To keep any knowledge of USV4 separate from regular splits, I've made a new USV4 encoding strategy that will be used only if we detect sequential USV4 swaps.
- For single USV4 swaps without necessary optimizations, the regular split swap strategy can be used
- No need to change the swap struct interface to take multiple swaps - this concatenation can be done at the swap strategy level.
TODO:
- test
- deduplicate code from split strategy
- UniswapV4SwapEncoder
Return selector in the StrategyEncoder. This is needed for the ExecutorStrategyEncoder
--- don't change below this line ---
ENG-4088 Took 12 minutes
Took 13 seconds
This is unnecessary since we already have the executor address loaded at build time
--- don't change below this line ---
ENG-4088 Took 8 minutes
Took 7 seconds
This is necessary when we run tycho-execution in an environment that already has a runtime.
Make sure that if no runtime exists, like in the testing scenario inside tycho-execution, we save the new runtime in an attribute of permit2. If we don't do this, then the runtime just dies and our handle points to nothing at all and all tests fail
--- don't change below this line ---
ENG-4088 Took 17 minutes
Took 5 seconds
This way we don't have issues with paths and trying to read files that are at other locations after compile time
--- don't change below this line ---
ENG-4088 Took 44 seconds
Took 52 seconds
- This way this chain object contains everything we need, we don't need to worry about doing any transformation or calling any supplementary functions inside any of the encoders
- Needed to move our new Chain object to a higher level since this is used in the higher-level encoder traits. This required some weird default values in the constants in order to avoid using alloy's hex literal. I could have instead opted to make Bytes parse a string I think, though this would mean possibly returning an error at the constants level, which is not nice either.
Question:
- Do we want the user to be in charge of passing the native and wrapped token every single time? This may be a bit annoying for the user. For now, I have defaulted to those in constants.rs, this would take 5 mins to remove though if you don't like it, and it would get rid of this complicated bytes initialization.
