Osmosis Town Hall — Choosing a Bridge Service Provider

Just two days after getting superfluid staking live on Osmosis, we held our long-expected Bridge Service Provider Town Hall, hosted by Coney Daddy with Sunny Aggarwal as our Osmosis questioner-in-chief.

Our RFP has been out since mid-February, inviting all bridge service providers to submit proposals to be the primary bridge service provider for the Cosmos-Ethereum bridge (and possibly more). We received proposals from five providers, four of whom attended today.

Bridge proposals links: Axelar, Gravity Bridge, Nomad, Wormhole

Update: Two late proposals came in on the day of the Town Hall, from Sifchain and Celer Network. They may be attending next Wednesday’s Updates from the Lab.

Sunny opened the town hall by presenting our rationale for choosing a single bridge service provider. Next, each bridge (in alphabetical order) presented its case and fielded individualized questions. Then, we got everyone together for a more general question and answer session, before closing with some ideas for next steps. Voting will begin sometime in the next two weeks, and we will make sure it is widely announced on the Commonwealth and social media. Since the Cosmos SDK does not have multiple choice voting, the mechanism for the vote will likely be a series of yes/no proposals — unless someone proposes something better!

One Bridge for Osmosis?

Cross-chain bridges are a temporary solution until IBC takes over the world. Eventually, IBC’s Interchain Standards (ICS) will allow all blockchains to communicate with each other, and asset transfers between chains will likely become uncommon. At that stage, interchain DeFi will largely consist of messages about assets that live on their native chains.

IBC is itself a bridging protocol, albeit a highly trustless, decentralized one requiring full light-client coverage of both chains. These light clients must be written in the chain’s own language (e.g. Solidity for Ethereum), which requires considerable overhead to implement. In fact, IBC clients are being built on Ethereum, Solana, and elsewhere, but until they are completed, we need temporary bridges to connect these ecosystems to the interchain.

These non-IBC bridges all involve compromises in trustlessness and decentralization, so choosing a canonical bridge for Osmosis will involve some trade-offs. Fortunately, we have a number of choices, each with its own advantages in security, UX, decentralization, development speed, and the like. We can, of course, choose different bridges for different ecosystems, but more bridges would require more development time, taking the core developers away from their primary focus: making Osmosis the premier interchain DEX.

Core developer attention is our most valuable resource, and it must be used to develop Osmosis as a DEX. Developers that can code the actual Osmosis blockchain are rare; we cannot just go out and purchase more. Those capable of doing the work are mostly here already or building their own projects.

In fact, many of our current initiatives are aimed at freeing up the core devs. We are making it easier for external devs to build on top of Osmosis with the CosmWasm integration, which is enabling Confio to build the Isotonic lending protocol and Alphaworks to create the ION DAO. Similarly, the front-end refactor will make it easier for devs to interact with our codebase. Finally, the Grants Program will let us invite even more developers to build out even more features and tooling.

The need to preserve scarce developer attention is why Osmosis chose from the beginning to outsource bridge-work. Bridges are particularly hard, and splitting focus on such difficult work can lead to vulnerabilities, as we have seen with some of the other Cosmos DEXs.

If Osmosis does not want to build a bridge, why have only a single bridge provider? Why not let the market sort out the best bridge by itself? As always, it is worth mentioning that listing on Osmosis is permissionless, and many front-ends exist beyond app.osmosis.zone, including ping.pub, citadel.one, Cosmostation, and Rango Exchange.

Beyond that, having a single canonical bridge is a matter of simplicity and user experience. Osmosis is competing with centralized exchanges that certainly do not have five versions of ETH and DAI and USDC and every other asset gumming up their UI. It would be extremely confusing and uninviting to newcomers to the space, and the alphabet soup UX is a huge pain point even for the experienced.

