Allow cw-hyperlane contracts to be uploaded

Proposal Discussion DApps / Tooling
1

fusionHA
fusionHA1020Ă—767 67.9 KB

Background

This proposal is drafted with the goal of enabling Osmosis, and by extension the entire cosmos ecosystem, to expand beyond its borders and specifically into the growing set of modular chains. This should serve to funnel more assets and liquidity into the Cosmos, and allow Osmosis to continue its dominance as an interchain liquidity hub.

Details

  1. What is cw-hyperlane?

cw-hyperlane is a cross-chain arbitrary messaging protocol built with the permissionless interoperability tech stack of Hyperlane, allows users to deploy the Hyperlane Mailbox contract on any chain as desired. In layman’s terms, cw-hyperlane, is the CosmWasm implementation of Hyperlane.

By deploying the Mailbox contract on every chain, connected chains can benefit from general message passing capabilities, in addition to asset transfers, all the while leveraging Hyperlane’s Modular Security stack.

Hyperlane supported chains include: Arbitrum, Avalanche, Base, BSC, Celo, Ethereum, Gnosis, Optimism, Polygon, Moonbeam, Scroll, Solana, zkEVM and is ever expanding.

Hyperlane is implemented in the EVM, Sealevel VM (Solana), Move, and several other bespoke environments in addition to cw-hyperlane. Hyperlane’s permissionless nature has led to many external contributors implementing it in an expanding array of environments. This creates a reasonable expectation that through Hyperlane, Osmosis could expand into new ecosystems that come online.

Note: Hyperlane is in the midst of a docs migration and version upgrade that will see material documentation updates. These are going to commence next week, and with them we will provide updated links either by editing the original post, or by posting within this discussion.

The cw-hyperlane codebase was developed by the Manythings team, who have made significant contributions to the Osmosis ecosystem through projects like IBCX and ION DAO, and are now building Mitosis, a cross-chain liquidity protocol targeting the modular ecosystem.

  1. Use case & Benefit

The most immediate benefit will be the highly anticipated Celestia mainnet launch. With the launch of Hyperlane on Osmosis, TIA can be transferred to Osmosis via IBC, and then can be bridged into any chain or rollup via Hyperlane! This presents an opportunity for Osmosis to be a liquidity provider for the growing cadre of Celestia rollups, and the modular ecosystem more broadly.

Beyond the Celestia ecosystem, cw-hyperlane on Osmosis means connectivity with any chain that has Hyperlane deployed on it. This will allow Osmosis to open trade routes with any ecosystem, thanks to Hyperlane’s permissionless nature.

  1. Is cw-hyperlane audited?

cw-hyperlane contracts are undergoing audit by OakSecurity. The final report of the cw-hyperlane audit should be available within a number of weeks, as Oak is in final phases of the audit. Also, previous audit reports for Hyperlane can be found here.

About Hyperlane

Hyperlane is the first Permissionless Interoperability layer, enabling anyone to connect any blockchain, out-of-the-box. With Hyperlane, developers can build Interchain Applications, apps that abstract away the complexity of interchain interactions and serve users on any connected chain. Additionally, Hyperlane’s modular security stack gives developers the power to customize their interchain security. Hyperlane development is open-source and led by core developers at Abacus Works.

About Mitosis

Mitosis is a decentralized liquidity protocol that proposes a new paradigm in cross-chain interoperability fit for the modular blockchain ecosystem. Mitosis proposes a new DeFi primitive called “mAssets,” which allows full utilization of locked assets and enables LPs to avoid foregone yields that are imposed by today’s cross-chain protocols. Mitosis leverages strategic and technical collaboration with Hyperlane, the leading cross-chain interoperability solution for the modular future.

Links for further reading

3 Likes
2

