Epic: Liquidity Layer should be more native to permissionless Hyperlane

[nambrot]

The existing Liquidity Layer API is in beta and was created as a experiment to see how developers could combine message processing with token bridging. Since then, a lot of has changed, and lessons have been learned, so this ticket captures the next version that would be an improvement over the current version. Specifically:

• The previous Router-based approach required the deployer/owner to permission destination chains and adapters which does not match Hyperlane's permissionless nature. There may be routes and adapters that developers want to use and requiring the deployer to whitelist and assess them is not ideal.
• Warp Routes to permissionless chains are a key part of the Hyperlane experience and need to be supported in the liquidity layer.
• It is not clear that the v1-designed atomic token transfer when processing the message is actually required. Most applications, if not all can just rely on reversion if the tokens did not arrive during message processing (and consequent retries by the relayer).

An important insight is that there is no single answer to how to bridge a token (i.e. I have token X on chain A and want token Y on chain B). Sometimes it might be a wrapped token bridge (either a warp route, canonical like Optimism or external like Wormhole), sometimes it's gonna be a DEX, but then other times its actually just the issuer (i.e. CCTP for USDC).

In effect, the liquidity layer can reduce to simple sending tokens via arbitrary bridges to an ICA of the sender on the destination and then make conventional function calls. These various mechanisms can be abstracted behind adapters that mostly implement the same interface, i.e. just transferRemote(destination, recipient, amount). On the destination chain, there can be ISMs that complete the bridge transfer to the ICA, thus each adapter most likely needs their own ISM implementation + support in the relayer (unless the token bridge relays itself)

To complete the scope of this ticket:

• Create a specification of this adapter interface (that accounts for gas payments)

• Ensure that Warp Routes work out of the box (i.e warp routes are their own adapter)

• Implement support for Circle's CCTP in that interface (i.e. a CCTPAdapter that does transferRemote and a CCTPISM that has support in the relayer)

• Deploy a demo to CCTP-enabled chains (Goerli, Fuji, Ethereum, Avalanche) as well as an example warp route

• Include a change request to the demo that shows developers how to use this new version of the liquidity layer

• Also may need CosmWasm version

### Older issues
- [ ] https://github.com/hyperlane-xyz/issues/issues/355

[nambrot]

@mellowcroc is working on this

[daniel-savu]

Bumping this, since someone recently asked for the ability to send both tokens and data via hyperlane. Seeing it's marked as a bounty but I think the original developer has stopped working on this? @avious00 @aroralanuk

[nambrot]

Yeah the linked PR has a lot of good stuff, but IMO there is plenty of work left here for somebody else to take this over

[nambrot]

We should call this something else, liquidity layer at this point has a different connotation. ICA with tokens or something