In the 2 years that IBC has been live, nearly 100 Cosmos chains have adopted the protocol and enabled tens of billions of dollars worth of cross-chain transfers. Outside of the Cosmos SDK ecosystem, to date only Composable/Picasso from the Polkadot ecosystem has adopted IBC. If the interchain community can come together around a cohesive vision, then we can push IBC across the chasm to connect more ecosystems and expand the internet of blockchains.
Ethereum and its connected L2s and rollups currently represent the vast majority of crypto economic activity due to their role as a first mover with network effects in Defi. Ethereum has been able to lead the space with superior Developer Experience (DevX) and tooling. Their killer feature, Composability, allows multiple smart contracts to be interconnected and augmented to produce new dApps. In Cosmos, IBC has enabled cross-chain composability, but the DevX and tooling still needs to mature for us to offer a credible alternative platform. Ultimately, the DevX of a new developer diving into IBC should be crystal clear, guiding them all the way from “hello world” to developing new light clients.
Interchain Queries (ICQ) and Interchain Accounts (ICA) were developed to enable IBC-connected networks to share information and automate execution across IBC channels. However, ICA is still nascent, so it contains operational issues, is incompatible with solidity, and doesn’t have tight integrations with ICQ. We need to prioritize IBC app developments to bring IBC DevX both up to par and interoperable with Ethereum. This includes building future versions of ICA, as well as promoting a strong cross-chain wide culture of end-to-end testing through interchaintest.
Trustless interoperability across blockchain ecosystems is greatly needed. So far, over $2.5 billion has been lost in hacks on centralized bridges. The crypto industry as a whole must move beyond bridges secured by multi-sigs, oracles, or custodians. For the safety of its users, the entire industry needs to transition to decentralized trustless bridges. While there isn’t currently an industry standard for trust-minimized generic message passing, IBC is the clear front-runner for connecting blockchains (just like TCP/IP connects the internet). As the crypto industry landscape continues to evolve, we need to push adoption much harder to ensure the survival and relevance of IBC. Doing so will be for the benefit of the entire crypto industry, not just the Cosmos ecosystem.
The hard part about expanding IBC
IBC enables trust-minimized bridging through blockchain light clients verifying the state of counterparty blockchains. It is expensive and time consuming to develop light clients for non-CometBFT (formerly Tendermint) blockchains and protocol libraries for non-Cosmos-SDK chains. Despite this, we at Strangelove are committed to collaborating with external partners to expand IBC:
-
Developed the Wasm IBC light client with funding from the ICF and adoption by Composable Finance
-
Working with Landslide on IBC for AVAX subnets
-
Collaborating with Penumbra on end-to-end testing for their IBC integration
-
Developed IBC Swap & Forward middleware for Duality
-
Developed Packet Forward middleware for Skip Money and Squid Router
-
Building ICS-20 smart contract composability middleware and IBC shim for Wormhole
-
Building IBC transport layer and Cosmos SDk integrations for Hyperlane
-
Continuously offer widespread support to dozens of operators of the go-relayer
The time and money hurdles mean that the various IBC core development teams can’t develop light clients for every blockchain today. We will continue to collaborate with third parties who are expanding IBC beyond the Cosmos-SDK (Composable, Penumbra, Pokt, Union, Polymer, Electron, Sovereign, Octopus, Datachain, etc.) Beyond that, we need to be efficient and take actions that will drive widespread adoption of IBC at relatively low-cost.
How do we push IBC adoption? Target Developers.
Developer Tooling – Promote Wasm light client
Strangelove completed the development of the Wasm light client, which is a huge boon for the future expansion of IBC. Now, developers can write light clients in any language that compiles to Wasm (Rust, C/C++, JS, Go, etc.). Furthermore, they can easily add or upgrade light clients without requiring a chain upgrade. Now this process is as simple as deploying a smart contract. Through releasing the Wasm light client, we’ve removed the biggest barriers for IBC adoption by effectively enabling IBC through smart contracts. We at Strangelove will double down on promoting this Wasm light client by helping external teams leverage this platform to connect more networks over IBC.
Developer Tooling – Full featured Interchaintest
A strong testing framework makes it much easier for developers to understand the structures, operations, and flows of IBC connected networks. It drastically simplifies debugging issues and acts as a validation tool for new developers’ self paced learning. We will continue to invest heavily in interchaintest to ensure that teams can perform full end-to-end testing of their IBC channels across multiple network types – all running on a developer’s workstation. We will also collaborate with cosmology/starship to maintain strong end-to-end testing standards across the entire interchain. We will continue to build up interchaintest into a full featured dev environment that makes it easy for developers to build and test new light clients across a range of coding languages and network types.
Modularity – Generalize IBC
IBC currently has many baked-in dependencies on the Cosmos SDK. For example, there are assumptions that chains have Cosmos SDK specific pieces like the bank module. Both IBC-go and IBC-rs libraries need to be modified to abstract away Cosmos SDK requirements, which will then make it much easier for other ecosystem developers to integrate IBC and expand the trust-minimized interchain. In particular, there is pressing work to generalize IBC-go and IBC-rs to unblock Pocket Network and Namada, respectively, from implementing IBC. By making IBC more generalized, we can create vastly more opportunities for IBC to connect non-Cosmos-SDK networks written in golang (Polygon, Pocket, Avalanche, Thorchain, etc.), rust (Polkadot, Solana, Near, Aptos, Sui, etc.). In addition, we need to accelerate work to develop a generalized IBC-solidity library to streamline EVM IBC integrations.
Developer Experience – Distribute IBC semantics to bridge providers
Existing bridging solutions have gained massive traction despite their inherent trust requirements. We can piggyback on their success by introducing an IBC semantics abstraction layer on top of these existing bridge solutions. Promoting the use of base IBC semantics will enable application developers to easily support multiple bridge implementations along with IBC. This work entails writing IBC shim smart contracts that translate between bridge specific semantics and base IBC semantics. We are already developing this for Hyperlane and Wormchain. Some additional bridges for which we’d love to introduce base IBC semantics abstraction layers include Axelar and Gravity bridge.
Composability – Middlewares & IBC apps
Since launch, IBC has grown to support a wide range of features, enabling rich capabilities that heavily increase customizability and interoperability. The ultimate goal of IBC is to become the default protocol for trust-minimized generic message passing, enabling asynchronous composability across the entire internet of blockchains. The development and adoption of IBC apps and middlewares enables networks to compose new functionalities while leveraging existing smart contracts and modules on other IBC-connected networks.
Strangelove maintains the cosmos/ibc-apps github repo for developers to easily find, test, and adopt a list of IBC apps and middlewares. We are dedicated to collaborating with third party teams developing their own IBC apps and middlewares by providing feedback, assisting with DevX additions (tooling, tutorials, & examples), and upstreaming their contributions into this repo. These apps and middlewares open new opportunities to develop innovative features or improve the IBC user experience (UX).
For example:
-
Interchain queries (ICQ) was developed in collaboration between Quasar, Polymer, and Strangelove. ICQ enables sovereign chains to query states of other IBC connected chains. This information can then be used to inform automated asset management strategies.
-
IBC hooks, developed by Osmosis Labs, enable token transfers to initiate contract calls. Leveraging this standard, developers can improve the UX of cross-chain swaps, as users will only need to sign one transaction to both bridge and swap. This may be superseded by ADR08 which will provide these callbacks in a more generic way.
-
Packet Forward Middleware, developed by Strangelove and adopted by Skip Money and Squid Protocol, enables token transfers to automatically forward through multiple IBC channels, allowing for improved UX. This can be useful to “unwrap” IBC tokens that have been bridged through multiple networks. This can also be used to transfer non-native assets from one chain to another, multi-hopping through the native chain in between, with only a single transaction signing.
At Strangelove, we’ll continue to promote the development of new ibc-apps projects. In parallel, we’ll continue to work with external partners to help them adopt IBC apps to improve UX for their users and increase interoperability across the interchain.
For example, extensive work is being done to revolutionize Interchain Accounts (ics999 and polytone), and we’re advising these teams to ensure their structures are compatible with IBC developments for existing bridges and solidity based chains. In future versions of ICA, users should be able to create an account on multiple chains at once and give those accounts just-in-time rights to execute remote operations on their behalf.
We also worked with Duality Labs to develop Swap & Forward IBC middleware. We’d love to work across the industry to proliferate the number of IBC apps and middlewares to enable more composable actions like staking, lending, etc..
If you are building an IBC app, please reach out! We will happily review your code and upstream your PRs into the cosmos/ibc-apps repo.
Conclusion: IBC beyond the Cosmos
IBC is the only scalable and trust-minimized solution available to connect sovereign networks. While Ethereum and other major ecosystems have congregated around centralized bridging solutions, we in the Interchain and more specifically at Strangelove have demonstrated a commitment to promoting the expansion of IBC to these networks.
This work is not easy. Everyone in the interchain has been fighting an uphill battle for over 2 years now. But the alternative is to allow crypto retail users and institutions to continue to fall prey to hacked bridges, high tolls, and fragmented user and developer experiences. We need to be focused, strategic, and collaborative to ensure the success of IBC. We’ve identified key actions that will push IBC forward:
-
Collaborate with and support various teams expanding IBC to other ecosystems
-
Promote adoption of the Wasm light client to streamline light client development
-
Generalize IBC to make it easier to adopt by more networks
-
Distribute base IBC semantics to existing validator-based bridges
-
Promote asynchronous composability through IBC apps
With the strategies listed above, we will continue to work hand-in-hand with partners like the ICF and other ecosystems’ foundations to push IBC adoption and usage everywhere. If you want to join us in this mission, please get in touch!