i had one question with respect to token fungibility. the flow of TIA from Osmosis to Celestia rollups via Hyperlane seems straightforward. in the other direction, if rollup tokens are sent to Osmosis from Celestia rollups via cw-hyperlane, can those tokens be sent via IBC to all other chains? i.e. will the tokens minted by cw-hyperlane on Osmosis be CW20 tokens which can then be converted to native Cosmos Coin representations via tokenfactory, or will the tokens be of a wrapped version that’s incompatible with the IBC transport layer?

2 Likes
3

Excellent question! In the current design, tokens will be sent out of Osmosis to other chains & rollups using the Warp Route feature. When those tokens return from a rollup, back to Osmosis, they effectively go back to the original form of collateral that was used to initiate the Warp Route. So once back on Osmo all of the tokens will be back to their original forms, as opposed to returning as a wrapped version.

4

ok cool. and how about when tokens native to rollups are sent to Osmosis? are they still non-wrapped versions?

5

I like it. This certainly has my vote, which will open up more and easy access to Osmosis from other chains. One major leap forwards.

The tech is ready, now we “just” need to spread the word.

@jkol is this only available for rollups and chains where Hyperlane is installed? Or can existing Cosmos-based chains also profit from the Hyperlane to become available in other ecosystems as well?

6

i’m also wondering about the fungibility of liquidity coming over hyperlane from these other rollups – will there be a token conversion mechanism so these can be transported over IBC to other cosmos chains?

also wondering about the security of this route, i see that there are meant to be watchers but these are not implemented: https://docs.hyperlane.xyz/docs/protocol/agents/processor

wouldn’t it make sense to at least wait until there is some sort of security mechanism? otherwise you might be signalling to users that this is a viable mechanism for liquidity transport, when it is actually just preproduction (validators have no stake, there are no watchers).

2 Likes
7

@Adi for native rollup tokens sent to Osmo, those will be wrapped in the sense that collateral will be deposited on the rollup, and a representation minted on Osmo. That representation is a CW20, but can also move to other chains via Hyperlane (at the discretion of the Warp Route deployer. Warp Routes are the Hyperlane take on bridging).

@LeonoorsCryptoman yes and no! It is true that Hyperlane needs to be deployed on any chains where you’d want to communicate with (using Hyperlane), but it can be deployed permissionlessly by anyone on any chain. It’s currently already implemented for EVM, CW, and Sealevel (solana’s vm), and is in final stages of being implemented for Move and several others VMs. Any Cosmos-based chain with support for one of these VMs can have Hyperlane deployed :slight_smile:

8

@chrly The watchers are specific for certain security modules, such as the Optimistic module. In the Osmosis case validators will be a subset of the Osmosis validators to start, and expand for more coverage with time.

9

I’m curious if you’d consider using osmosis’ tokenfactory module instead of cw20. I feel like this’d be a great use case for the module + the token can be traded/transferred like a native token?

2 Likes
10

if this subset of Osmosis validators misbehave, how are they slashed without watchers in place?

11

Luckily the Manythings team has already implemented a tokenfactory version as well, so it could be used instead of cw20! happy for this to be a decision as well.

@Adi for the moment, as fraud is proveable on the source chain (Osmosis in this case) it can be easily observed and then slashing can commence from a governance process. That however is not the end state, both staking and slashing are being implemented, with a PR ready for slashing. The slashing module will allow for economic security to be deployed using any token, so it could accept OSMO or ATOM for example. All of this is being implemented over the next few months :slight_smile:

12

Very nice that the slashing will be automated.
Slashing via governance is something we really should avoid. We have touched on the subject a couple of times, but always concluded that it was a very bad path to take. So if you can avoid having social slashing via governance that would be preferable,

In addition to your answer to @chrly:
Does it mean that when sending assets via Hyperlane to other chains, they will have the same denom? So on Osmosis the asset will be IBC/1234567890, but on any other chain it will be IBC/1234567890 as well? That would greatly enhance user-friendliness, since in the current IBC-form every channel generates a different IBC/denom and is a potential threat to having the right asset fungible on the chain where you want to have it since IBC/123 is not compatible with IBC/132 as they are totally different assets. If Hyperlane would fix that, that would be awesome.