Beyond promoting a smooth user experience, choosing a canonical asset will incentivize further liquidity and prevent fragmentation. We would need liquidity pools for each prefixed asset coming over multiple bridges, which would spread the liquidity out, making the trading experience much worse (mainly higher price impacts, but also extra fees to trade through multiple versions of an asset). Additionally, as we have been saying in recent weeks, we must use our incentives more strategically, to nudge liquidity where it is most desirable, rather than simply giving incentives to every pool. Fragmented asset pools will only further reduce our ability to do this.

That is why we are selecting a single bridge provider for Osmosis-Ethereum transfers. For further background, see “Thoughts on Osmosis and Bridges.”

And now, on to the bridges!

Axelar

Sergey Gorbunov is one of the co-founders of Axelar. He has deep roots in the field, having co-written, for example, the proposal to standardize the use of BLS digital signatures. He and co-founder Georgios Vlachos were working at Algorand when they concluded that interchain communication was the likely future of blockchain technology, as well as one of the hardest, most interesting problems to solve in the space. Having started only a year and half ago, Axelar now has a 25-person team with deep roots in cryptography and distributed systems.

Axelar is a “decentralized overlay network” that connects different blockchain stacks. The Axelar Network was built with the Cosmos SDK and connected to IBC for use as a cross-chain zone. It is permissionless, meaning that anyone can join, submit transactions, relay, and validate. Axelar also consists of a set APIs and SDKs that make it easy for applications like Osmosis to connect cross-chain and attractive for developers to build out more functionality.

The Axelar router makes it easy to onboard new chains. Already five EVM chains have been connected to Axelar, and they are working to set up IBC connections to them. Routing also allows you to interact with cross-chain functionalities in the same way that you would with centralized solutions. The primary driver behind this is Axelar’s deposit-address system. In this system, a deposit address is first generated on the source chain. Then, that source-chain address is linked with a specific account on the destination chain, thereby creating a routing path that the user does not have to interact with. The Axelar validators custody the deposit addresses, observe transactions come on-chain, enact a finality gadget, and send funds cross-chain.

Sunny emphasized the smoothness of this deposit address system. It allows “dumb wallet” UX, simple sends which are much smoother than the “smart wallet” UX of having to sign a complex transaction. Dumb wallet capability enables you to bypass smart wallets like MetaMask even when bridging funds from Ethereum. Deposit addresses will thus allow Osmosis to mimic the easy depositing available on centralized exchanges, and you never have to have the wallets of other chains installed to bridge assets from them. This is also useful for reaching more people, as Sergey added, since there are only 12 million MetaMask users, but about ten times as many DeFi users that use other wallets.

Axelar is building translations across many different ecosystems: EVM, Bitcoin, and other proof-of-work chains. As each ecosystem is added, every ecosystem can connect to every other previously connected chain. All the networks speak different languages, and Axelar is the translator. If Axelar is integrated with Osmosis, you would before long be able to bridge to multiple chains just by using the Osmosis frontend and Keplr with Axelar in the background.

Bridging time depends on the latency of the source and destination chains. Axelar adds an additional 20–30 seconds to finalize the transaction, but this can be greatly lowered in the future. Bridging fees are currently 0.1%, but they are not entirely set at the moment, and Sergey expects them to be lower in the future.

Regarding cross-chain security, Sergey takes it as axiomatic that one should minimize additional trust assumptions. Therefore, it follows that bridging solutions should be at least as secure as the chains being bridged. Axelar’s solution to this is having a Cosmos chain, one with a similar validator set to other chains. Additionally, they are heavily invested in securing their smart contracts and in applying cutting-edge cryptography.

Is the validator set sufficiently decentralized, and are the tokens well distributed? Sergey says that team and operational company have 30%, and the foundation has 40% to use for building the ecosystem. Investors presumably have the other 30%. In their RFP, Axelar pledged 5% of AXL tokens to an insurance fund, and at least 1% of tokens for Osmosis incentives, if they become the Osmosis bridge provider. Since Axelar mainnet is less than a month old, the token supply is not yet fully distributed and validators are still being onboarded; however, there were 100 on the testnet, including many of the usual Cosmos validators.

