1 of 39

Landslide

An overview of the Landslide Network

Landslide tip: This product is currently being developed! If you report issues, we will note them and include you in our incentivized testnet.

Overview

Landslide brings seamless interchain connectivity between Avalanche and the interchain ecosystem through IBC.

Landslide is a game-changing IBC connection to Avalanche, enabling seamless interoperability between Avalanche, Cosmos, and other IBC-enabled chains. It ushers in a new era of cross-chain DeFi operations, scalability, and streamlined user experience by enabling any CosmWasm-based dapp to run natively on the Avalanche network. Through Landslide, we're fostering a more interconnected, robust blockchain ecosystem, enhancing liquidity, diversifying applications and assets, and attracting a broader user base to web3.

An Inter-Blockchain Communication (IBC) bridge to Avalanche represents a significant development in the blockchain space, offering various benefits.

Firstly, the IBC protocol allows for seamless interoperability between different blockchains. In the context of Avalanche, an IBC bridge means that Avalanche can securely and efficiently interact with Cosmos and any other IBC-enabled chains ( being the most recent), facilitating asset and data transfer between these networks. This opens up a new world of possibilities, such as cross-chain DeFi operations, where a user on one network can utilize financial products on another network, enhancing overall accessibility and utility.

Secondly, this expansion of IBC to Avalanche, a non-Cosmos chain, is a crucial step towards a more interconnected and interoperable blockchain ecosystem. As more non-Cosmos chains adopt IBC, the possibilities for cross-chain interactions expand exponentially. This broadening network effect can lead to higher liquidity, increased diversity of applications and assets, and enhanced robustness of the ecosystem as a whole.

Thirdly, Avalanche has gained a lot of traction due to its high throughput and low fees. By building a bridge to Avalanche, Cosmos-based dApps can leverage these advantages, offering their users a better experience.

Finally, from a user perspective, this means that users can access more diverse dApps and services without needing to manage multiple wallets or navigate different networks. This streamlines the user experience, potentially attracting more users to the blockchain ecosystem.

The Landslide Network is a new Avalanche Subnet that enables any CosmWasm-based dapp to run natively on the Avalanche network. This means that dApps previously restricted to other networks like Osmosis, WYND, and Helix can now be accessed by a new pool of users on Avalanche. This document aims to provide an overview of the Landslide Network, its goals, and features.

Goals

The Landslide Network aims to address some of the challenges existing blockchain networks face, such as slow transaction finality, scalability issues, and limited interoperability. The following are the main goals of the Landslide Network:

Connect natively to IBC: The Landslide Network enables native transfers of all IBC-connected tokens, allowing for seamless asset transfers between the Landslide Network and other IBC-enabled chains.
Decrease transaction finality: The Landslide Network aims to reduce the finality time of transactions on Tendermint from 7-22 seconds to under 1 second, making it one of the fastest networks in the blockchain ecosystem.
Take advantage of trading opportunities: With faster finality times, the Landslide Network can take advantage of trading opportunities that arise in fast-paced environments, making it an attractive platform for high-frequency traders.

Landslide is building a Cosmos IBC enabled subnet for Avalanche. This will allow Native IBC integration within the @avalancheavax ecosystem. What does this mean for?
1. Under 1 second finality for bridged/forked assets into the Landslide L1.
2. Compatibility between assets of any built with Tendermint/ Cosmos SDK assets. ( , , , )
3. Aggregated liquidity
—

Quick links

Get Started

We've put together some helpful guides for you to get setup with our product quickly and easily.

Product Guides

Run Landslide Locally

This guide will walk you through setting up a local Landslide network, deploying CosmWasm contracts, and connecting your wallet to interact with the local network.

How to set up a network locally
- Setting up your development environment
- Starting a local Landslide network
- Preparing your CosmWasm contract
- Uploading and instantiating contracts on Landslide
- Configuring your wallet for local development
- Interacting with your deployed contracts

How to setup Slide SDK locally

Slide SDK (currently known as LandslideVM, changing shortly) is a powerful toolkit for building and deploying CosmWasm applications on the Avalanche network.

Dependencies

1. Go Installation

Download and install Go version go1.22 or later from the
Go Version Compatability Note
IMPORTANT: This project has been tested and confirmed to work with Go 1.22.7. If you encounter build issues, especially related to WebAssembly (WASM) compilation, please ensure you are using a compatible Go version.
Recommended Go Version

2. AvalancheGo Installation

AvalancheGo is the official Go implementation of an Avalanche node. Follow these steps to install it:

a. Clone repository:

This command clones the Slide SDK repository and navigates into the newly created directory.

b. Download and install AvalancheGo:

Run the following command from inside the landslidevm repository to download AvalancheGo:

This command:

Sets up environment variables for the installation paths.
Runs a script that downloads and installs a compatible version of AvalancheGo.
The installed AvalancheGo will be located in /tmp/e2e-test-landslide/avalanchego.

Run a CosmWasm Application

1. Build CosmWasm Plugin

CosmWasm is a smart contracting platform built for the Cosmos ecosystem. We need to build a plugin to enable CosmWasm support in Avalanche.

Run this command from the landslidevm directory:

This script:

Compiles the CosmWasm plugin.
Places the compiled plugin in the AvalancheGo plugins directory.
The long string in the path is a unique identifier for the plugin.

2. Run a Wasm L1

Now we'll set up and run a Wasm L1 (Layer 1) on an Avalanche node using the Landslide Runner.

This clones the Landslide Runner repository and navigates into it.

a. Clone repository:

b. Start the Avalanche node with Landslide L1:

This command:

Builds and configures the Landslide L1.
Starts an Avalanche node with the Landslide L1 deployed.
You should see logs indicating that the node is running and syncing with the network.

Expected Outputs

When you run make run-wasm, you should expect to see output similar to the following:

Network Creation:
- The system will create a network with 5 nodes.
- You'll see log entries for each node being added, with details like node name, directory, and ports.
Health Check:

Key Information to Note:

Subnet ID: e.g., "2c1CbR7FGYdeFPB4WaeWphHZrChLH7TQ92FRW6U4mCWTnaxVsB"
Blockchain-ID: e.g., "WKQC4prgnS66BYgQw8ZBdjgYtPhKaRmDEqB5iXKG55Wj13gHu"
RPC URLs: e.g., "http://127.0.0.1:9750/ext/bc/WKQC4prgnS66BYgQw8ZBdjgYtPhKaRmDEqB5iXKG55Wj13gHu/rpc"
gRPC URLs: e.g., "http://127.0.0.1:9090"

If you see this output, your Landslide network is up and running successfully. You can interact with your network using the provided RPC and gRPC URLs. Remember that you can stop the network by pressing CTRL + C.

Next Steps

Congratulations! You now have a running Avalanche node with Landslide L1 and CosmWasm support. You can start developing and deploying CosmWasm smart contracts on this infrastructure.

To interact with your node or deploy contracts, you'll need to use appropriate tools and APIs. Refer to the Avalanche and CosmWasm documentation for more information on interacting with the network and writing smart contracts.

Troubleshooting

If you encounter issues:

Ensure all dependencies are correctly installed, and versions are compatible.
Check that you have the necessary permissions to execute scripts and create directories.
Review console output for error messages.
Consult our FAQ or community forums for common issues and solutions.

For further assistance, reach out to our support team or community channels.

Conect your wallet to a local network

Cosmostation Wallet

Download and install Cosmostation Wallet as a browser extension

Create Wallet:
Save mnemonic phrase afterward
Verify your seed phrase
Reconnect to Cosmostation extension and enter a password
Navigate to "Add Custom Chain" > "Add a custom Cosmos chain". Once the chain is added, return to the wallet and select the new chain:

How to deploy a CosmWasm contract

After setting up your Landslide local network, follow these steps to deploy and interact with smart contracts.

Important Note on Terminal Usage

Before proceeding, it's crucial to understand the correct setup:

Keep your original terminal window running the Landslide network (make run-wasm command) open and active. This terminal maintains your local network.
Open a new terminal window to execute the following commands. This separation allows you to interact with the network without interrupting its operation.

This two-terminal approach provides several benefits:

Keeps the network running uninterrupted
Allows easy reference to network logs while executing commands
Prevents accidental network stoppage
Facilitates easier troubleshooting

Now, in your new terminal window, proceed with the following steps:

1. Build and Install Wasmd

is the CLI tool for interacting with CosmWasm contracts.

a. Clone the Wasmd repository:

b. Checkout the most stable version (replace v0.53.0 if needed):

c. Install Wasmd:

d. Verify the installation:

2. Import Private Key

When running a local testnet, as opposed to connecting to a live testnet or mainnet, you need to use a pre-configured account that has been allocated tokens in the genesis state. This differs from a live network, where you would typically create a new account and obtain tokens through a faucet or a transfer.

In a local testnet environment:

The network is initialized with a set of pre-defined accounts.
These accounts are already funded with tokens in the genesis block.
One of these accounts is designated for testing and development purposes.

To interact with the network, you'll need to import this specific testnet private key:

