Add Wormhole as a Canonical Bridge Service Provider

Proposal Discussion
1

This proposal would recognize Wormhole as a Canonical bridge service provider (BSP) for Osmosis.

Canonical bridge providers originally had expectations defined in Proposal 205. This proposal modifies those expectations to facilitate the addition of a second canonical bridge.

About Wormhole Gateway

First announced at OsmoCon 2023, Wormhole is entering the Cosmos with a new Cosmos SDK chain called Gateway. Built on the Cosmos SDK, Gateway is a fully IBC compatible zone for the Wormhole Messaging protocol. This will enable the Wormhole ecosystem to bring liquidity and developer activity into the Cosmos by seamlessly connecting all Cosmos chains to external chains supported by Wormhole, including Ethereum and Solana.

Wormhole has consistently ranked as best in class in security, with the most recent review carried out by Uniswap unconditionally approving Wormhole. Wormhole messaging is managed by 19 Guardians, who transmit across over 23 chains and would be the validators for Gateway.

Gateway allows Wormhole to add two major security features to the existing Wormhole messaging platform, improving the security for all chains already connected via Wormhole:

First, the Global Accountant allows the open audit and tracking of all assets within the Wormhole ecosystem, ensuring that the wrapped asset and the native asset are always at a 1:1 parity.

Second, the Governor enables the limitation of asset flow to a risk ceiling controlled by Guardians. In the event of a smart contract issue or a blockchain vulnerability, any contagion is prevented.

Gateway will also have zero added fees to bring liquidity into the Cosmos from Wormhole connected chains with minimal cost to users and enable frictionless movement between IBC-enabled chains and those without. The Wormhole ecosystem believes that in order for the interchain to thrive, bridging protocols cannot extract rent, and takes a similar position to IBC as a free-to-use protocol.

Permissionless asset listing will also be available, enabling the rapid proliferation of tokens across the Cosmos, regardless of where they originated.

Enabling Wormhole as a Canonical bridge service provider will initially provide a more familiar user experience for transferring assets from multiple non-EVM chains to Osmosis via the on-chain Guardian set. This includes chains and assets that are currently unavailable on Osmosis such as:

  • Solana
  • Near
  • Algorand
  • Aptos
  • Sui

Additional connections via Wormhole Gateway allow Osmosis to further compete with Centralised Exchanges as a premier trading venue with a wide variety of assets. Duplicate connections may also be leveraged to improve the security of canonical assets by diversifying the route assets travel to reach the chain.

Expectations of Bridge Service Provider (BSP) Relationship

Front-end Display

The BSP will be integrated into the main Osmosis front-end to provide canonical, unprefixed bridged assets upon arrival onto Osmosis.

In the event of multiple canonical bridge providers, incumbent canonical assets will retain the non-affixed symbol listing, with only the novel assets appearing as the non-affixed version.

I.e., ETH obtained via the incumbent Axelar canonical bridge will remain displayed as ETH, and ETH obtained via Wormhole will be displayed with an affix such as whETH.

SOL obtained via Wormhole will be displayed with no affix as SOL.

In the event that a Wormhole asset has more liquidity on Osmosis than an Axelar asset for a consistent two-week period of time, the affix will change to reflect the higher liquidity asset.

This arrangement is likely temporary, and future proposals will be debated to improve user experience, likely in conjunction with the new Transmuter pool type.

Osmosis Incentives

Osmosis commits to prioritizing the assets of the canonical bridge, incentivizing them earlier and more heavily than the comparable assets of non-canonical bridges. Canonical pools should earn substantially more incentives per dollar of liquidity than their counterpart pools under the base incentives model, not including any external incentive matching.

Integration

The BSP will work to enable integrations following Osmosis’ goal of achieving deposits and withdrawals from the app.osmosis.zone interface and wallets without requiring pass-through to a bridge-specific UI.

Revocability

Osmosis DAO and the BSP will work together for mutual benefit without contractual promise or obligation. The Osmosis DAO must ratify any change to the canonical status of the BSP. Any damage for bad behavior by either party will be reputation alone. This disclaimer does not cover specific promises between the BSP and an individual user.

Target On-chain Date: August 07 2023

References and Links

Wormhole Security: https://wormhole.com/security/
Wormhole Bug Bounty Program: https://wormhole.com/bounty/
Community Links and Social Channels: https://wormhole.com/community/
Wormhole Blog: https://wormhole.com/blog/

7 Likes
2