13

yea, totally agree! and yes, my question was indeed if hyperlane denoms would look the same as IBC denoms. if hyperlane used IBC transport under the hood, then the assets would be fungible and solve this issue that i was talking about before which would be awesome. +1 for hyperlane fixing that! but as it is rn it looks like the liquidity coming over would not be fungible at all, so that would be ideal to fix in order to avoid fragmentation for osmosis users imo. then you could also count on security guarantees from ibc’s proof system instead of having to wait for governance to slash (obviously, automated misbehaviour detection is probably preferable to waiting for a governance period to pass on slashing)

using the tokenfactory method above would also solve this liquidity fragmentation issue as the “vouchers” for tokens coming over hyperlane would be directly minted on osmo as ibc compatible tokens, if the osmosis users decide they trust hyperlane to bridge securely (as they have done with axelar).

1 Like
14

@jkol ? Can you share your insights with respect to the denom and IBC/Hyperlane?

15

Howdy folks, thanks for the thoughtful questions, Nam from Hyperlane here. Let me see if I get your question correct, are you asking whether hyperlane denoms are fungible with other denoms?

My understanding is that a token which is canonical from a rollup and would get bridged via Warp Routes to osmosis will have a cw20 representation on Osmosis which could then be IBC’d to any other cosmos chains as if it were native on Osmosis (and thus inherit the same fungibility properties as OSMO itself).

Speaking more concretely, if a rollup has some kind of USDC representation that gets warped over to Osmosis, such USDC would not be fungible with USDC from Noble (the same way axlUSDC is not).

I pinged the ManyThings team to chime in here as well

16

Yeah, that was indeed our question.

It would be totally amazing if Hyperlane in some way could harmonize denoms between the chains using the denom.

Such that the route used to get an asset on a chain doesn’t matter if Hyperlane is involved. But the same denom would for an asset taking route A-B-C and the same denom for A-D-E-C. That would greatly improve user-friendliness in the end, since there would be less risk of having unusable tokens on a chain.

17

To clarify the question I think is being asked and my interpretation of the situation here:

As far as the rest of Cosmos is concerned, hyperlane’d tokens to Osmosis look as though Osmosis is the source chain. (The same as ETH from Axelar bridge) This is true if they are minted with CW-20 or Tokenfactory. Minting with tokenfactory is needed imo, as there is not dex infrastructure for native CW-20 tokens on Osmosis.

The point folks are raising is that it would be great to get the same IBC transport under the hood so other chains could see the true source and unwind back to source. However this is already different from classic IBC, and I think suggests better solutions should be designed than what we do for cosmos-IBC. Namely:

  • Source chain may not have fast finality so users may prefer to use an intermediate chain (e.g. Osmosis) for this routing.
  • Alternatively have a way to treat multiple intermediate chains as equivalent. (Same problem as in IBC)

I think this is a great research direction, but would add months of delay and cause a significant miss to the real opportunity here for getting liquidity access to these other chains. Furthermore, right now getting new IBC clients is a bit notoriously difficult, and would add months to the roadmap. There is only one client on most chains (07-tendermint), and a huge amount of work for the wasm client has happened, and is still a bit out from getting to all chains.

I would personally recommend not blocking on this concern.

there would be less risk of having unusable tokens on a chain.

Hopefully front-ends / other chains decide whether they want to deploy Hyperlane natively, or use Osmosis as an intermediate step. This seems unlikely to be accidental user error, but instead due to bad FE design from another app

1 Like
18

Thanks for the feedback!

I can certainly imagine that it might not be the first step to be taken with respect to harmonising the IBC-denoms in the ecosystem, but more a dot on the horizon to make the ecosystem more user-friendly in the long run :slight_smile:

1 Like