“We have a deep roadmap, and we are committed to this. It is one of the hardest problems for the ecosystem, but that’s what makes us tick and makes us excited to work on it.”

Gravity Bridge

Justin Kilpatrick and Deborah Simpier from Althea represented Gravity Bridge. Gravity is a deeply Cosmos-based bridge whose codebase has been worked on by many early Cosmos teams. Althea started working on Gravity around two years ago because they needed a stablecoin bridge for their distributed internet provision blockchain.

Because they had seen other bridges fail due to feature bloat and over-abstraction, they prioritized stability and reliability. This focus on simplicity led them to make their Solidity contract (gravity.sol) non-upgradeable, whereas the other bridges can be upgraded by multi-sig wallets. This means the validators and their delegators are completely in control of the Gravity Bridge, and no one else can change the code. That said, functionality can be added to the contract without upgrading it. The one complex feature Gravity added was batching, which enables users to make smaller transactions without being completely eaten up by Ethereum’s high gas fees.

When might the Gravity Bridge might be able to support multiple EVMs? The sooner Osmosis has access to those ecosystems, the better positioned it will be as the interchain DEX. Justin thinks that, conservatively, they can connect to other EVMs by the end of the year, and, less conservatively, they could have the bulk of the work done in two months. Setting up the relayers and testing would take more time. Axelar-style deposit addresses could be added to Gravity, but the timeline for that is unclear.

NFT transfers are slated for the end of summer. The Gravity Bridge team has been working with Stargaze, who has announced that they will be using Gravity Bridge for cross-chain NFTs. Interchain accounts, which would enable the Osmosis Community Pool to own its own ENS name, are possible sooner, since the Gravity Bridge is already fully capable of performing arbitrary actions on Ethereum. All that would be needed is an additional widget. Finally, cross-chain price oracles and metadata are being worked on and considered for integration with an IBC module.

Sunny was curious about how the team plans to split its time between their Althea project and the Gravity Bridge, given the difficulties of bridging and the focused attention that other teams are bringing to the table. Althea sees Gravity Bridge as a Cosmos public work — the plumbing of the Cosmos — and while municipal projects are not generally known for their speed and efficiency, they usually do a good job of providing a stable supply.

Nomad

Representing Nomad were Pranay Mohan and James Prestwich, and their decentralized liquidity partner, Connext, represented by Arjun Bhuptani. Nomad is set to become a prominent bridge in the Cosmos, since it is being adopted by Evmos.

Nomad bridges optimistically and uses Connext to deliver funds before the roughly 30-minute optimistic window closes. This optimistic model allows them to do away with the security measures of multi-sigs, validators, and peg zones. Instead, a single Updater locks up tokens and mints them on the destination chain or, conversely, burns the receipts to unlock funds on the original home chain. These bridging transactions are watched by a group of fraud-detectors called Watchers.

As long as there is one honest Watcher, a fraud proof can be submitted to prevent fraudulent transactions. On the other hand, the ability of any Watcher to stop the chain at any time presents a griefing vector. This is a problem, since there are occasions, like forced liquidations, where stopping transactions from going through can be a profitable attack. Liveness and safety are intertwined in this model.

At the moment, this griefing is not possible, since the Updater and the Watchers are controlled by Nomad. However, the team is planning to allow chains to select their own sets of Watchers, which is good because it will decentralize the bridge and make the Updater less corruptible, but bad because it re-introduces the griefing vector. Further, chains will have to curate their Watcher set and rely on reputation/total value in the system to ensure that they do not attack. Each individualized Watcher set also creates a new set of token representations that are non-fungible, though there may be ways around this.

