As a router provider, I would like the ability to transfer liquidity between chains

[alexwhte]

Problem

Routers today need to pull liquidity and use the bridge to move funds between chains. This is not an ideal user experience as they are the providers

Ideas to solve this

We could add a function to allow routers to do this directly

Acceptance Criteria

[ ] Router can specify a source / destination chains and token [ ] Router can specify amount of liquidity to move [ ] Router can call a service to move their liquidity to the new chain [ ] (tbd) Whatever fee structure makes sense here charges the router provider correclty [ ] Feature is gated to router providers only in some way

Other

[LayneHaber]

Are there other router liquidity convenience methods we should add? Specifically, I'm thinking we may want one that is able to removeLiquidityAndSwap so the recipient always receives the adopted asset on the chain they're receiving excess liquidity on.

cc @just-a-node @rhlsthrm

[rhlsthrm]

Are there other router liquidity convenience methods we should add? Specifically, I'm thinking we may want one that is able to removeLiquidityAndSwap so the recipient always receives the adopted asset on the chain they're receiving excess liquidity on.

cc @just-a-node @rhlsthrm

Should it just be an override for removeLiquidity that has a boolean for receiveAdopted? Seems less confusing that way.

[LayneHaber]

Should it just be an override for removeLiquidity that has a boolean for receiveAdopted? Seems less confusing that way.

Sure, could be. Are there any other, or just these two functionalities:

• [ ] remove + swap to adopted
• [ ] remove + move between chains + readd

[LayneHaber]

Also, why can't we do the second as an additional layer via multicall? Then you should have the same UX of "1 onchain transaction" (just trying to keep this minimally complex at the lowest levels)

[alexwhte]

Should be a wrapper contract

[jakekidd]

I was about to say "just pass in encoded addRouterLiquidityFor as the execute calldata" but then I remembered it's non-reentrant loll.

I'm not sure exactly how the separate contract solution would work (I see multicall helping but not solving the core problem). As far as I can tell, would require adding another call param or something so that execute can call RoutersFacet._addLiquidityForRouter (the internal method) directly to bypass the non-reentrancy for that specific case.

EDIT: By 'core problem' I meant specifically the "move between chains + readd" part

Multicall helper contract could easily handle:

• remove + swap to adopted
• remove + xcall send funds to another chain

But as far as I can tell, we'd need to do high-effort modification to core contracts to handle the "readd" on-arrival.

[LayneHaber]

not planned