When prompted, enter the following bip39 mnemonic (seed phrase):

This mnemonic corresponds to a pre-funded account in your local testnet. By importing this key, you're gaining access to an account that already has tokens, allowing you to perform transactions, deploy contracts, and interact with the network without acquiring tokens first.

Important Notes:

This specific key should only be used for local testing purposes.
Never use this key on a public testnet or mainnet, as the private key is publicly known.
In a production environment, you would generate your own secure keys and properly manage them.

Understanding this process helps clarify the difference between working with a local testnet and interacting with a live network, where account creation and token acquisition would be handled differently.

3. Deploy Smart Contract

Now, you're ready to deploy a smart contract to your Landslide network.

a. Upload an example contract (in this case, hackatom.wasm):

Important:

Replace [REPLACE_WITH_YOUR_RPC_URL] with the RPC URL provided in your Landslide network output. This is visible in the first terminal where you started your Landslide node. It should look something like http://127.0.0.1:9750/ext/bc/....
At this point, you'll be prompted to confirm the transaction. Review the details carefully and enter 'y' to confirm and proceed with signing and broadcasting, or 'N' to cancel the transaction.

After executing the command to upload the smart contract, you should see an output similar to this:

Great! Your smart contract has been successfully uploaded to the Landslide network. Here's what you need to know:

The code: 0 indicates that the transaction was successful.
The most important piece of information is the txhash. Yours will look different, but in this case, it's: F15A7FB824FA83D58E556224FE2D5BD59A4FC7FB8E50400D5B0649E78D873D53

Next Steps: You'll need this transaction hash for the next step, which is to fetch the code_id of your uploaded contract. The code_id is crucial for future interactions with your contract.

Proceed to the next step in the documentation, where you'll query this transaction to get the code_id. Make sure to replace the placeholder transaction hash with the one you received in your output.

If you encountered any errors or didn't receive a similar output, double-check that you've correctly replaced the RPC URL in the command and that your Landslide network is running properly.

b. Fetch the code ID using the transaction hash from the previous output:

After executing the command to query the transaction, you should see an output similar to this:

Here's what to look for in this output:

Check that the code field is 0, which indicates the transaction was successful.
Look for the events array in the output. Find the event with "type": "store_code".
Within the store_code event, there are attributes. Find the attribute with

This code_id is crucial for future interactions with your contract, such as instantiation or execution. Make note of it for use in subsequent steps.

6. Query Code ID Metadata

After uploading your smart contract, you can retrieve its metadata using the code ID. Run the following command:

Replace <CODE_ID> with the code ID you obtained in the previous step, and [REPLACE_WITH_YOUR_RPC_URL] with your Landslide network's RPC URL.

Example output:

This output provides important information about your uploaded smart contract:

code_id: Confirms the ID of your uploaded contract.
creator: The address that uploaded the contract.
data_hash: A unique hash of the contract's bytecode.

This information is useful for verifying the contract's details and understanding its deployment permissions. The data_hash can be used to ensure the integrity of the uploaded contract.

Next Steps

With your contract deployed, you can now interact with it using Wasmd commands. Consider exploring:

Instantiating your contract
Querying contract state
Executing contract functions

Remember to always use the correct node URL and chain ID in your commands, as provided by your Landslide network setup (visible in the first terminal).

Troubleshooting

If commands fail, double-check your node URL and chain ID from the first terminal.
Ensure your private key has sufficient funds for gas fees.
Verify that your Landslide network is still running and healthy in the first terminal.

For more advanced usage or specific contract interactions, refer to the CosmWasm documentation and your contract's specific interface.

Run Landslide local network following

Run Landslide on Testnet

How to Run Landslide on a Testnet

How to connect Cosmostation

Cosmostation Wallet

Download and install Cosmostation Wallet as a browser extension

Create Wallet:
Save the mnemonic phrase afterward. To store this password, we recommend using , as they're the most secure password management solution.
Verify your seed phrase
Reconnect to Cosmostation extension and enter a password
Navigate to "Add Custom Chain" > "Add a custom Cosmos chain."
Once the chain is added, return to the wallet and select the new chain:

License

License terms

Slide SDK is launched under a

The license limits use of the v0.1 source code in a commercial or production setting until April 1st, 2027. After this, the license will convert to a general public license. This means anyone can fork the code for their own use — as long as it is kept open source.

The Gaia Labs Labs team will create documents that outline the forking process here.

Security Audit

Description of the Oak Security audit for Slide SDK

Slide SDK was audited by Oak Security, you can read the audit here.

Landslide EVM

A Primer on Landslide as it relates to Ethereum dApps.

Bridging Ethereum apps to Avalanche

This flowchart illustrates the interoperability of applications running on different blockchain networks - Cosmos, Polkadot, and Ethereum - through the use of Landslide technology on the Avalanche network.

Starting from the left, we have three subgraphs representing the Cosmos, Polkadot, and Ethereum networks. Each network runs a specific application: Osmosis on Cosmos, DOT on Polkadot, and Synthetix on Ethereum.

These applications interact with their respective IBC light clients. For Cosmos, it's the Landslide SDK IBC light client; for Polkadot, it's the ; and for Ethereum, it's the Landslide EVM IBC light client. These light clients are responsible for maintaining a connection and facilitating communication between the networks.

All three light clients then connect to the IBC bridge, which serves as the main hub for transferring state between the source and target chains. The IBC bridge then connects to three more IBC light clients, which are responsible for transferring the source chain's state to the Avalanche network.

Finally, the state is transferred to the Avalanche network, where it's run natively inside an Avalanche subnet. This is represented by three subgraphs under Avalanche: Landslide running Synthetix, Landslide2 running OSMO, and Landslide3 running DOT. The transition between these subgraphs is facilitated by Avalanche Warp Messaging, indicating the flow of transactions within the Avalanche network.

Relayer Operator Guide

Relayer

In IBC, blockchains do not directly pass messages to each other over the network. This is where `relayer` comes in. A relayer process monitors for updates on opens paths between sets of IBC enabled chains. The relayer submits these updates in the form of specific message types to the counterparty chain. Clients are then used to track and verify the consensus state. In addition to relaying packets, this relayer can open paths across chains, thus creating clients, connections and channels. Additional information on how IBC works can be found .

Basic Usage - Relaying Packets Across Chains

The -h (help) flag tailing any rly command will be your best friend. USE THIS IN YOUR RELAYING JOURNEY.

Clone, checkout and install the latest release (). needs to be installed and a proper Go environment needs to be configured
Initialize the relayer's configuration directory/file.
Default config file location: ~/.relayer/config/config.yaml By default, transactions will be relayed with a memo of rly(VERSION) e.g. rly(v2.5.2). To customize the memo for all relaying, use the --memo flag when initializing the configuration.

Chain integrators guide

Lower than version 0.50
Higher than version 0.50

Lower than v0.50

Integrating the Avalanche Light-Client Module in Your Cosmos SDK Application

Enhance your Cosmos SDK application by integrating the light-clients/14-avalanche module. Follow this step-by-step guide to easily import and register the Avalanche light-client in your project.

1. Import the Avalanche Light-Client Module

First, ensure you import the Avalanche (ava) module into your Cosmos SDK application. Typically, this is done in the app.go file, where your application's modules are defined.

2. Register the Avalanche Module in the Module Manager

Next, add the ava module to your application’s ModuleManager. Locate the section where you initialize the ModuleManager and include the Avalanche light-client:

By following these steps, you'll successfully integrate the Avalanche light-client module into your Cosmos SDK application, enabling enhanced interoperability with Avalanche-based chains.

Higher than v0.50

Integrating the Avalanche Light-Client Module in Your Cosmos SDK Application

Enhance your Cosmos SDK application by integrating the light-clients/14-avalanche module. Follow this step-by-step guide to easily import and register the Avalanche light-client in your project.

1. Import the Avalanche Light-Client Module

First, ensure you import the Avalanche (ava) module into your Cosmos SDK application. Typically, this is done in the ibc.go file, where your application's modules are defined.

2. Register the Avalanche Module in the Module Manager

Next, add the ava module to your application’s ModuleManager. Locate the section where you initialize the ModuleManager and include the Avalanche light-client:

3. Add module to the RegisterIBC function

Finally, register the Avalanche module in the RegisterIBC function of your application. This function is typically found in the ibc.go file.

By following these steps, you'll successfully integrate the Avalanche light-client module into your Cosmos SDK application, enabling enhanced interoperability with Avalanche-based chains.

IBC Connection

Overview

For a detailed overview, please refer to the

The below diagram depicts the interaction between two Cosmos SDK-based chains, Osmosis and Landslide, through the IBC protocol. The IBC Relayer acts as a mediator between the two chains.

When a message transfer is initiated by Chain A (Osmosis), it generates a packet commitment (hash) and stores it in the KV store by key (port, channel, sequence). Then it emits a packet event and the IBC Relayer handles this event. The IBC Relayer queries for the packet commitment proof from Chain A (Osmosis), which is then returned by Chain A (Osmosis). The IBC Relayer creates a message to relay the packet to Chain B (Landslide).

