DRAFT: CompositeLiquidityRouterV2 #1104
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The idea behind this refactoring is to use recursion for handling nested pools, as well as to represent the input arguments as a structure. Introducing the structure made it possible to apply the parameters minBptAmountOut, wethIsEth, and userData individually for each operation.
NestedAddPoolOperation
is a structure that represents a single liquidity addition operation.prevPool
— if the target pool is nested within another pool, we need to specify this. This allows the same wrapped asset to be used across multiple pools.pool
— the target pool.tokensInAmounts
— the token amounts we want to use in the operation. If one of the tokens is nested, its amount should be set to 0. If we want to add liquidity to an ERC4626, we need to specify only one element in tokensInAmounts.Example:
If we want to wrap
ETH -> WETH
andDAI -> wDAI
, as well as add liquidity toBPT_POOL_B
, the nestedPoolOperations array will be populated as follows:The order of operations will be as follows:
ETH → wETH
.DAI → wDAI
.POOL_A
(this operation is executed automatically, even if it's not in our list of operations, because its children were affected).POOL_B
.MAIN_POOL
(this operation is also executed automatically, even if it's not in our list of operations, because its children were affected).If we want to add wDAI instead of wrapping DAI, then our structure will look like this:
The order of operations will be as follows:
ETH → wETH
.POOL_A
POOL_B
.MAIN_POOL
(this operation is also executed automatically, even if it's not in our list of operations, because its children were affected).Type of change
Checklist:
main
, or there's a description of how to mergeIssue Resolution
Closes #1044