Thanks for putting this up!

I can see the advantages of having a second bridge available, also for security reasons. I like also your mention with the Transmuter pool type (Upload Transmuter Contract - #4 by LeonoorsCryptoman), because that will greatly enhance the UX for bridged assets which might have different affixes. I can indeed imagine that the user bridges an asset; shows just the asset on the Osmosis front-end; and where the backend takes care of the necessary swaps to give the user the best swap-rates.

Good that you also give a mention already how we should cope with assets which are already bridged by our current canonical BSP Axelar.

How do you see the part where the affix has to change for the leading bridged asset? Are you not worrying that it might be a bad UX for the people who already bridged the asset in the past from the leading bridge provider at that time? They might be confused that they now have another asset than they had in their wallets. I personally would like to hold that part of the proposal until we are more clear on what the Transmuter contracts can do for us. The problem might solve itself that way already.

3

This would just be a temporary solution, and for Ethereum assets is extremely unlikely to happen in the few weeks it will take for the transmuter to be live. The transmuter will indeed solve this issue, as the canonical representation will be the transmuter pool LP derivative version instead!

4

Exciting!

Could we get more details on how the Gateway-enabled smart contracts would work on Osmosis?

I am curious how it’ll differ from the existing Wormhole contracts on other cosmos chains like Injective and XPLA.

Thanks.

1 Like
5

I would even like to go further.

I would like to get rid of the canonical and affixed versions on the front-end.
Just display “ETH” and let the back-end do all the magic when swapping. Or is that what you mean with; “The transmuter will indeed solve this issue, as the canonical representation will be the transmuter pool LP derivative version instead!”
And you actually mean that the transmuter will have some sort of derivative version called “ETH” and the pool does the underlying magic?

Furthermore; if it is unlikely to happen in the few coming weeks before Transmuter goes live, then please leave it out of the proposal, since it only adds confusion and does not add value if it is not going to happen anyway ^^

6

Major yes on this proposal. This has been a long-time coming. Osmosis needs bridge diversity quite badly from large bridges with lindy like Wormhole.

I love that Wormhole has no added fees. This should facilitate a much cheaper bridging experience than Axelar in times of high volume on Ethereum. The addition of the transmuter contract is a nice touch as well.

Sunny mentioned at Osmocon that the way this will effectively work is that you can add axlETH and wormholeETH to a liquidity pool governed by the transmuter, and the LP token from that pool will become the canonical version of ETH. This solves for a lot of fungibility issues and asset denom confusion with multiple bridges while at the same time de-risking us from a security reliance on just one canonical bridge.

This should also open up a ton of lucrative markets for cross-chain arbitrage (and just a general liquidity influx period).

I’m excited to see new assets on Osmosis due to this integration as well, particularly things like $SOL and $BONK. There’s a lot of crossover between the Osmosis and Solana communities, and I think Osmosis has the potential to be a very competitive market (potentially even a primary market) for Solana assets.

1 Like
7

Yep, that’s correct! Going to paste some language here from @JohnnyWyles because, as usual, he explains it much better than me :sweat_smile:

Still needs the Wormhole, Transmuter and a Multiasset prop (that I’m still writing) to be passed. The actual asset in that pool wouldn’t change, but we’d move to all pools being osmo.ETH (named ETH on the frontend) with wormETH and axlETH underlying. You would deposit either of those to the Transmuter Contract to get the Canonical ETH, but for most users they would get this done automatically on deposit.

8

I’m very excited for this and the possibilities it opens with the transmuter. I appreciate the rethinking of canonical as the token that has the most liquidity being the canonical representation of a given asset.

Supportive and excited for this!

Jacob G. asked about the code for this so I thought I would share it here for reference.

github repo for gateway: https://github.com/wormhole-foundation/wormhole/tree/main/wormchain

3 Likes
9

This was raised in a few other places too. Maybe that clause could be adjusted to be something along the lines of consistently higher liquidity for 2 weeks to prevent any UI confusion in the event of a liquidity war before we have ironed out and deployed the Multiassets?

3 Likes
10

In favor of having Wormhole as a canonical bridge service provider!

We fully support highlighting & closely collaborating with a few quality bridge partners to improve liquidity, trading routes, UX, safety but we prefer bridged assets with an affix.

Short-to mid-term, we expect ongoing changes among the best bridge service providers (standards, liquidity, security issues, dominance). Hence, it would make more(?) sense to use the specific asset name in order to not confuse users or discourage other projects.

If we understand the transmuter pool LP derivative correctly, this should become the asset without affix → USDT (osmo), ETH (osmo) for the best user experience. Related Qs below:

  • Buying X = osmoX would route to whitelisted underlying assets through the best trade route. So, there will be no shared asset pool? It’s just a frontend proxy asset for simplicity?
  • Will there be configurability for users to select underlying assets they do NOT want?
  • Could it become interesting one day to actually establish a shared underlying pool for better liquidity - essentially similar to Curve’s stablecoin 3Pool or Balancer’s LST pool? Such a derivative token takes in risks from underl. assets but reduces total value at risk.

Our final notes/takes for good, simple, safe UX & enabling high value transfers:

  1. USDC = osmoUSDC (the derivative USDC)
  2. axlUSDT, whUSDT (specific names of all bridged USDC)
  3. Improve search on the Osmosis app
    a) show only usdc assets when searching for usdc
    b) Add tokenlist / Assetlist to frontend (Osmo assets, liquid assets, wh assets, list by xyz)
    c) Show safe, liquid assets on top of search (-> canonical bridges → axlUSDC, whUSDC)
  4. Full support for earlier, bigger liquidity incentives for key pairs, (canonical) bridged assets
  5. With 2+ quality bridges, it’s also time to start collab w/ leading bridge aggregators (LIFI; Socket) for better user onboarding, liquidity routes from any chain to x assets on Osmosis. If they support osmoX, underlying canonical bridges would further benefit