After receiving the message, Chain B (Landslide) sends back a WriteAck result to the IBC Relayer. The IBC Relayer then queries for the acknowledgement proof from Chain B (Landslide), which is then returned by Chain B (Landslide). The IBC Relayer creates an acknowledgement message containing the packet, acknowledgement, and proofs, which is then sent to Chain A (Osmosis).

IBC Go

How IBC-go interacts with the Avalanche IBC light client

See original

The IBC-go library is a Go implementation of the IBC protocol and provides a set of interfaces and functions to handle the different components of the IBC protocol. To interact with the IBC light client for Avalanche, you can use the IBC-go library to implement the necessary functionality to receive and send packets over the IBC protocol.

Here are the general steps for using IBC-go to interact with the IBC light client for Avalanche:

Install and configure the IBC-go library. You can follow the installation instructions provided in the Github repository to set up the library and configure it for your specific use case.

IBC Relayer AVAX L1 Proof

How IBC gets the state proof from AVAX mainnet

The sequence diagram describes an Inter-Blockchain Communication (IBC) relayer retrieving Avalanche L1 proof.

The process involves multiple participants: the relayer, L1 Node 1 through Node N, and L1 Validator 1 through Validator N.

The relayer first queries proof by key from L1 Node 1. Node 1 attempts to get the payload by key, and if the signature is already in its internal cache, it retrieves it. If the signature is not cached, it makes a call through the Virtual Machine (VM) context to Validator 1 to sign the payload. After Validator 1 returns the signature, Node 1 forwards it back to the relayer.

A similar process occurs with L1 Node 2 and its corresponding Validator. However, in this case, it's noted that the signature is not cached and needs to be signed by the Validator through the VM context.

The process repeats for all remaining nodes (represented as Node N) and their corresponding Validators (Validator N).

After collecting all signatures from the different L1 Nodes, the relayer then composes these signatures from Node 1, up to Node N.

API endpoints

🔌 Landslide Network Testnet Endpoints

The following endpoints are available for connecting to the Landslide Network testnet:

RPC Endpoint

The RPC (Remote Procedure Call) endpoint allows for direct interaction with the blockchain through JSON-RPC calls. Use this for submitting transactions, querying chain state, and other blockchain interactions.

Avalanche Warp Messaging

Overview

Landslide Core comes with built-in support for Avalanche Warp Messaging (AWM). 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. You can find more information about AWM and how it functions on this page.

Integrations

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.

Overview

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.

Case Study: Osmosis

Explaining the Osmosis integration

Cosmoswap

Here is a quick overview of how works on the Osmosis decentralized exchange:

Cosmoswap leverages Osmosis's pooled liquidity infrastructure to enable customizable "outposts" - IBC-connected DEX deployments on other chains.

For example, Landslide functions as a Cosmoswap outpost on Avalanche. Landslide, built with the Cosmos SDK, handles the Avalanche-side transactions and liquidity routing.

Osmosis manages the core liquidity pools and validation logic. Landslide contains router contracts directing trades to Osmosis over IBC.

ABCI Calls

The ABCI (Application Blockchain Interface) calls in the Landslide Core repository provide the interface for Cosmos-based dApps to interact with the Avalanche network. Developers can plug their existing Cosmos dApps into the Landslide Core by implementing the necessary ABCI calls. The repository includes example ABCI applications such as the KVStoreApplication and the PersistentKVStoreApplication, which can be used as placeholders for Cosmos SDK-based applications.

FAQ

Roadmap

A regularly updated roadmap.

Completed

Current Sprint

Overview

What is CometBFT?

Some background on Tendermint

CometBFT Explained

CometBFT consensus is a Byzantine fault-tolerant consensus algorithm used in distributed systems, particularly in blockchain networks. It is used in various blockchain projects, including Cosmos, Binance Chain, and Injective.

In CometBFT consensus, formerly called Tendermint, nodes in the network reach an agreement on the order and content of transactions in the blockchain. The consensus algorithm ensures that all nodes agree on the current state of the blockchain, and that new transactions are added in a consistent and secure manner.

CometBFT consensus works by using a round-based voting process. Each round has a leader node that proposes a block of transactions to the network. The other nodes in the network then vote on whether to accept the proposed block. If enough nodes vote to accept the block, it is added to the blockchain.

What is Avalanche Consensus?

Some background on Snow and Avalanche Consensus. Watch this video for a full explanation.

Avalanche Consensus

Watch this video for a full explanation with animations.

Landslide replaced Tendermint consensus with Avalanche consensus and runs on an Avalanche subnet. Landslide enables users to:

run the Tendermint ABCI on an Avalanche subnet
run any Cosmos-based dApp on an Avalanche subnet
send assets and message across IBC to/from Avalanche to any other IBC-enabled blockchain

Overview

Avalanche consensus is a novel consensus algorithm designed for distributed ledger technology that aims to achieve high throughput, low latency, and high scalability. It is unique in that it uses a new consensus paradigm called the Avalanche family of protocols, which rely on a new approach to network sampling, voting, and confirmation.

In Avalanche consensus, nodes can propose transactions and vote on them. Unlike traditional consensus algorithms like Proof of Work or Proof of Stake, in which nodes vote on a single block, in Avalanche consensus, nodes vote on multiple transactions at the same time. This allows Avalanche to achieve high throughput, as it can process multiple transactions in parallel.

The Avalanche family of protocols is also designed to handle network partitions gracefully. In traditional consensus algorithms, a network partition can cause forks in the blockchain, which can be difficult to resolve. In Avalanche, network partitions are resolved automatically by having nodes vote on transactions independently in each partition. When the network partitions are resolved, the protocol ensures that only one transaction is accepted for each transaction ID.

Avalanche consensus is also able to achieve low latency, as transactions can be confirmed within seconds of being proposed. This is achieved through a process called sub-sampling, in which nodes sample only a small portion of the network to determine whether a transaction is valid. If a transaction is deemed valid by this small group of nodes, it is then broadcast to the rest of the network for confirmation. This allows for fast confirmation times while still maintaining the security of the system.

Sub sampling

In Avalanche consensus, the network subsampling algorithm is designed to be meta-stable, which means that it is able to maintain consensus even in the presence of temporary failures or inconsistencies in the network. This is important because it allows the protocol to continue to operate correctly even if a small subset of nodes fail or behave maliciously.

The network subsampling algorithm in Avalanche works by randomly selecting a subset of nodes from the network to participate in a transaction vote. Each selected node then votes on the transaction, and if enough nodes vote in favor of the transaction, it is considered confirmed and added to the blockchain.

In order for the network subsampling algorithm to be meta-stable, it is designed to be resilient to a variety of network failures and inconsistencies. For example, if a node fails to respond to a vote request, the algorithm is designed to select a replacement node to vote in its place. Similarly, if there are inconsistencies in the votes received from the selected nodes, the algorithm is designed to use a fallback mechanism to resolve the inconsistency and ensure consensus.

The meta-stability of the network subsampling algorithm is important because it ensures that the consensus protocol can continue to operate correctly even in the face of temporary network failures or inconsistencies. This makes Avalanche consensus more robust and reliable than traditional consensus algorithms, which may be vulnerable to these types of failures.

Overall, the meta-stability of the network subsampling algorithm is a key feature of Avalanche consensus that helps to ensure the security and reliability of the protocol.

Faster Finality

Time to finality is faster on Avalanche consensus compared to Tendermint consensus due to the probabilistic nature of the Avalanche consensus algorithm. In probabilistic consensus, transactions are not required to be confirmed by every node in the network, but rather by a statistically significant subset of nodes. This allows transactions to be confirmed more quickly, as they do not have to wait for every node in the network to confirm them.

In contrast, Tendermint consensus is a deterministic consensus algorithm in which every node in the network must confirm each transaction before it can be added to the blockchain. This can lead to longer confirmation times, as the confirmation process can be bottlenecked by slow or faulty nodes.

The probabilistic nature of Avalanche consensus allows it to achieve faster time to finality by using a process called sub-sampling. In this process, a small subset of nodes is selected to confirm each transaction, and if the transaction is confirmed by this subset, it is then broadcast to the rest of the network for confirmation. This allows transactions to be confirmed much more quickly than in deterministic consensus algorithms like Tendermint.

Additionally, the sub-sampling process in Avalanche consensus is designed to be meta-stable, which means that it is able to maintain consensus even in the presence of temporary failures or inconsistencies in the network. This further improves the speed and efficiency of the confirmation process.

Overall, the probabilistic nature of Avalanche consensus, combined with its sub-sampling process and meta-stability, allows it to achieve faster time to finality than deterministic consensus algorithms like Tendermint.

Video overview

Got 2 minutes? Check out a video overview of Dr. Emin Gün Sirer explaining Avalanche consensus:

Features

Landslide Network features

Features

The Landslide Network offers several features that make it an attractive platform for developers and users alike. These include:

