Commit Graph

22 Commits

Author SHA1 Message Date
TAMARA LIPOWSKI
132eed4bb9 test: 5-hop Multi-protocol integration test
- Needed to add ekubo and uniswap v4 to callback-limited protocols.
- I had to bump the fork block in all of our integration tests: The way it was before meant that certain integration tests were using certain executor addresses, and others were using different ones, because of the redeployment. This was a pain to account for on the rust side. Instead, all tests now use an Ekubo-compatible fork block. Values needed to be updated because of price changes between blocks.
2025-04-23 12:31:53 +01:00
Diana Carvalho
4a61de56b7 feat: Support using the TransferType in uniswap v4
Update tests

--- don't change below this line ---
ENG-4437 Took 1 hour 3 minutes

Took 2 minutes
2025-04-23 12:31:42 +01:00
Diana Carvalho
244b7d3482 fix: Rename constants and update docstrings for clarity
--- don't change below this line ---
ENG-4314 Took 44 minutes


Took 9 seconds
2025-04-23 12:31:41 +01:00
Diana Carvalho
8aa5b08b41 fix: unsupported protocols for chained swaps are always unsupported
not only when the previous swap if of the same protocol!
Improve docs and naming

--- don't change below this line ---
ENG-4314 Took 15 minutes
2025-04-23 12:31:41 +01:00
Diana Carvalho
efe12cfcd6 feat: Support in between swaps optimizations
--- don't change below this line ---
ENG-4314 Took 31 seconds
2025-04-23 12:31:41 +01:00
TAMARA LIPOWSKI
11886b3ac1 fix: properly add ekubo_v2 to constants
Mistakenly added "ekubo"
2025-04-23 12:31:41 +01:00
TAMARA LIPOWSKI
d9066d0a09 feat: Use TokenTransfer optimization helper in Ekubo 2025-04-23 12:31:41 +01:00
TAMARA LIPOWSKI
462be5463b feat: Add TokenTransfer class to Curve
- This needed to be in Curve so that the executor can also take care of transfers from the user into the tycho router, to avoid having transfer actions mixed between the router and executors
2025-04-23 12:31:41 +01:00
TAMARA LIPOWSKI
a301a1cef3 feat: (WIP) Support selection of transfer into router
- For protocols like Balancer and Curve, which expect funds to be in the router at the time of swap, we must support also transferring funds from the user into the router. Doing this in the router would mean we are dealing with transfers in two different places: in the router main methods and in the executors. To avoid this, we are now performing transfers just in the executors, and two transfer types have been added to support transfers into the router.

TODO:
- Add this for Balancer and Curve (only added for USV4 atm).
- TODO consider renaming TRANSFER_FROM and TRANSFER_PERMIT2 to include "pool" in the name
2025-04-23 12:31:41 +01:00
TAMARA LIPOWSKI
59a80dc392 feat: Optimize transfer to first pool
TODO: Update integration tests on solidity side, since a few were now updated on the encoding side to use a transferFrom.
2025-04-23 12:31:41 +01:00
Diana Carvalho
739fb46d20 feat: Add protocol_specific_addresses.json file
This way we can define protocol and chain specific addresses in this file and use them in the Encoders

--- don't change below this line ---
ENG-4306 Took 1 hour 4 minutes
2025-04-08 09:30:29 +01:00
TAMARA LIPOWSKI
b4c687bc3f fix: Proper ekubo protocol name in GROUPABLE_PROTOCOLS 2025-04-03 11:09:31 +02:00
TAMARA LIPOWSKI
d5c589d2c0 feat: Remove router_address from Solution, set default
- The router address can be set when creating the SplitSwapStrategy, which now takes an Option<Bytes> as input during initialization (another breaking interface change)
- This change allows us to change our router address in the future with minimal effect on the users. Users should only pass the router address in the split swap initialization if they intend to use their own router for execution.
- This change also means that the router address does not need to be passed with the solution, even when using the executor strategy (which was pointless).
- I thought of having a router_address() method to set this in the encoder builder - but it seemed too messy, since we don't need the router address for execution for example. We would then potentially unnecessarily load and set the default router address when not needed. It is also not even used at the highest level EVMTychoEncoder, so it makes more sense for it to be directly associated with the swap strategy instead.
- Users will now not be able to encode for different routers without re-initializing the strategy. We assumed this use case to be very rare and not worth supporting.
2025-04-02 11:18:30 +02:00
die-herdplatte
3c982c5824 Ekubo integration 2025-03-20 09:58:40 +01:00
Diana Carvalho
57789a40e4 fix: Unify both executor addresses in one file
- Move executor_addresses.json to a top level directory
- Delete executors.json
- Use the same file for both encoding and setting executors

--- don't change below this line ---
ENG-4260 Took 19 minutes


Took 11 seconds
2025-02-26 10:10:30 +00:00
TAMARA LIPOWSKI
47b61802ee feat: Generalize group_swaps method
- This can now be used for any groupable protocols - not just USV4.
2025-02-17 17:23:29 -05:00
Diana Carvalho
f5232f403e feat: Read default executors at compile time into a json
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
2025-02-07 12:16:46 +00:00
Diana Carvalho
4680a4be24 feat: Make executors_file_path optional and use a default value if None
--- don't change below this line ---
ENG-4088 Took 4 minutes

Took 59 seconds
2025-02-07 12:16:46 +00:00
TAMARA LIPOWSKI
e83b8d9aef feat: Take Chain object containing native/wrapped addresses
- 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.
2025-02-05 17:14:56 -05:00
TAMARA LIPOWSKI
f8b3baff55 chore: merge main 2025-02-05 13:48:00 -05:00
TAMARA LIPOWSKI
8cd7d9f76e feat: Get native/wrapped addresses from chain
- These were being hardcoded to ETH and WETH, which may not always be the case for EVM-compatible chains.
2025-02-04 16:59:01 -05:00
TAMARA LIPOWSKI
4bc615913e feat: Tycho encoder validation
Validates:
- Proper sequence of input, output, and first/last swap tokens for wrap/unwrap cases
- All solutions contain at least one swap
- Only exact in solutions are inputted (since we don't yet support exact out)
2025-02-03 17:04:00 -05:00