DRAFT: CompositeLiquidityRouterV2

[elshan-eth]

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.

struct NestedAddPoolOperation {
        address prevPool; 
        address pool;
        uint256[] tokensInAmounts;
        uint256 minBptAmountOut;
        bool wethIsEth;
        bytes userData;
}

• 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:

                MAIN_POOL                 
                    │                     
           ─────────┴───────────          
         POOL_A               POOL_B      
          │                    │          
   ───────┴───────     ────────┴───────   
 WETH          wDAI   USDC           USDT 

If we want to wrap ETH -> WETH and DAI -> wDAI, as well as add liquidity to BPT_POOL_B, the nestedPoolOperations array will be populated as follows:

ICompositeLiquidityRouter.NestedPoolOperation[] memory nestedPoolOperations = new ICompositeLiquidityRouter.NestedPoolOperation[](2);
nestedPoolOperations[0] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: POOL_A,
            pool: wETH,
            tokensInAmounts: [ethAmount].toMemoryArray(),
            minBptAmountOut: 0,
            wethIsEth: true,
            userData: new bytes(0)
        });

nestedPoolOperations[1] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: POOL_A,
            pool: wDAI,
            tokensInAmounts: [daiAmount].toMemoryArray(),
            minBptAmountOut: 0,
            wethIsEth: false,
            userData: new bytes(0)
        });
        
nestedPoolOperations[2] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: MAIN_POOL,
            pool: POOL_B,
            tokensInAmounts: [usdcAmount, usdtAmount].toMemoryArray(),
            minBptAmountOut: 0,
            wethIsEth: false,
            userData: new bytes(0)
        });

The order of operations will be as follows:

1. Wrap ETH → wETH.
2. Wrap DAI → wDAI.
3. Add liquidity to POOL_A (this operation is executed automatically, even if it's not in our list of operations, because its children were affected).
4. Add liquidity to POOL_B.
5. Add liquidity to 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:

ICompositeLiquidityRouter.NestedPoolOperation[] memory nestedPoolOperations = new ICompositeLiquidityRouter.NestedPoolOperation[](2);
nestedPoolOperations[0] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: POOL_A,
            pool: wETH,
            tokensInAmounts: [ethAmount].toMemoryArray(),
            minBptAmountOut: 0,
            wethIsEth: true,
            userData: new bytes(0)
        });

nestedPoolOperations[1] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: MAIN_POOL,
            pool: POOL_A, // In this case, we are adding liquidity directly to `POOL_A`.
            tokensInAmounts: [0, wDAIAmount].toMemoryArray(), // The first element is set to 0 because the result for this value will be obtained after the `ETH → wETH` operation.
            minBptAmountOut: 0,
            wethIsEth: false,
            userData: new bytes(0)
        });
        
nestedPoolOperations[2] = ICompositeLiquidityRouter.NestedPoolOperation({
            prevPool: MAIN_POOL,
            pool: POOL_B,
            tokensInAmounts: [usdcAmount, usdtAmount].toMemoryArray(),
            minBptAmountOut: 0,
            wethIsEth: false,
            userData: new bytes(0)
        });

The order of operations will be as follows:

1. Wrap ETH → wETH.
2. Add liquidity to POOL_A
3. Add liquidity to POOL_B.
4. Add liquidity to 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

• Bug fix
• New feature
• Breaking change
• Dependency changes
• Code refactor / cleanup
• Optimization: [ ] gas / [ ] bytecode
• Documentation or wording changes
• Other

Checklist:

• The diff is legible and has no extraneous changes
• Complex code has been commented, including external interfaces
• Tests have 100% code coverage
• The base branch is either main, or there's a description of how to merge

Issue Resolution

Closes #1044

[jubeira]

Good job @elshan-eth!

As discussed off-thread, I think this would be a good candidate for a future iteration of the composite liquidity router. At this point the SDK team has already moved forward with the initial interface, and we won't be able to be ready to launch if we introduce a big change like this one.

I would not discard this, however. Let's keep the composite liquidity router as is, and rename the one in this PR to CompositeLiquidityRouterV2.