High throughput and scalability: The Landslide Network is designed to handle high throughput and scalability, making it ideal for developing games, AMMs, and other dapps that require fast finality times.
Native support for IBC: The Landslide Network natively supports IBC, enabling seamless transfer of assets between the Landslide Network and other IBC-enabled chains.
Interoperability with Cosmos-based SDK: The Landslide Network is 100% compatible with the native Cosmos-based SDK, making it easy for developers to port their existing dApps to the Landslide Network.
Airdrop tokens to Avalanche and Cosmos users: The Landslide Network will conduct an airdrop of tokens to users on Avalanche and Cosmos, providing an incentive for users to join the Landslide Network and participate in its ecosystem.

Fundamentals

Getting set up

How to set up Landslide Core

Installation

Ensure that you have Go installed on your computer. You can download and install the latest version of Go from the official website at .

Roadmap

Interchain Staking

How Landslide accepts ATOM in addition to AVAX for validators.

*Please Note: this is a working document and is intended to change over time.

Background

Original Source where Sunny from Osmosis and Emin Gün Sirer from Ava Labs discuss this proposal.

1. Integration of Cross-Chain Validation (CCV) from Cosmos through IBC:

This will involve understanding the CCV protocol in depth and implementing it within the Landslide Network. This will allow the network to borrow security from more established chains, thus increasing the cost of attacking the network.

Here is a detailed for the Cross-Chain Validation (CCV) protocol in the Cosmos Inter-Blockchain Communication (IBC) ecosystem. Here's a summary of the key concepts and operations:

Security Model:

The CCV protocol is designed for chains that use a proof of stake mechanism. It relies on validators who bond (lock, stake) tokens to validate blocks. The amount of tokens bonded determines a validator's voting power. Misbehaving validators can be punished by slashing their bonded tokens. The security of consumer chains is based on the tokens validators bonded on the provider chain.

Motivation:

CCV is a building block that enables shared security models. It allows chains to borrow security from more established chains, thus increasing the cost of attacking their networks. It also enables hub minimalism, keeping a hub in the Cosmos network as simple as possible to decrease the attack surface.

Definition:

The document introduces new terms such as Provider Chain (the blockchain that provides security), Consumer Chain (the blockchain that consumes security), and Validator Set Change (VSC - a change in the validator set of the provider chain that must be reflected in the validator sets of the consumer chains).

Channel Initialization:

The CCV protocol differentiates between chains that start directly as consumer chains and existing chains that transition to consumer chains. In both cases, consumer chains are created through governance proposals.

Validator Set Update:

This operation updates the validator sets of all the consumer chains based on the information obtained from the provider chain. It also enables the timely completion of unbonding operations.

Consumer Initiated Slashing:

(this will not be implemented on AVAX)

This operation enables the provider chain to slash and jail bonded validators that misbehave while validating on the consumer chain.

Reward Distribution:

This operation enables the distribution of block production rewards and transaction fees from the consumer chains to the validators on the provider chain.

2. Customization of Avalanche Subnets:

Currently, the subnets are a subset of the current p-chain validator list. This can be changed as long as the new validators are renting the required minimum AVAX amount from other providers in the network. The customization of subnets will allow for greater flexibility and control over the network's operations.

3. Collaboration with GoGoPool:

is reducing the 2000 AVAX requirement via a liquidity bootstrapping method, essentially AVAX lending plus staking 100 AVAX worth of GoGoPool tokens (GGP). Collaborating with GoGoPool can provide a way to lower the barrier to entry for new validators, thus increasing the security and decentralization of the network.

4. Integration of Interchain Security on Cosmos:

This will look a lot like interchain security on Cosmos. This will involve implementing the security model of Cosmos within the Landslide Network, allowing for shared security models and increased network security.

5. Creation of a Subnet that Uses ATOM in Addition to Staking AVAX:

This will involve creating a subnet that is also a zone that uses ATOM in addition to staking AVAX. This will allow for the integration of IBC and Warp together, providing greater flexibility and control over the network's operations.

This roadmap is ambitious and requires a deep understanding of blockchain technology, particularly the Cosmos IBC and Avalanche's infrastructure. However, it is a feasible plan that could greatly enhance the security and functionality of the Landslide Network.

FAQ

A learning resource 📕

How are the validator sets authenticated?

The validator sets in Avalanche are authenticated using a threshold of signatures from a randomly chosen subset of validators. A block is verified when two-thirds of these selected validators have signed it. To obtain a specific validator set and its associated proof for the C-Chain, the information stored in the block header, you can use the API provided in the official AVAX docs. The IBC integration between the Avalanche network and a different chain, like Cosmos, uses a Landslide VM that tracks validator set changes from the Avalanche P-chain.

The VM is responsible for processing the incoming validator set changes from the Avalanche P-chain and updating the validator set of the connected subnet accordingly. This would enable the subnet to stay synchronized with the latest validator set of the Avalanche network and ensure secure and consistent transactions.

Additionally, we include a client certificate or acceptance proof, such as a BLS signature, for the parent block in the child block. This ensures that the child block is only accepted if the parent block is accepted, creating a trust chain that maintains the transaction history's integrity.

The overall idea is that chains use a VM on Landslide (CosmWasm, EVM, XCM) to connect the Avalanche network and a different chain, track the validator set changes, and ensure secure and consistent transactions between the two chains.

How is a Cosmos dApp more decentralized on Avax than it is on native Cosmos?

Check the docs. 🤯

See the original Cosmos whitepaper . "Unlike Bitcoin or other proof-of-work blockchains, a Tendermint blockchain gets slower with more validators due to the increased communication complexity. Fortunately, we can support enough validators to make for a robust globally distributed blockchain with very fast transaction confirmation times, and, as bandwidth, storage, and parallel compute capacity increases, we will be able to support more validators in the future.

On genesis day, the maximum number of validators will be set to 100, and this number will increase at a rate of 13% for 10 years, and settle at 300 validators."

See the Avalanche whitepaper .

"A core feature of the Snow family is its ability to scale without incurring fundamental tradeoffs. Snow protocols can scale to tens of thousands or millions of nodes, without delegation to subsets of validators. These protocols enjoy the best-in-class system decentralization, allowing every node to fully validate. First-hand continuous participation has deep implications for the security of the system. In almost every proof-of-stake protocol that attempts to scale to a large participant set, the typical mode of operation is to enable scaling by delegating validation to a subcommittee. Naturally, this implies that the security of the system is now precisely as high as the corruption cost of the subcommittee. Subcommittees are furthermore subject to cartel formation."

How is it possible to migrate liquidity from a Cosmos dApp to Avalanche?

Check out this guide which explains how Cosmos dApps deploy Landslide outposts to Avalanche. Each Cosmos dApp has to effectively deploy its entire software stack to the Avalanhe network via a subnet. Avalanche X and C chains do not allow for custom VMs; they can only be connected via subnet communication.

A connection to a Cosmos dApp is only secured by IBC light client verification.

If a Cosmos dApp is deployed to Landslide Network, does it have a more decentralized validator set?

YES. 🤯

There can be more decentralization of validators on Avalanche, as there is no hard cap on the number of validators as there is with Tendermint. , which can scale infinitely, and all of these validators can validate on the Landslide subnet. This means that an existing Cosmos zone can have an unlimited number of validators on the Landslide subnet, which can increase the decentralization of the network. The Avalanche consensus protocol is probabilistic, as described in the , operates differently from other consensus mechanisms like those used in Ethereum (Nakamoto) or Cosmos (Tendermint). Here are some key points that help answer your questions:

1.) Uncapped Validator Set: Avalanche consensus operates through repeated sub-sampled voting. When a node is determining whether a transaction should be accepted, it asks a small, random subset of validator nodes for their preference. This process is repeated until the validators queried reply with the same answer for a sufficient number of consecutive rounds. This approach allows the validator set in Avalanche to expand infinitely, as the consensus process does not require communication with all validators, only a small, randomly chosen subset.

Do all Rust contracts of a Cosmos dApp need to be redeployed onto the Landslide subnet in order to benefit from decreased time to finality and transactions per second?

Yes, in order to take advantage of the higher transactions per second and faster finality provided by the Landslide network, the existing Rust contracts of a Cosmos dApp would need to be redeployed onto the Landslide subnet using the Landslide SDK.

The is 100% compatible with the Cosmos SDK, with a few minor changes made to support Avalanche consensus and remove the Tendermint consensus and slashing modules. Therefore, the process of deploying contracts onto the Landslide network should be relatively straightforward for dApps that are already built using the Cosmos SDK.

What happens if an Avalanche validator signs two different blocks at the same height?

Currently, nothing happens. In Avalanche, block signing only occurs during the block proposal process, not during the validation process. Therefore, double-signing is not treated as an attack.

Don't validators still have to sign a vote for the block during the consensus process?

No, validators do not sign a vote for the block during the consensus process in Avalanche.

Do you need an oracle to access the P-chain in avalanche?

No. It is possible to access the P-chain in Avalanche via IBC without the need for an oracle. IBC is a protocol that enables interchain communication between different blockchains, and it does not require oracles to function.

