Warp Routes should easily balance collateral on multiple chains

[nambrot]

Warp Route deployers are oftentimes interested in allowing deposits be held in collateral on multiple chains, i.e. USDC should be warped to a rollup not just from the settlement layer but from any place on which "canonical" USDC exists (Ethereum, Opitmism, Arbitrum, Polygon and Avalanche, etc.).

Warp routes currently are mostly used in a single collateral context. Nothing in the warp route contracts prevents the use of multiple chains as collateral chains. (i.e. deployed HypErc20Collateral or HypNative). However, it breaks the implicit assumption for HypErc20 holders that they will be able to withdraw the collateral at any point withouany pre-checks or conditions (excluding the ISMs and owners doing their jobs). Since the warp route deployer wants to explicitly allow for collateral to effectively be fungible across multiple chains, there has to be a mechanism to prevent users from being stuck, i.e. withdraw to a chain on which no collateral exists at the time.

There are multiple ways of accounting for this, but here is a suggested scope for this ticket:

1. On the warp UI, indicate the availability of collateral and warn + possible prevent users from withdrawing to that chain.
2. Race conditions are still possible and thus the problematic situation cannot be fully avoided. Warp Route contract's could be extended with functionality that allows a permissioned role to move the collateral via token bridges (ideally canonical ones like rollup bridges or CCTP) between the collateral chains. The reason to do it via a permissioned role would allow the warp route to pre-emptively balance. You can also imagine an unpermissioned path which allows a user to request withdrawal of collateral from another chain if the local chain cannot satisfy the withdrawal.

CLI: Additional context in Discord discussion.

### Tasks
- [ ] Make sure WarpCore config supports this use case
- [ ] Support multi collateral warp routes in the CLI

[mellowcroc]

started working on this 💪

[HariSeldon23]

Could also have another agent which allows market makers to get involved. This is what Axelar did as the latency of their transfer was just too much. If you think Avalanche to Etheruem via Axlear would need Avalanche (1s) finality, Cosmos (6s), Ethereum (a lot of seconds) it would mean that their latency would be pretty jaggy for the end users.

So what they did was allow external market makers to settle immediately and then get the tokens when they eventually arrived.

It's permissioned, but the market makers make some money for those users that are impatient.

[nambrot]

Yeah, we have been talking to other teams that also favor a liquidity-based approach. Once you reached a certain size I can see how that is beneficial, though given the permissionless nature, I would say we always need to support a method that doesn't require market makers

[1kln]

This is a great direction and a natural extension for Warp Routes and would work for simple situations. The operators of the "advanced warp routes" have to recognize though that they would be in a trade-off between liquidity (the availability of the redemption) and their subsidy of asset rotation cost.

More frequent asset rotation would allow better withdraw experience, but rotation would incur a cost (gas + potential fees), if can't be passed on to liquidity takers, the operator of the Warp Routes would have to subsidize themselves; less rotations would mean more chance for a withdraw to get stuck or re-routed to other chains.

If the goal is to 1) have a simple solution 2) have a natural extension to Warp Route, I think the best direction is to always allow 1:1 withdraws, while only allowing users to withdraw to a chain that's advantageous for the WR to maintain balanced liquidity across all the collateral chains. This way, the WR is able to push the cost of rebalancing to the liquidity takers themselves (if they REALLY want to withdraw to a chain that's low in balance, they can use an alternative liquidity routes and pay for the cost themselves). Then an external liquidity layer can be built on top of this to optionally help the user to optimize this process.

This way, the operator isn't subject to unpredictable rebalancing subsidy, and is able to have liquidity takers always rebalance liquidity for free. From liquidity taker's point of view, they either accept the suggested chain and exit, or have to pay an external (pluuggble?!) liquidity source (CCTP, Khalani etc) to help it balance to the desired destination chain.

[1kln]

I feel the design space is to take 2 of the following 3:

• fixed redemption pricing (e.g. 1:1)
• target chain freedom
• redemption availability

to get all 3 would require continuous injection of outside capital, likely in the form of operator subsidizing rotation of collateral assets.