⚛️Connecting Existing Cosmos dApps to Avalanche

READ THIS: While you can connect any Cosmos-dApp, it will NOT communicate over IBC until the Landslide AVAX Light Client is released in 3-5 months. Stay tuned.


By implementing the necessary ABCI calls, developers can connect their existing Cosmos dApps to the Avalanche network using Landslide Core. This allows them to take advantage of the benefits of the Avalanche network, including faster finality times and IBC compatibility.


One of the most significant advantages that Avalanche brings to the table is faster finality times. The Avalanche consensus protocol enables blazing fast transaction confirmations, typically in the range of sub-second to a few seconds. This is a substantial improvement compared to native Tendermint, where users often have to wait 3-8 seconds to achieve transaction finality.

For Cosmos dApps, faster finality times translate into a multitude of benefits:

  1. Improved user experience: Users can execute trades swiftly and enjoy seamless interaction with Avalanche. This will not only attract more users but also encourage existing ones to engage more frequently, ultimately driving up our user retention and growth.

  2. Increased liquidity: With faster finality times, Landslide can process more transactions per second, leading to higher trading volumes. This increased liquidity will help create a more robust market and improve price discovery, benefitting all Cosmos users.

  3. Reduced risk of liquidations: Faster finality times minimize the risk of cascading liquidations due to market volatility, as users can adjust their positions more promptly. This will help protect our users' assets and boost their confidence in our platform.

  4. Enhanced arbitrage opportunities: Quicker transaction times enable efficient cross-chain arbitrage, allowing traders to take advantage of price discrepancies across different platforms. This will attract sophisticated traders and lead to a more mature ecosystem.

Deploying an outpost on Avalanche is a strategic move that can greatly benefit any Cosmos dApp by capitalizing on the faster finality times. This will not only improve the user experience but also contribute to the overall growth and success of Cosmos.

Sharing Liquidity: Outposts

A Landslide outpost: The term "outpost" refers to a specialized deployment of the existing CosmWasm software stack, such as White Whale, on another blockchain network. The purpose of establishing an outpost is to use the already existing software stack and just change the consensus algorithm to expand the dApp's reach, functionality, and interoperability by tapping into the unique features and advantages of the target blockchain network.

Avalanche Warp Messaging (AWM) allows any Avalanche Subnet to quickly send arbitrary messages to another Subnet, without relying on a trusted relayer or bridge. This is made possible by utilizing the validators of the sending Subnet. The messages are delivered in just a few seconds, or even less. AWM enables liquidity sharing between subnets and the P-chain.

Problem: If a Cosmos dApp like White Whale wants to deploy on Avalanche, it is currently impossible because it cannot deploy its software stack it can only wrap its tokens and send them over a bridge like Axelar.

Solution: White Whale has to deploy its software stack onto Landslide, just like it would to native Cosmos. Here are the steps for that to take place:

  1. IBC Integration: White Whale will first integrate the IBC protocol into its existing CosmWasm software stack on the native Cosmos network. IBC enables communication between heterogeneous blockchain networks, allowing users to securely and efficiently transfer assets and data between IBC-enabled chains. (This is usually completed for most Cosmos chains.)

  2. Landslide SDK and Landslide Core Integration: To facilitate seamless communication between White Whale's CosmWasm stack and Avalanche, White Whale has to integrate the Landslide SDK and Landslide Core into their software stack, just as if they are re-deploying their app stack to a Cosmos chain. These components will serve as a White Whale outpost, its stack operating on a different consensus algorithm.

  3. IBC Connection Establishment: Once the IBC integration and Landslide SDK and Core integration are complete, White Whale will establish a secure IBC connection between the native Cosmos network and Avalanche. This connection will allow for the transfer of assets and data between the two networks, enabling White Whale to operate on both platforms.

  4. CosmWasm Contract Deployment on Avalanche: With the IBC connection established and Landslide SDK and Core in place, White Whale will deploy its CosmWasm contracts on Landslide. These contracts will interact with the Landslide SDK and Core to ensure smooth communication and interoperability between White Whale's services on both Cosmos and Avalanche.

  5. Testing and Auditing: Before launching the White Whale outpost on Avalanche, White Whale will conduct rigorous testing and auditing to ensure the security and reliability of the newly deployed CosmWasm contracts and the Landslide SDK and Core. This process will help identify and address any potential vulnerabilities or issues that may arise during the deployment.

  6. Launch and User Onboarding: Once testing and auditing are complete, White Whale will officially launch its outpost on Avalanche. This will involve marketing campaigns, user education, and support to ensure that our existing and new users can easily navigate and take advantage of the new outpost and its benefits.

Case Study: Osmosis

This diagram shows the process of transferring packets between Osmosis and Landslide using the IBC protocol.

  1. First, Osmosis creates the packet data and sends it to the IBC module.

  2. The IBC module sends the packet to the relayer.

  3. The relayer relays the packet to the destination chain, which in this case is Landslide on the AVAX subnet.

  4. Landslide receives the packet and sends an acknowledgement back to the IBC module.

  5. The IBC module sends the acknowledgement to the relayer.

  6. The relayer relays the acknowledgement back to the source chain, which is Osmosis.

  7. Osmosis receives the acknowledgement from the IBC module.

Last updated

©2023 Gaia Labs LTD