Additionally - you don't need IBC either. You can directly get the state you need by querying the P-chain.

How do I access Avalanche Warp Messaging (AWM)?

You can only access AVAX via the P-chain if and only if you have an IBC light client on AVAX and on the source chain side. This requires the corresponding VMs to run natively on both chains. is funding open source IBC light client work on all chains, not just AVAX.

How do you get from the current Landslide Core to a working system and the properties of the system?

To get from the current Landslide Core to a working system, developers need to implement the necessary ABCI calls in their application, including InitChain, BeginBlock, DeliverTx, CheckTx, and EndBlock ABCI calls. Once implemented, the dApp can be compiled using the LandslideSDK and deployed to the Avalanche network.

LandslideCore is an implementation of the Tendermint Core that has been extended to include support for the Avalanche network. It provides the core functionality for creating and managing blockchain applications on the Avalanche network.

Doesn't Cosmos already have very fast finality?

It depends on the chain. Take Injective for example, is the block explorer. Notice that while there are blocks that are 1 second apart, their validator set is 60. is 21 times larger at 1264.

The speed of finality in Cosmos chains can vary depending on the chain's configuration and the number of validators in its network. Some Cosmos chains may achieve fast finality times of a few seconds, while others may have longer finality times. However, Avalanche's consensus mechanism is designed to achieve sub-second finality times even with a large number of validators. This is achieved through its use of probabilistic consensus and its network subsampling algorithm, which allows for a high degree of scalability without compromising security.

Where is the Avalanche consensus implemented?

The consensus algorithm implemented in the reactor.go file of the LandslideCore repository is the Avalanche consensus algorithm. This implementation includes the following key components:

Sampling: A network subsampling algorithm is used to gather opinions from a random subset of the validator set.

Do you need to have consensus certificates?

How does Tendermint increase latency as you scale the validator set?

Tendermint consensus protocol requires validators to communicate with each other to come to an agreement on the next block. As the number of validators increases, the number of communication channels also increases, which can lead to increased network latency. This can result in a longer time for blocks to be propagated and finality to be achieved. In other words, as the validator set grows, the network may experience delays in block creation and confirmation. This is a known issue with Tendermint consensus, and is why other consensus protocols, like Avalanche, have been developed to address this scalability challenge.

How does Avalanche ensure token fungibility across subnets?

Token fungibility is VM specific, but the current recommendation is to treat tokens on different subnets as not fungible, just like in Cosmos. The Cosmos team is implementing path unwinding to improve token fungibility, as discussed .

The first standard for token fungibility on Avalanche is likely to be based on the messaging format introduced into Subnet EVM, which is agnostic to token logic, and the Teleporter contract format that specifies fungibility. Ava Labs is currently working on this internally, and there are no official developer documents available yet.

If a token is minted on Subnet A and sent to Subnet B, and then wants to be sent to Subnet C, it will generally be forwarded through Subnet A.

How does the IBC light client send packet data?

Please refer to the official , and check out a detailed diagram of the AVAX IBC light client .

Packet data in IBC refers to the messages that are sent between two independent chains over the IBC protocol. The packet data contains information on the transaction or asset transfer, such as the sender, recipient, amount, and any additional metadata.

To build an IBC light client for AVAX, you would need to create a light client that can verify and validate packet data from other chains. The light client must be able to confirm that the packet data received is valid and that it has not been tampered with during transmission.

In the context of the IBC protocol, a light client is a simplified version of a full node that can verify the headers of blocks from another chain. Light clients can use a cryptographic proof to verify that the block headers are valid without having to download and store the entire blockchain.

What is the method for obtaining a specific validator set and its associated proof for the C-Chain, especially when this information is stored in the block header?"

Use this API to get the validator set:

How does the Avalanche light client handle the selection and updating of its validator set in comparison to Ethereum's Altair light client, which updates its 512-member validator set every 256 epochs?

In Avalanche, a partial validator set is randomly chosen from the entire pool of available validators to sign blocks. The Avalanche Light Client operates by setting a certain threshold—often a two-thirds majority—of these selected validators whose signatures are required to verify a block. Unlike Ethereum's Altair light client, which updates its validator set every 256 epochs (approximately every 27 hours), the Avalanche Light Client follows its own unique schedule and methodology for updating and validating its validator set.

How does the Landslide token accrue value?

The only security assumption that IBC has is that the target and the source chain are valid. Unlike major bridges like LayerZero, ChainLink, or Wormhole, there are no assumptions that the bridge is valid, because there are no externally verified bridge validators on IBC; there are only relayers relaying packets between chains. Landslide tokens create value by (1) securing a subnet, and (2) processing volume to/from Avalanche over IBC.

What's the user experience like? Do you need to hold Landslide tokens in order to swap assets?

Landslide tokens are abstracted away from the users via Burnt’s . The aim is to optimize the tokens so that users do not need to hold SLIDE tokens to swap between Cosmos/AVAX assets; the token is abstracted away from the user..

RPC

This file defines the JSON-RPC spec of CometBFT vs Landslide SDK. This is meant to be implemented by all clients.

Routes

✅

minHeight (integer): The lowest block to be returned in the response
maxHeight (integer): The highest block to be returned in the response

Request

JSONRPC

Response

Block

Get block at a specified height.

Parameters

height (integer): height of the requested block. If no height is specified the latest block will be used.

Request

JSONRPC

Response

BlockByHash

Parameters

hash (string): Hash of the block to query for.

Request

JSONRPC

Response

BlockResults

Parameters

height (integer): Height of the block which contains the results. If no height is specified, the latest block height will be used

Request

JSONRPC

Response

Commit

Parameters

height (integer): Height of the block the requested commit pertains to. If no height is set the latest commit will be returned.

Request

JSONRPC

Response

Validators

Parameters

height (integer): Block height at which the validators were present on. If no height is set the latest commit will be returned.
page (integer):
per_page (integer):

Request

JSONRPC

Response

hash (string): The hash of the transaction
prove (bool): If the response should include proof the transaction was included in a block.

Request

JSONRPC

Response

TxSearch

Searches for transactions based on a query condition. Returns matching transactions along with their details.

Parameters

query (string): The query condition for searching transactions (e.g., "tx.height=1").
prove (boolean): Indicates whether to include proof data for each transaction.
page (string): The page number for paginated results.

Request

JSONRPC

Response

BlockSearch

Searches for blocks based on a query condition. Returns matching blocks along with their details.

Parameters

query (string): The query condition for searching blocks (e.g., "block.height > 1").
page (string): The page number for paginated results.
per_page (string): The number of blocks to show per page.

Request

JSONRPC

Response

Transaction Routes

BroadCastTxSync

Returns with the response from CheckTx. Does not wait for DeliverTx result.

Parameters

tx (string): The transaction encoded

Request

JSONRPC

Response

BroadCastTxAsync

Returns right away, with no response. Does not wait for CheckTx nor DeliverTx results.

Parameters

tx (string): The transaction encoded

Request

JSONRPC

Response

CheckTx

Checks the transaction without executing it.

Parameters

tx (string): String of the encoded transaction

Request

JSONRPC

Response

ABCI Routes

ABCIInfo

Get some info about the application.

Parameters

None

Request

JSONRPC

Response

ABCIQuery

Query the application for some information.

Parameters

path (string): A request path for the application to interpret analogously to a in e.g. routing.
data (string): Request parameters for the application to interpret analogously to a , expressed as hexadecimal-serialized bytes (convert WasmApp to hex is 5761736d417070).
height (integer)

Request

