Thoughts on Osmosis and Bridges
Recent community discussion surrounding Cosmos-Ethereum bridges and Osmosis’s credible neutrality has highlighted some important concerns. We wanted to contribute to the active and at times passionate governance participation in the ecosystem by providing commentary as to how we think about the role of bridges in the Cosmos ecosystem and Osmosis specifically.
Bridged assets are not fungible: ETH arriving across Gravity Bridge vs. ETH arriving from Axelar are two different tokens within Cosmos. This challenge is replicated with all ERC20 assets. Were Osmosis to support both versions of ETH on the front end, ETH1 and ETH2 would both appear when swapping. Rather than one liquidity pool for OSMO/ETH, there would be two: OSMO/ETH1 and OSMO/ETH2. This comes with significant detriment to user experience and dex liquidity.
User Experience
Osmosis seeks to one day overtake centralized exchanges. Therefore, the interchain user experience is one of the main pillars of Osmosis. If decentralized exchanges are going to appeal to centralized exchange users, the decentralized user experience must meet or exceed the centralized exchange user experience. The app.osmosis.zone frontend has already taken inspiration from the UX flows of centralized exchanges, such as in the Deposits/Withdrawal flows on the assets page.
On a centralized exchange, there is one version of each asset. Users have come to take this for granted, and decentralized exchanges should endeavor to meet this expectation. Like the 70 million customers on Coinbase, defi users just want a quick and easy way to buy ETH. Most don’t want to think about comparative bridge risk.
At present, most defi applications in ecosystems with multiple bridges make this entropy painfully transparent to the user.
Take the Saber DEX on Solana as an example. At present, there are eight versions of USDT depending on its originating bridge and ten of USDC, distinguished only by a cacophony of cryptic prefixes and suffixes. The intent is to provide clarity; for most users, however, it only serves to confuse.
By comparison, Osmosis made a different decision from the outset to use IBC as its native bridging solution given IBC’s security, trust-minimization, and ability to maintain a single reference token. Suppose someone deployed a bespoke bridge between the Cosmos Hub and Osmosis, resulting in two representations of ATOM on Osmosis: ATOM-IBC and ATOM-nubridge. This would cause confusion and fragment liquidity. Therefore, Osmosis incentives are directed toward a single canonical ATOM that is defined as the asset sent over IBC channel-0, as noted in the osmosis assetlist. Rather than supporting multiple versions of ATOM arriving over different channels or indirect IBC routes (i.e. Cosmos Hub -> Akash -> Osmosis), Osmosis shows and concentrates liquidity around a single ATOM.
Fragmented Liquidity
User experience aside, maintaining a single reference token improves liquidity and therefore DEX utility and economics. Constant product AMMs provide lower slippage when they have more liquidity. With multiple versions of an asset, multiple pools would arise, fragmenting liquidity, providing inferior pricing to traders, and reducing the utility of Osmosis as an exchange.
Service Providers and Credible Neutrality
To maintain a single canonical representation of bridged assets on Osmosis, we were faced with two options. The first is to integrate the bridge software into the Osmosis chain itself, run by Osmosis validators, giving it the same security properties as the chain itself. This is the approach taken by many DEX chains such as Injective and Gravity Bridge software, Thorchain and Bifrost, or Sifchain and Peggy. The second is to “outsource” bridging to external “service providers”, to spend our limited time and resources focused on building the DEX and DeFi platform into the best it can be. We have chosen to focus on the second approach.
Some have claimed that selecting a single bridge to enshrine as the canonical representation of assets contradicts principles of credible neutrality. However, we interpret the concept of credible neutrality from the perspective of a platform’s relationship to its users, not with its service providers. Using oracle solutions as an example, an oracle should be credibly neutral vis a vis its users, meaning it provides fair and equal access to all users. This is distinct from requiring a lending protocol to integrate with all available oracle solutions, or else be accused of being “anti credible neutrality.” Similarly, the Osmosis protocol needs to choose a bridge solution as its primary service provider for bridging assets from Ethereum.
But how does Osmosis choose between providers? Well, just like in picking any service provider from an oracle to a phone service to a plumber, there’s a variety of factors to take into account, including things like cost, features, reliability, customer service, ease of use, and user base network effects.
An important thing to note as well, is that mechanisms should be in place to switch service providers if necessary. For example, if the product provided by a new bridging solution is outstandingly better, Osmosis should consider switching. This prevents any incumbent bridging solution from becoming stagnant, as competing providers can compete on providing a better service. However, it should also be noted that the switching costs are quite high, as it will be a massive engineering lift and design challenge to optimize the UX of migrating from one bridge provider to another. For this reason, it is extremely important for Osmosis to choose its initial bridge provider carefully taking into account many criteria.
There are a number of EVM <> Cosmos bridge providers such as Gravity Bridge chain, Axelar, and Sifchain Peggy. In the spirit of decentralization, we believe the community should decide which provider to use. However a simple Yes or No vote on the first provider to make a proposal is likely insufficient for a decision of this magnitude. We would like to invite discussion on determining a process that the community can use to best select an initial Ethereum bridge provider.
Fungifying Assets Over Multiple Bridges
In the future, it may be possible to introduce innovative new mechanisms for fungifying assets arriving from different chains into a single asset representation. This would unify liquidity, and could potentially even enable UXs such as those found on centralized exchanges in which users can withdraw to several chains.
Once such systems are available, Osmosis can begin to integrate multiple bridge providers simultaneously. However, this is still very much at the research stage, and still quite a ways off.
We hope this post helps elucidate our thinking on bridges, user experience, and dex liquidity. Hopefully Interchain defi users can approach this conversation from a different lens and prepare them for what’s around the corner: a portal between Ethereum and Osmosis!