11

Wormhole uses ICS20 to bridge assets from Gateway to Cosmos chains like Osmosis. All assets bridged via Wormhole Gateway into the cosmos are fungible via IBC with unified liquidity across chains. There are no Wormhole smart contracts that are deployed on Osmosis.

Cosmos chains like INJ and XPLA use a legacy integration where the Wormhole cosmwasm contract stack was deployed on chain. Assets were bridged directly onto Cosmos chains and only fungible via Wormhole messaging.

Using Gateway results in an easier integration for Cosmos chains and protocols.

1 Like
12

Oh that’s a big difference, thanks for explaining.

Then, can we assume there will be no general message passing from Osmosis (ie. no way to compose a custom VAA payload)?

If so, are there future plans to add this for full-feature parity with other Wormhole deployments?

13

I’m pretty sure that GMP would still be accomplished by uploading the relevant smart contracts to Osmosis in addition to this deployment. Shouldn’t be too much of an additional lift, but would require another gov prop or two to approve the contract deployment.

This is similar to how Axelar does it, AFAIU (for example, the Squid contracts)

1 Like
14

Oh wasn’t familiar w/ the Axelar setup, thank you.

Could we try to get that capability in too, maybe as a “fast-followup”? GMP would be pretty awesome, especially for folks building dapps/protocols on top of Osmosis.

1 Like
15

a PoA bridge managed by 19 Guardians, some of them (I assume) US based?

has anyone done a legal DD on this?

sounds to me like an unregistered money transmitter scheme or sth. certainly not decentralized, hence the additional legal risk from US LE.

would love to have lawyers comment on this. r/r seems bad at first glance rn

16

I had to get over the jitters from the word “canonical” but this actually doesn’t sound too bad.

17

There’s been some chatter about Wormhole security after their hack 18 months ago. I’ve attached some files and links to this post that shows all of the measures that have been taken after the hack for folks to look at. They have a ton of varied security measures.

They also have one of the best security teams in the space. This is the same team that found bugs in two cosmos chains (celer and Stride) and one bug in IBC.

Wormhole digs out of its hole with new security measures to move on from $320M hack _ TechCrunch (1).pdf (4.7 MB)

1 Like
18

Robo thanks for all the info. Wanted to ask if you’re working for wormhole or osmosis in any capacity? Appreciate your help as always but if there is some reason for the generous support think it would be important for the community to know.

1 Like
19

Hey Luis!

Candidly, I have been advising wormhole foundation on Cosmos and their Cosmos launch, but I don’t work for the wormhole foundation.

I also had nothing to do with drafting this proposal. I do very much want this to pass though, and have wanted that since the first bridge vote.

Also, as many know, i’m on the reviewer committee for Osmosis Grants who, AFAIK, have no interest in whether this proposal passes or fails apart from maybe some cool potential future grants? I don’t work for Osmosis.

2 Likes
20

Appreciate it Robo. Hyped for Wormhole.