JSONRPC

Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "chunk": "0",
    "total": "1",
    "data": "ewogICJhcHBfbmFtZSI6ICJ3YXNtZCIsCiAgImFwcF92ZXJzaW9uIjogIjAuNTAuMCIsCiAgImdlbmVzaXNfdGltZSI6ICIyMDI0LTA2LTExVDE5OjQ3OjAyLjU4ODE0MDY2NFoiLAogICJjaGFpbl9pZCI6ICJsYW5kc2xpZGUtdGVzdCIsCiAgImluaXRpYWxfaGVpZ2h0IjogIjAiLAogICJhcHBfaGFzaCI6IG51bGwsCiAgImFwcF9zdGF0ZSI6IHsKICAgICIwNy10ZW5kZXJtaW50IjogbnVsbCwKICAgICJhdXRoIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJtYXhfbWVtb19jaGFyYWN0ZXJzIjogIjI1NiIsCiAgICAgICAgInR4X3NpZ19saW1pdCI6ICI3IiwKICAgICAgICAidHhfc2l6ZV9jb3N0X3Blcl9ieXRlIjogIjEwIiwKICAgICAgICAic2lnX3ZlcmlmeV9jb3N0X2VkMjU1MTkiOiAiNTkwIiwKICAgICAgICAic2lnX3ZlcmlmeV9jb3N0X3NlY3AyNTZrMSI6ICIxMDAwIgogICAgICB9LAogICAgICAiYWNjb3VudHMiOiBbCiAgICAgICAgewogICAgICAgICAgIkB0eXBlIjogIi9jb3Ntb3MuYXV0aC52MWJldGExLkJhc2VBY2NvdW50IiwKICAgICAgICAgICJhZGRyZXNzIjogIndhc20xdmN3MGhlNWw5bXU1NHphd2czaDQ0MHA4M2V4NzBjY21tZTUzYWMiLAogICAgICAgICAgInB1Yl9rZXkiOiBudWxsLAogICAgICAgICAgImFjY291bnRfbnVtYmVyIjogIjAiLAogICAgICAgICAgInNlcXVlbmNlIjogIjAiCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5hdXRoLnYxYmV0YTEuQmFzZUFjY291bnQiLAogICAgICAgICAgImFkZHJlc3MiOiAid2FzbTFrbmc2c3FrbTBtanVoMDljd3o2dTg2Zjc1bG1lZmxqOWgwZnFociIsCiAgICAgICAgICAicHViX2tleSI6IG51bGwsCiAgICAgICAgICAiYWNjb3VudF9udW1iZXIiOiAiMSIsCiAgICAgICAgICAic2VxdWVuY2UiOiAiMCIKICAgICAgICB9LAogICAgICAgIHsKICAgICAgICAgICJAdHlwZSI6ICIvY29zbW9zLmF1dGgudjFiZXRhMS5CYXNlQWNjb3VudCIsCiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMWM0dzRqeGRrdmozeWdkeWNka2p5OThqdmU2dzBkNzI1N2VxZng5IiwKICAgICAgICAgICJwdWJfa2V5IjogbnVsbCwKICAgICAgICAgICJhY2NvdW50X251bWJlciI6ICIyIiwKICAgICAgICAgICJzZXF1ZW5jZSI6ICIwIgogICAgICAgIH0KICAgICAgXQogICAgfSwKICAgICJhdXRoeiI6IHsKICAgICAgImF1dGhvcml6YXRpb24iOiBbXQogICAgfSwKICAgICJiYW5rIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJzZW5kX2VuYWJsZWQiOiBbXSwKICAgICAgICAiZGVmYXVsdF9zZW5kX2VuYWJsZWQiOiB0cnVlCiAgICAgIH0sCiAgICAgICJiYWxhbmNlcyI6IFsKICAgICAgICB7CiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMXZjdzBoZTVsOW11NTR6YXdnM2g0NDBwODNleDcwY2NtbWU1M2FjIiwKICAgICAgICAgICJjb2lucyI6IFsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICAgImFtb3VudCI6ICIxMDAwMDAwMDAwIgogICAgICAgICAgICB9CiAgICAgICAgICBdCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMWtuZzZzcWttMG1qdWgwOWN3ejZ1ODZmNzVsbWVmbGo5aDBmcWhyIiwKICAgICAgICAgICJjb2lucyI6IFsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICAgImFtb3VudCI6ICIxMDAwMDAwMDAwIgogICAgICAgICAgICB9CiAgICAgICAgICBdCiAgICAgICAgfQogICAgICBdLAogICAgICAic3VwcGx5IjogWwogICAgICAgIHsKICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAiYW1vdW50IjogIjIwMDAwMDAwMDAiCiAgICAgICAgfQogICAgICBdLAogICAgICAiZGVub21fbWV0YWRhdGEiOiBbXSwKICAgICAgInNlbmRfZW5hYmxlZCI6IFtdCiAgICB9LAogICAgImNhcGFiaWxpdHkiOiB7CiAgICAgICJpbmRleCI6ICIxIiwKICAgICAgIm93bmVycyI6IFtdCiAgICB9LAogICAgImNpcmN1aXQiOiB7CiAgICAgICJhY2NvdW50X3Blcm1pc3Npb25zIjogW10sCiAgICAgICJkaXNhYmxlZF90eXBlX3VybHMiOiBbXQogICAgfSwKICAgICJjb25zZW5zdXMiOiBudWxsLAogICAgImNyaXNpcyI6IHsKICAgICAgImNvbnN0YW50X2ZlZSI6IHsKICAgICAgICAiZGVub20iOiAic3Rha2UiLAogICAgICAgICJhbW91bnQiOiAiMTAwMCIKICAgICAgfQogICAgfSwKICAgICJkaXN0cmlidXRpb24iOiB7CiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgImNvbW11bml0eV90YXgiOiAiMC4wMjAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJiYXNlX3Byb3Bvc2VyX3Jld2FyZCI6ICIwLjAwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImJvbnVzX3Byb3Bvc2VyX3Jld2FyZCI6ICIwLjAwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgIndpdGhkcmF3X2FkZHJfZW5hYmxlZCI6IHRydWUKICAgICAgfSwKICAgICAgImZlZV9wb29sIjogewogICAgICAgICJjb21tdW5pdHlfcG9vbCI6IFtdCiAgICAgIH0sCiAgICAgICJkZWxlZ2F0b3Jfd2l0aGRyYXdfaW5mb3MiOiBbXSwKICAgICAgInByZXZpb3VzX3Byb3Bvc2VyIjogIiIsCiAgICAgICJvdXRzdGFuZGluZ19yZXdhcmRzIjogW10sCiAgICAgICJ2YWxpZGF0b3JfYWNjdW11bGF0ZWRfY29tbWlzc2lvbnMiOiBbXSwKICAgICAgInZhbGlkYXRvcl9oaXN0b3JpY2FsX3Jld2FyZHMiOiBbXSwKICAgICAgInZhbGlkYXRvcl9jdXJyZW50X3Jld2FyZHMiOiBbXSwKICAgICAgImRlbGVnYXRvcl9zdGFydGluZ19pbmZvcyI6IFtdLAogICAgICAidmFsaWRhdG9yX3NsYXNoX2V2ZW50cyI6IFtdCiAgICB9LAogICAgImV2aWRlbmNlIjogewogICAgICAiZXZpZGVuY2UiOiBbXQogICAgfSwKICAgICJmZWVncmFudCI6IHsKICAgICAgImFsbG93YW5jZXMiOiBbXQogICAgfSwKICAgICJmZWVpYmMiOiB7CiAgICAgICJpZGVudGlmaWVkX2ZlZXMiOiBbXSwKICAgICAgImZlZV9lbmFibGVkX2NoYW5uZWxzIjogW10sCiAgICAgICJyZWdpc3RlcmVkX3BheWVlcyI6IFtdLAogICAgICAicmVnaXN0ZXJlZF9jb3VudGVycGFydHlfcGF5ZWVzIjogW10sCiAgICAgICJmb3J3YXJkX3JlbGF5ZXJzIjogW10KICAgIH0sCiAgICAiZ2VudXRpbCI6IHsKICAgICAgImdlbl90eHMiOiBbCiAgICAgICAgewogICAgICAgICAgImJvZHkiOiB7CiAgICAgICAgICAgICJtZXNzYWdlcyI6IFsKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5zdGFraW5nLnYxYmV0YTEuTXNnQ3JlYXRlVmFsaWRhdG9yIiwKICAgICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IHsKICAgICAgICAgICAgICAgICAgIm1vbmlrZXIiOiAibm9kZTEiLAogICAgICAgICAgICAgICAgICAiaWRlbnRpdHkiOiAiIiwKICAgICAgICAgICAgICAgICAgIndlYnNpdGUiOiAiIiwKICAgICAgICAgICAgICAgICAgInNlY3VyaXR5X2NvbnRhY3QiOiAiIiwKICAgICAgICAgICAgICAgICAgImRldGFpbHMiOiAiIgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJjb21taXNzaW9uIjogewogICAgICAgICAgICAgICAgICAicmF0ZSI6ICIwLjEwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgICAgICAgICAgICJtYXhfcmF0ZSI6ICIwLjIwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgICAgICAgICAgICJtYXhfY2hhbmdlX3JhdGUiOiAiMC4wMTAwMDAwMDAwMDAwMDAwMDAiCiAgICAgICAgICAgICAgICB9LAogICAgICAgICAgICAgICAgIm1pbl9zZWxmX2RlbGVnYXRpb24iOiAiMSIsCiAgICAgICAgICAgICAgICAiZGVsZWdhdG9yX2FkZHJlc3MiOiAiIiwKICAgICAgICAgICAgICAgICJ2YWxpZGF0b3JfYWRkcmVzcyI6ICJ3YXNtdmFsb3BlcjF2Y3cwaGU1bDltdTU0emF3ZzNoNDQwcDgzZXg3MGNjbXc5cGRueiIsCiAgICAgICAgICAgICAgICAicHVia2V5IjogewogICAgICAgICAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5jcnlwdG8uZWQyNTUxOS5QdWJLZXkiLAogICAgICAgICAgICAgICAgICAia2V5IjogInlEKzJoN3ZZWW1yVTFBQSs3c01UdjFVaktFOFQ3aFZoZ01xcjlFei9IQTg9IgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJ2YWx1ZSI6IHsKICAgICAgICAgICAgICAgICAgImRlbm9tIjogInN0YWtlIiwKICAgICAgICAgICAgICAgICAgImFtb3VudCI6ICIyNTAwMDAwMDAiCiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgfQogICAgICAgICAgICBdLAogICAgICAgICAgICAibWVtbyI6ICIxOTVjYmUyYWM0YTNmMmUwNTFkNmNjNTgwOTZhNTUxNzJkOTMwZDNlQDE5Mi4xNjguNTAuMjUxOjI2NjU2IiwKICAgICAgICAgICAgInRpbWVvdXRfaGVpZ2h0IjogIjAiLAogICAgICAgICAgICAiZXh0ZW5zaW9uX29wdGlvbnMiOiBbXSwKICAgICAgICAgICAgIm5vbl9jcml0aWNhbF9leHRlbnNpb25fb3B0aW9ucyI6IFtdCiAgICAgICAgICB9LAogICAgICAgICAgImF1dGhfaW5mbyI6IHsKICAgICAgICAgICAgInNpZ25lcl9pbmZvcyI6IFsKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAicHVibGljX2tleSI6IHsKICAgICAgICAgICAgICAgICAgIkB0eXBlIjogIi9jb3Ntb3MuY3J5cHRvLnNlY3AyNTZrMS5QdWJLZXkiLAogICAgICAgICAgICAgICAgICAia2V5IjogIkFoRmdnWEc4ZlcwOEhLRGFjTGpoVVYyOGw2cVFRejY3WkF1b0hHRGx3Q3g0IgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJtb2RlX2luZm8iOiB7CiAgICAgICAgICAgICAgICAgICJzaW5nbGUiOiB7CiAgICAgICAgICAgICAgICAgICAgIm1vZGUiOiAiU0lHTl9NT0RFX0RJUkVDVCIKICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJzZXF1ZW5jZSI6ICIwIgogICAgICAgICAgICAgIH0KICAgICAgICAgICAgXSwKICAgICAgICAgICAgImZlZSI6IHsKICAgICAgICAgICAgICAiYW1vdW50IjogW10sCiAgICAgICAgICAgICAgImdhc19saW1pdCI6ICIyMDAwMDAiLAogICAgICAgICAgICAgICJwYXllciI6ICIiLAogICAgICAgICAgICAgICJncmFudGVyIjogIiIKICAgICAgICAgICAgfSwKICAgICAgICAgICAgInRpcCI6IG51bGwKICAgICAgICAgIH0sCiAgICAgICAgICAic2lnbmF0dXJlcyI6IFsKICAgICAgICAgICAgImVsQWlTQjUwZUkyamQ4T2kvR1JlUEdLaWFBNFlRNXYybVVtWm9UeWwxZllQdUZHL1BEdnJRZk84cHVRamdRN3RBc2hXVlV4V0lRdDlWRGdSaHhPcnd3PT0iCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICBdCiAgICB9LAogICAgImdvdiI6IHsKICAgICAgInN0YXJ0aW5nX3Byb3Bvc2FsX2lkIjogIjEiLAogICAgICAiZGVwb3NpdHMiOiBbXSwKICAgICAgInZvdGVzIjogW10sCiAgICAgICJwcm9wb3NhbHMiOiBbXSwKICAgICAgImRlcG9zaXRfcGFyYW1zIjogbnVsbCwKICAgICAgInZvdGluZ19wYXJhbXMiOiBudWxsLAogICAgICAidGFsbHlfcGFyYW1zIjogbnVsbCwKICAgICAgInBhcmFtcyI6IHsKICAgICAgICAibWluX2RlcG9zaXQiOiBbCiAgICAgICAgICB7CiAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICJhbW91bnQiOiAiMTAwMDAwMDAiCiAgICAgICAgICB9CiAgICAgICAgXSwKICAgICAgICAibWF4X2RlcG9zaXRfcGVyaW9kIjogIjE3MjgwMHMiLAogICAgICAgICJ2b3RpbmdfcGVyaW9kIjogIjE3MjgwMHMiLAogICAgICAgICJxdW9ydW0iOiAiMC4zMzQwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJ0aHJlc2hvbGQiOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJ2ZXRvX3RocmVzaG9sZCI6ICIwLjMzNDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgIm1pbl9pbml0aWFsX2RlcG9zaXRfcmF0aW8iOiAiMC4wMDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJwcm9wb3NhbF9jYW5jZWxfcmF0aW8iOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJwcm9wb3NhbF9jYW5jZWxfZGVzdCI6ICIiLAogICAgICAgICJleHBlZGl0ZWRfdm90aW5nX3BlcmlvZCI6ICI4NjQwMHMiLAogICAgICAgICJleHBlZGl0ZWRfdGhyZXNob2xkIjogIjAuNjY3MDAwMDAwMDAwMDAwMDAwIiwKICAgICAgICAiZXhwZWRpdGVkX21pbl9kZXBvc2l0IjogWwogICAgICAgICAgewogICAgICAgICAgICAiZGVub20iOiAic3Rha2UiLAogICAgICAgICAgICAiYW1vdW50IjogIjUwMDAwMDAwIgogICAgICAgICAgfQogICAgICAgIF0sCiAgICAgICAgImJ1cm5fdm90ZV9xdW9ydW0iOiBmYWxzZSwKICAgICAgICAiYnVybl9wcm9wb3NhbF9kZXBvc2l0X3ByZXZvdGUiOiBmYWxzZSwKICAgICAgICAiYnVybl92b3RlX3ZldG8iOiB0cnVlLAogICAgICAgICJtaW5fZGVwb3NpdF9yYXRpbyI6ICIwLjAxMDAwMDAwMDAwMDAwMDAwMCIKICAgICAgfSwKICAgICAgImNvbnN0aXR1dGlvbiI6ICIiCiAgICB9LAogICAgImdyb3VwIjogewogICAgICAiZ3JvdXBfc2VxIjogIjAiLAogICAgICAiZ3JvdXBzIjogW10sCiAgICAgICJncm91cF9tZW1iZXJzIjogW10sCiAgICAgICJncm91cF9wb2xpY3lfc2VxIjogIjAiLAogICAgICAiZ3JvdXBfcG9saWNpZXMiOiBbXSwKICAgICAgInByb3Bvc2FsX3NlcSI6ICIwIiwKICAgICAgInByb3Bvc2FscyI6IFtdLAogICAgICAidm90ZXMiOiBbXQogICAgfSwKICAgICJpYmMiOiB7CiAgICAgICJjbGllbnRfZ2VuZXNpcyI6IHsKICAgICAgICAiY2xpZW50cyI6IFtdLAogICAgICAgICJjbGllbnRzX2NvbnNlbnN1cyI6IFtdLAogICAgICAgICJjbGllbnRzX21ldGFkYXRhIjogW10sCiAgICAgICAgInBhcmFtcyI6IHsKICAgICAgICAgICJhbGxvd2VkX2NsaWVudHMiOiBbCiAgICAgICAgICAgICIwNi1zb2xvbWFjaGluZSIsCiAgICAgICAgICAgICIwNy10ZW5kZXJtaW50IiwKICAgICAgICAgICAgIjA5LWxvY2FsaG9zdCIKICAgICAgICAgIF0KICAgICAgICB9LAogICAgICAgICJjcmVhdGVfbG9jYWxob3N0IjogZmFsc2UsCiAgICAgICAgIm5leHRfY2xpZW50X3NlcXVlbmNlIjogIjAiCiAgICAgIH0sCiAgICAgICJjb25uZWN0aW9uX2dlbmVzaXMiOiB7CiAgICAgICAgImNvbm5lY3Rpb25zIjogW10sCiAgICAgICAgImNsaWVudF9jb25uZWN0aW9uX3BhdGhzIjogW10sCiAgICAgICAgIm5leHRfY29ubmVjdGlvbl9zZXF1ZW5jZSI6ICIwIiwKICAgICAgICAicGFyYW1zIjogewogICAgICAgICAgIm1heF9leHBlY3RlZF90aW1lX3Blcl9ibG9jayI6ICIzMDAwMDAwMDAwMCIKICAgICAgICB9CiAgICAgIH0sCiAgICAgICJjaGFubmVsX2dlbmVzaXMiOiB7CiAgICAgICAgImNoYW5uZWxzIjogW10sCiAgICAgICAgImFja25vd2xlZGdlbWVudHMiOiBbXSwKICAgICAgICAiY29tbWl0bWVudHMiOiBbXSwKICAgICAgICAicmVjZWlwdHMiOiBbXSwKICAgICAgICAic2VuZF9zZXF1ZW5jZXMiOiBbXSwKICAgICAgICAicmVjdl9zZXF1ZW5jZXMiOiBbXSwKICAgICAgICAiYWNrX3NlcXVlbmNlcyI6IFtdLAogICAgICAgICJuZXh0X2NoYW5uZWxfc2VxdWVuY2UiOiAiMCIKICAgICAgfQogICAgfSwKICAgICJpbnRlcmNoYWluYWNjb3VudHMiOiB7CiAgICAgICJjb250cm9sbGVyX2dlbmVzaXNfc3RhdGUiOiB7CiAgICAgICAgImFjdGl2ZV9jaGFubmVscyI6IFtdLAogICAgICAgICJpbnRlcmNoYWluX2FjY291bnRzIjogW10sCiAgICAgICAgInBvcnRzIjogW10sCiAgICAgICAgInBhcmFtcyI6IHsKICAgICAgICAgICJjb250cm9sbGVyX2VuYWJsZWQiOiB0cnVlCiAgICAgICAgfQogICAgICB9LAogICAgICAiaG9zdF9nZW5lc2lzX3N0YXRlIjogewogICAgICAgICJhY3RpdmVfY2hhbm5lbHMiOiBbXSwKICAgICAgICAiaW50ZXJjaGFpbl9hY2NvdW50cyI6IFtdLAogICAgICAgICJwb3J0IjogImljYWhvc3QiLAogICAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgICAiaG9zdF9lbmFibGVkIjogdHJ1ZSwKICAgICAgICAgICJhbGxvd19tZXNzYWdlcyI6IFsKICAgICAgICAgICAgIioiCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAogICAgIm1pbnQiOiB7CiAgICAgICJtaW50ZXIiOiB7CiAgICAgICAgImluZmxhdGlvbiI6ICIwLjEzMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImFubnVhbF9wcm92aXNpb25zIjogIjAuMDAwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAicGFyYW1zIjogewogICAgICAgICJtaW50X2Rlbm9tIjogInN0YWtlIiwKICAgICAgICAiaW5mbGF0aW9uX3JhdGVfY2hhbmdlIjogIjAuMTMwMDAwMDAwMDAwMDAwMDAwIiwKICAgICAgICAiaW5mbGF0aW9uX21heCI6ICIwLjIwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImluZmxhdGlvbl9taW4iOiAiMC4wNzAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJnb2FsX2JvbmRlZCI6ICIwLjY3MDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImJsb2Nrc19wZXJfeWVhciI6ICI2MzExNTIwIgogICAgICB9CiAgICB9LAogICAgIm5mdCI6IHsKICAgICAgImNsYXNzZXMiOiBbXSwKICAgICAgImVudHJpZXMiOiBbXQogICAgfSwKICAgICJwYXJhbXMiOiBudWxsLAogICAgInNsYXNoaW5nIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJzaWduZWRfYmxvY2tzX3dpbmRvdyI6ICIxMDAiLAogICAgICAgICJtaW5fc2lnbmVkX3Blcl93aW5kb3ciOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJkb3dudGltZV9qYWlsX2R1cmF0aW9uIjogIjYwMHMiLAogICAgICAgICJzbGFzaF9mcmFjdGlvbl9kb3VibGVfc2lnbiI6ICIwLjA1MDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgInNsYXNoX2ZyYWN0aW9uX2Rvd250aW1lIjogIjAuMDEwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAic2lnbmluZ19pbmZvcyI6IFtdLAogICAgICAibWlzc2VkX2Jsb2NrcyI6IFtdCiAgICB9LAogICAgInN0YWtpbmciOiB7CiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgInVuYm9uZGluZ190aW1lIjogIjE4MTQ0MDBzIiwKICAgICAgICAibWF4X3ZhbGlkYXRvcnMiOiAxMDAsCiAgICAgICAgIm1heF9lbnRyaWVzIjogNywKICAgICAgICAiaGlzdG9yaWNhbF9lbnRyaWVzIjogMTAwMDAsCiAgICAgICAgImJvbmRfZGVub20iOiAic3Rha2UiLAogICAgICAgICJtaW5fY29tbWlzc2lvbl9yYXRlIjogIjAuMDAwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAibGFzdF90b3RhbF9wb3dlciI6ICIwIiwKICAgICAgImxhc3RfdmFsaWRhdG9yX3Bvd2VycyI6IFtdLAogICAgICAidmFsaWRhdG9ycyI6IFtdLAogICAgICAiZGVsZWdhdGlvbnMiOiBbXSwKICAgICAgInVuYm9uZGluZ19kZWxlZ2F0aW9ucyI6IFtdLAogICAgICAicmVkZWxlZ2F0aW9ucyI6IFtdLAogICAgICAiZXhwb3J0ZWQiOiBmYWxzZQogICAgfSwKICAgICJ0cmFuc2ZlciI6IHsKICAgICAgInBvcnRfaWQiOiAidHJhbnNmZXIiLAogICAgICAiZGVub21fdHJhY2VzIjogW10sCiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgInNlbmRfZW5hYmxlZCI6IHRydWUsCiAgICAgICAgInJlY2VpdmVfZW5hYmxlZCI6IHRydWUKICAgICAgfSwKICAgICAgInRvdGFsX2VzY3Jvd2VkIjogW10KICAgIH0sCiAgICAidXBncmFkZSI6IHt9LAogICAgInZlc3RpbmciOiB7fSwKICAgICJ3YXNtIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJjb2RlX3VwbG9hZF9hY2Nlc3MiOiB7CiAgICAgICAgICAicGVybWlzc2lvbiI6ICJFdmVyeWJvZHkiLAogICAgICAgICAgImFkZHJlc3NlcyI6IFtdCiAgICAgICAgfSwKICAgICAgICAiaW5zdGFudGlhdGVfZGVmYXVsdF9wZXJtaXNzaW9uIjogIkV2ZXJ5Ym9keSIKICAgICAgfSwKICAgICAgImNvZGVzIjogW10sCiAgICAgICJjb250cmFjdHMiOiBbXSwKICAgICAgInNlcXVlbmNlcyI6IFtdCiAgICB9CiAgfSwKICAiY29uc2Vuc3VzIjogewogICAgInBhcmFtcyI6IHsKICAgICAgImJsb2NrIjogewogICAgICAgICJtYXhfYnl0ZXMiOiAiMjIwMjAwOTYiLAogICAgICAgICJtYXhfZ2FzIjogIi0xIgogICAgICB9LAogICAgICAiZXZpZGVuY2UiOiB7CiAgICAgICAgIm1heF9hZ2VfbnVtX2Jsb2NrcyI6ICIxMDAwMDAiLAogICAgICAgICJtYXhfYWdlX2R1cmF0aW9uIjogIjE3MjgwMDAwMDAwMDAwMCIsCiAgICAgICAgIm1heF9ieXRlcyI6ICIxMDQ4NTc2IgogICAgICB9LAogICAgICAidmFsaWRhdG9yIjogewogICAgICAgICJwdWJfa2V5X3R5cGVzIjogWwogICAgICAgICAgImVkMjU1MTkiCiAgICAgICAgXQogICAgICB9LAogICAgICAidmVyc2lvbiI6IHsKICAgICAgICAiYXBwIjogIjAiCiAgICAgIH0sCiAgICAgICJhYmNpIjogewogICAgICAgICJ2b3RlX2V4dGVuc2lvbnNfZW5hYmxlX2hlaWdodCI6ICIwIgogICAgICB9CiAgICB9CiAgfQp9"
  }
}