Sunny suggested that attacks might be possible when the destination chain goes down for updates through the vector of the optimistic window. However, Pranay said that the relayer could be taken down for that amount of time, and since Nomad fraud proofs are measured in blocks, the optimistic window would stay open during the downtime. Further, Arjun from Connext said that in case of attacks Nomad could pause the bridge, and further that, assuming Connext has enough liquidity, its liquidity providers are the ones that take the risk of funds being stolen.

Regarding UX, Sunny asked whether the lack of a chain would mean that sending ETH from Osmosis to Avalanche would have to involve a transaction on mainnet Ethereum. Arjun said that transfers covered by Connext could go directly, and Pranay added that larger amounts could eventually be handled with CosmWasm contracts.

Sunny asked whether Connext was working with any other bridges, since it would benefit their liquidity providers to have access to all avenues for liquidity. Arjun said that Connext is essentially married to Nomad because they prefer non-validator-controlled bridges. At the same time, he said that Connext is planning eventually to remove its whitelist for adding new liquidity paths, though having one primary transport layer (Nomad) is more efficient for them.

Finally, Sunny asked about the attack on Pranay’s and James’ previous project, the Optics Bridge. Pranay said that he could not get into all the details, but that it was not exactly an attack. The contracts involved in the bridge were upgradeable, and the multi-sig was somehow compromised. However, Nomad is a separate project with a multi-sig that they are planning to democratize over time, hopefully with Cosmos participants.

Wormhole

Kanav Kariya, president of Jump Crypto, and Hendrik Hofstadt, of Jump and Certus One, presented the Wormhole proposal. Wormhole is connected to 8 blockchains currently, and expects to be connected to 15–16 by the end of the year. In its roughly 12 months months of operation, it has become the default bridge for Solana (where it began) and for Terra, and has $800-$900m in the Portal Bridge contracts, which would be a source of volume and TVL for Osmosis. Their NFT bridge is live, and there is a CosmWasm bridge for NFTs currently undergoing audits.

Wormhole is a Proof of Authority multi-sig bridge with 19 Guardians, many of whom are Cosmos validators. They are largely agnostic about trust models and will move quickly to adapt whatever new technologies come along to make the bridge as secure as possible.

Axelar’s deposit address feature is also supported by Wormhole. Right now, Wormhole gives you attestations when you bridge that you then redeem on the destination chain, which is a bit clunky, but the team is working on a relayer network where you’ll be able to take part of the funds you are bridging and use them to pay for relaying and redeeming to occur in the background. Most of the code for this is done, and it has to go through audits, and they have to make a widget for estimating fees. A further benefit is that all wrapped assets on Wormhole are fungible, so you do not have to hop through multiple chains and pay their fees.

Wormhole is the most trad-fi of the bridges we are considering. This is positive when there is an $320 million hack, and users can instantly be made whole (though Kanav makes no promises about self-insuring future hacks). It also means that they are well positioned to pivot quickly and to pay a hefty premium for research and security audits. They can afford to take multiple bets on the future and hedge them intelligently.

On the other hand, their governance is somewhat opaque and centralized, and it is natural for a decentralized exchange to be somewhat suspicious of a hugely successful trading firm. In general, their stated thesis is that, at this stage in the development of crypto, building in the space is a greater expected value play (EV+) than trading. They will adopt the best solutions (like threshold encryption) insofar as they can, though they have not committed yet to a monetization model for their bridge.

Among the things they are building is a Cosmos chain, not to serve as a bridge, but to run their accounting. The Cosmos chain would track the balances of all the chains being bridged, in order to prevent the transfer of unbacked funds, and governance would also live there. It is not clear what the token distribution would be for this new chain, or what parameters would be governable.

They ended their session with an interesting idea that I’d be curious to hear more about: treating Wormhole as the UDP (user datagram protocol) of cross-chain messaging, which they say could enable them to tunnel IBC and replace the light clients. They are actively working on this and hope to be rolling it out very soon. If they are serious about bringing IBC and ICS standards to other ecosystems, that would be a good thing. Could the other bridges do something similar?