Landslide

Landslide

Overview

Goals

Quick links

Get Started

Product Guides

Run Landslide Locally

How to setup Slide SDK locally

Dependencies

1. Go Installation

Recommended Go Version

2. AvalancheGo Installation

a. Clone repository:

b. Download and install AvalancheGo:

Run a CosmWasm Application

1. Build CosmWasm Plugin

2. Run a Wasm L1

Expected Outputs

Next Steps

Troubleshooting

Conect your wallet to a local network

Cosmostation Wallet

Verify your seed phrase

How to deploy a CosmWasm contract

Important Note on Terminal Usage

1. Build and Install Wasmd

2. Import Private Key

3. Deploy Smart Contract

6. Query Code ID Metadata

Next Steps

Troubleshooting

Run Landslide on Testnet

How to connect Cosmostation

Cosmostation Wallet

Verify your seed phrase

License

Security Audit

Landslide EVM

Relayer Operator Guide

Relayer

Table Of Contents

Basic Usage - Relaying Packets Across Chains

Chain integrators guide

Lower than v0.50

Integrating the Avalanche Light-Client Module in Your Cosmos SDK Application

1. Import the Avalanche Light-Client Module

2. Register the Avalanche Module in the Module Manager

Higher than v0.50

Integrating the Avalanche Light-Client Module in Your Cosmos SDK Application

1. Import the Avalanche Light-Client Module

2. Register the Avalanche Module in the Module Manager

3. Add module to the RegisterIBC function

IBC Connection

Overview

IBC Go

IBC Relayer AVAX L1 Proof

API endpoints

🔌 Landslide Network Testnet Endpoints

RPC Endpoint

Avalanche Warp Messaging

Overview

Integrations

Connecting Existing Cosmos dApps to Avalanche

Overview

Case Study: Osmosis

Cosmoswap

ABCI Calls

ABCI Calls

FAQ

Roadmap

Overview

What is CometBFT?

CometBFT Explained

What is Avalanche Consensus?

Avalanche Consensus

Overview

Sub sampling

Faster Finality

Video overview