Q & A

There’s something to be said for being battle tested — what measures do you have to ensure that funds are safu?

Sergey/Axelar: Cryptographic solutions and engineering are key, as are audits and open validator sets, and 5% of AXL is dedicated to an insurance fund.

Justin/Gravity: An insurance fund would be up to the validators to use the community pool, but it would be likely, and Gravity is the only bridge with non-upgradeable contracts.

Pranay/Nomad: It is useful not to have to worry about the underlying infrastructure (i.e. there’s no Nomad chain), and it only takes one honest Watcher to prevent fraud. James added that Nomad handles economic vulnerabilities the best of all the bridges.

Hendrik/Wormhole: Bridge software is like a rocket ship — it needs to be perfect at launch, so rigorous processes, tests, and audits are necessary. Further, the Guardians run monitoring software and can shut down the bridge when they notice potential fraud.

Can your bridge be rate-limited to prevent catastrophic loss in case of an exploit? Can stuck funds be recovered?

Sergey/Axelar: We have rate-limiting functionality, but it is not enabled at the moment. Regarding stuck funds, given our deposit contracts, there is essentially a deposit handler, so if a user sends an asset incorrectly, it can be sent back. You might also be able to set time-outs, but these would have to work around some synchrony assumptions.

Justin/Gravity: We have evidence-based slashing, so if a validator submits something fraudulently, the can be ejected from the validator set. There is also logic to make the chain stop if there are inconsistencies. There are no rate limits because these present a potential liveness issue, e.g. if someone deposits a large sum and then immediately withdraws it.

Pranay/Nomad: In the worst cases, you can rate-limit, and Nomad’s latency window offers considerable time in which to do so. In the case of stuck funds, having a single Updater is a strength.

Kanav/Wormhole: Rate-limits should be used, but they are hard because they introduce new attack vectors. There are not always obvious answers. Hendrik adds that rate-limiting just induces attackers to make multiple smaller transfers, and global limits impose a liveness risk.

What’s the cleanest integration UX-wise for Osmosis?

Sunny: We care a lot about having direct deposits, that is, not having to use intermediate chains, but going straight from Ethereum to Osmosis. As of now, the only chain that supports this is Axelar. Osmosis built the Bech32-IBC that any Cosmos SDK chain can import to make it easier to do cross-chain multi-hop transactions. Gravity is working to integrate this.

Wormhole is a different model: they would be minting tokens on Osmosis with CosmWasm, so we would need to finish the module that allows CosmWasm to mint and burn Cosmos native coins. Hendrik added that Wormhole has also built a module for this for their Cosmos Wormhole chain.

Pranay said that there is a module on Evmos that combines Nomad transfers with an IBC transaction. He also emphasized that Evmos sees itself as a partner to Osmosis and the whole Cosmos, not a competitor. And again, with Connext, you are always going point to point, skipping intermediate chains.

Who will give us an API to plug into our front-end to enable users to bridge using only the Osmosis front-end?

We want Osmosis user to be able to bridge into Osmosis using only the Deposit and Withdraw buttons on the Osmosis Assets page, without having to go to any other websites or apps. Adding an external site for bridging should only be for a brief time.

Pranay/Nomad: On Moonbeam, there are a couple of AMMs that have already built the Nomad SDK into their apps. We want users not to have to interact directly with Nomad, but with Connext, or, better, with just their home chain, or, best of all, with just their wallet. These additional UX improvements can always be added over time. Security is paramount, and Nomad’s is best.

Sergey/Axelar: Nomad is not necessarily more secure. Optimistic protocols risk both safety and liveness in the event of a DDoS attack, rather than just liveness, as in a bridge with validators.

James/Nomad: This analysis is incorrect. In a cross-chain bridge, a 2/3 majority of validators can produce a invalid update. And while on a single chain, that can be fixed with a minority fork, in the cross-chain world, false value is injected into the destination ecosystem. And though it is true that Nomad contains a griefing vector where one Watcher can halt the chain at any time, we can disincentivize that far less expensively than disincentivizing an attack on a validator-run bridge.

Sunny: Until we have permissionless Watchers, BFT-consensus validator sets are definitely better. With permissionless Watchers, I am still not sure because of the potential griefing and non-fungibility between disparate Watcher sets. But in any case, this raises the larger question of economic security in the Cosmos. We are moving toward a web of multi-lateral shared security. Gravity Bridge wants to share security with the Cosmos Hub, and it may also share security with Osmosis and other chains. The Cosmos is going to turn into a giant mesh of interlocking security.

James/Nomad: That’s why I’m bullish on Cosmos and IBC. However, when you are bridging, your security assumptions are always the addition of source, destination, and bridge chains. Bridge chains add risk.

Justin/Gravity: We can talk about ideal security, but all these upgradeable contracts in the other bridges are very insecure.

Sunny: Is time-locked upgradeability okay? In other words, a multi-sig could only step in in certain circumstances, e.g. an unplanned chain halt, or the multi-sig can only act if it locks its transactions a month in advance.

Justin/Gravity: That’s certainly better, and there are some cases where these sorts of things can work, although with a time-lock there is a potential for forks. Ultimately, nothing short of the full consensus-set voting on an upgrade is really acceptable. Gravity therefore has an accretive model of adding features that interact with the existing contract, rather than progressively decentralizing access to it.

James/Nomad: Systems have to upgrade: even TCP/IP has gone through slow, painful upgrades. The only decentralized systems upgrade mechanism that has really seemed to work is the hard fork mechanism, where people who do not like the changes can leave.

Kanav/Wormhole: Wormhole already has a very well developed SDK that is in use by three major exchanges, wallets, bridge.terra.money, and other places.

Expected timeline for Gravity Bridge API?

Justin: Deposit address forwarding will be available by the end of the month, and we’ll be using Bech32-IBC as well. Client libraries for these will be out when these are deployed. We have guides for Typescript, Rust, and Go, and this will be packaged into a proper SDK as soon as the features are out. That will be at the end of March for Ethereum → Osmosis, and for Osmosis → Ethereum maybe two months if we can get interchain accounts running by then.

Can we use multiple bridges for exclusive tokens?

Sunny: Yes, but fewer bridges be better because it will take much less development time. We certainly would like only one bridge for all EVMs (except for special requests/edge cases, like pStake). Multiple bridges might make more sense for other ecosystems, given the different core competencies of each bridge. For example, Wormhole is the only bridge provider for Solana at the moment, so unless someone else has a pitch for Solana, we will probably have to use them.

Next Steps

And that’s it! This was an information-gathering meeting, and we hope this format (the video and this recap) is perhaps a little more digestible than reading through all the RFPs.

As I mentioned in the introduction, I’ve proposed a multiple-choice voting process, but if someone has a better idea, please post it to Commonwealth soon. We’d like to get this decision made in the next week or two!

We will certainly have more bridge talk at next Wednesday’s Updates from the Lab. Check out your usual social media outlets, and make your voice heard! This is a community decision. The Osmosis Discord has had perhaps the most lively debate, since Robo McGobo created a special channel for bridge discussions, and representatives from the various teams have been quite responsive there.

Enter the laboratory at Osmosis.zone, the first decentralized exchange powered by the Cosmos SDK and IBC. See our published lab reports at the Osmosis blog, our bench notes at GitHub, and help plan future experiments in our Commonwealth

Connect with other DeFi Scientists by following us on Telegram, Twitter, Discord, Reddit, and the new Facebook and Instagram pages

Reach out to the Osmosis Ministry of Marketing by Email or Twitter and the Osmosis Support Lab by Email or Twitter