# Landslide An overview of the Landslide Network {% hint style="info" %} **Landslide tip:** This product is currently being developed! If you report issues, we will note them and include you in our incentivized testnet. {% endhint %} ## 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 ([Polkadot](https://composable.finance/) 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 [IBC-enabled](https://github.com/cosmos/ibc) 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: 1. 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. 2. 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. 3. 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. 4. 100% compatibility with Cosmos SDK: The Landslide Network is designed to be highly compatible with the native Cosmos-based SDK, enabling developers to easily port their existing dApps to the Landslide Network. 5. Collaboration between Avalanche, Cosmos, and other IBC-enabled chains: The Landslide Network aims to create closer collaboration between the three ecosystems of Avalanche, Cosmos, and other IBC-enabled chains, creating a stronger, more interconnected blockchain ecosystem. > 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[@cosmos](https://twitter.com/cosmos)? > > 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. ( [$OSMO](https://twitter.com/search?q=%24OSMO\&src=cashtag_click), [$LUNA](https://twitter.com/search?q=%24LUNA\&src=cashtag_click), [$RUNE](https://twitter.com/search?q=%24RUNE\&src=cashtag_click), [$JUNO](https://twitter.com/search?q=%24JUNO\&src=cashtag_click)) > > 3\. Aggregated liquidity > > — [Emperor Osmo](https://twitter.com/flowslikeosmo/status/1624785489265033216) ## Quick links {% content-ref url="/pages/Rh81SL8Y624S31Aw7UfO" %} [What is CometBFT?](/overview/what-is-cometbft) {% endcontent-ref %} {% content-ref url="/pages/EldnyxCOjPvJB3joz7Io" %} [Features](/overview/features) {% endcontent-ref %} ## Get Started We've put together some helpful guides for you to get setup with our product quickly and easily. {% content-ref url="/pages/ufC9MfHtZlKB7VRuCCeZ" %} [Getting set up](/fundamentals/getting-set-up) {% endcontent-ref %} {% content-ref url="/spaces/PdxSILrJhVcwwtZuvGHo/pages/YwPM2caaRrm3rpiTg8ul" %} [Landslide & CometBFT](/product-guides/landslide-and-cometbft) {% endcontent-ref %} {% content-ref url="/spaces/PdxSILrJhVcwwtZuvGHo/pages/1SmMnYGMsViB6Y1iNvii" %} [Connecting Existing Cosmos dApps to Avalanche](/integrations/connecting-existing-cosmos-dapps-to-avalanche) {% endcontent-ref %} # Landslide & CometBFT A Primer on Landslide as it relates to Cosmos dApps. ## CometBFT on Avalanche Cosmos apps are built on two key components: CometBFT and the CosmosSDK. CometBFT is a Byzantine Fault-Tolerant (BFT) middleware that securely replicates a state transition machine written in any programming language on many machines. It is designed to be fast and scalable but has significant limitations. On the other hand, the Cosmos SDK is a software development kit (SDK) that provides a framework for building decentralized applications (dApps) on top of the CometBFT consensus engine. It includes a set of modular tools and libraries that make it easy for developers to build, test, and deploy custom blockchain applications. Together, these two components form the backbone of the Cosmos ecosystem, providing a powerful platform for building fast, secure, and scalable decentralized applications. By leveraging the strengths of CometBFT and the Cosmos SDK, developers can build a wide range of dApps, including decentralized exchanges, prediction markets, and more. {% @mermaid/diagram content="--- title: Native Cosmos Chains --------------------------- flowchart TB id1(((Cosmos dApp))) --> id2{CometBFT} id1(((Cosmos dApp))) --> id3((CosmosSDK))" %} {% @mermaid/diagram content="--- title: Landslide Network ------------------------ flowchart TB id4(((Landslide dApp))) --> id5{Landslide EVM} id4(((Landslide dApp))) --> id6((Slide SDK)) style id4 fill:#f9f,stroke:#333,stroke-width:4px style id5 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 style id6 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 " %} ## Landslide Core Similarly, [LandslideCore](https://github.com/ConsiderItDone/LandslideCore/blob/0.34.19-lanslide-core/vm/cmd/main.go) provides developers with a powerful and flexible platform for building decentralized applications on the Avalanche network, while leveraging the familiar architecture and development tools that have made Cosmos dApps so successful. Like Cosmos dApps, Landslide is built on two key components: Landslide Core and CosmosAVAX SDK. Landslide Core is a customized version of Tendermint that utilizes the highly efficient and scalable Avalanche consensus algorithm. This provides developers with faster finality times, greater scalability, and improved throughput, all while maintaining compatibility with the existing Tendermint architecture. Meanwhile, CosmosAVAX SDK is an SDK 100% compatible with the CosmosSDK for building decentralized applications on top of the Landslide Core. It includes a set of modular tools and libraries that enable developers to easily build, test, and deploy custom blockchain applications on the Avalanche network. By following the architecture used in Cosmos dApps, Landslide provides developers with a familiar and intuitive platform for building high-performance dApps on the Avalanche network. This makes it easier for developers to port existing dApps from other networks onto the Avalanche network, while also enabling them to take advantage of the advanced features offered by the Landslide consensus algorithm. ## # Tendermint Core -> Landslide Core What Tendermint looks like in AVAX. ## Details LandslideCore is a customized version of the Tendermint blockchain software, designed to operate using the Avalanche consensus algorithm rather than the default Tendermint consensus mechanism. Notice this forked version of Tendermint removes the original Tendermint consensus algorithm and replaces it with the Avalanche consensus, which is faster, more efficient, and more scalable than the original algorithm. In addition, the following modules are removed from Tendermint Core: Mempool reactor, and the Consensus Reactor. The P2P networking layer and the HTTP servers are augmented to use the those in Avalanche. With LandslideCore, developers can leverage the powerful features of the Avalanche network, while still using a familiar blockchain software platform. The result is a blockchain software that provides faster finality times, better throughput, and greater scalability, making it an ideal platform for developing high-performance decentralized applications. ### Native Tendermint Below is a diagram of native Tendermint, (e.g. what Tendermint looks like currently.) {% @mermaid/diagram content="--- title: Native Tendermint ------------------------ flowchart TB id3\[(Tendermint Core)] --> id4(Mempool) --> id5(Mempool Reactor) id3\[(Tendermint Core)] --> id6\[(State, StateDB)] --> id7(Consensus Reactor) id3\[(Tendermint Core)] --> id8(HTTP) --> id9(P2P: Switch, Reactor) id3\[(Tendermint Core)] --> id10(Block Executor) id3\[(Tendermint Core)] --> id11\[(BlockDB, BlockStore)] style id5 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 style id7 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 style id9 fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 " %} ### Landslide Core Notice this forked version of Tendermint removes the original Tendermint consensus algorithm and replaces it with the Avalanche consensus, which is faster, more efficient, and more scalable than the original algorithm. In addition, the following modules are removed from Tendermint Core: Mempool reactor, and the Consensus Reactor. The P2P networking layer and the HTTP servers are augmented to use the those in Avalanche. With LandslideCore, developers can leverage the powerful features of the Avalanche network, while still using a familiar blockchain software platform. The result is a blockchain software that provides faster finality times, better throughput, and greater scalability, making it an ideal platform for developing high-performance decentralized applications. {% @mermaid/diagram content="--- title: Landslide Core --------------------- flowchart TB id3\[(Landslide Core)] --> id4(Mempool) --> id53 subgraph id53 \[Avalanche Ecosystem] direction TB id2(Mempool Reactor) id7(Avalanche Consensus) id9(P2P: Switch, Reactor) end id3\[(Landslide Core)] --> id6\[(State, StateDB)] --> id7 id3\[(Landslide Core)] --> id8(HTTP) --> id9(P2P: Switch, Reactor) id3\[(Landslide Core)] --> id10(Block Executor) id3\[(Landslide Core)] --> id11\[(BlockDB, BlockStore)] style id2 fill:#f9f,stroke:#333,stroke-width:1px style id7 fill:#f9f,stroke:#333,stroke-width:1px style id9 fill:#f9f,stroke:#333,stroke-width:1px" %} ### Connecting Landslide Core to IBC Here we imagine Cosmos and Avalanche as two groups of computers. They want to talk to each other, but they speak different languages. So they use a special helper called IBC to translate for them. Avalanche has a few helpers, called modules and subnets, that help them talk to Cosmos. One module talks to another module in Avalanche, and another module talks to a subnet, which confirms state on the P-Chain. They are able to understand each other thanks to IBC.
Here we see Cosmos and Avalanche as two groups of ecosystems. They want to talk to each other, but they speak different languages. So they use a special helper called IBC to translate for them. Avalanche has a few helpers, called modules and subnets, that help them talk to Cosmos. One module talks to another module in Avalanche, and another module talks to a subnet, which confirms state on the P-Chain. They are able to understand each other thanks to IBC.

Transferring OSMO assets from Cosmos to AVAX via IBC.

{% @mermaid/diagram content="flowchart TB id1(IBC Relayer)-->id3 id1(IBC Relayer)-->id5 id55(AVAX C-chain)-->id5 id56(AVAX X-chain)-->id5 subgraph id3 \[Cosmos Chain: Osmosis] direction TB id2(Avalanche Light Client)-->id4(CosmosSDK)-->id91(Tendermint Core) end subgraph id5 \[AVAX Subnet] direction TB id21(Tendermint Light Client)-->id6(LandslideSDK)-->id9(Landslide Core) end style id2 fill:#f9f,stroke:#333,stroke-width:1px style id6 fill:#f9f,stroke:#333,stroke-width:1px style id9 fill:#f9f,stroke:#333,stroke-width:1px style id21 fill:#f94,stroke:#333,stroke-width:1px" %} # LandslideCore The Landslide Consensus Core Package ## Landslide Core v 0.1 {% embed url="" %} LandslideCore Open Source Repo {% endembed %} Landslide Core is a new blockchain network built on top of Avalanche that provides high throughput, fast finality times, and IBC compatibility for Cosmos SDK-based decentralized applications (dApps). It includes a fork of Tendermint that uses the Avalanche consensus algorithm, which enables faster transaction finality times compared to traditional Tendermint consensus. Additionally, Landslide Core includes a compatible fork of the Cosmos SDK, which allows Cosmos-based dApps to run natively on the Avalanche network. This software documentation provides an overview of Landslide Core's features, including its architecture, consensus algorithm, and SDK compatibility, and serves as a guide for developers looking to build decentralized applications on the Landslide Core network.\ \ LandslideSDK documentation is still under construction. # Functions Documentation of functions in Landslide Core ### Initialize the Avalanche Virtual Machine ```go Initialize ``` **Context**: An example usage of this function might be to initialize the Avalanche virtual machine before deploying a custom dApp on the Avalanche network. **Parameters**: The function takes the following parameters: * `context.Context`: The context object for the operation. * `*snow.Context`: The context object for the Avalanche network. * `manager.Manager`: The manager object for the Avalanche database. * `[]byte`: The Genesis bytes for the Avalanche network. * `[]byte`: The Upgrade bytes for the Avalanche network. * `[]byte`: The Config bytes for the Avalanche network. * `chan<- common.Message`: The channel used to send messages to the Avalanche engine. * `[]*common.Fx`: A slice of the Fx objects used on the Avalanche network. * `common.AppSender`: The application sender object used on the Avalanche network. **Return Type:** The function returns an error.
**Functionality**: This function initializes the Avalanche virtual machine by setting up various databases and stores, loading the genesis state, creating the proxy app and establishing connections to the ABCI app, creating the event bus, and initializing the transaction and block indexers. It returns an error if any of these operations fail. ```go NewVM ``` 1. Function Name: The name of the function is `NewVM`. 2. Parameters: The function takes the following parameter: * `abciTypes.Application`: The application object used by the Avalanche network. 3. Return Type: The function returns a pointer to a `VM` struct. 4. Functionality: This function creates a new `VM` struct with the provided application object and returns a pointer to it. The `VM` struct represents the Avalanche virtual machine and is used to initialize and run dApps on the Avalanche network. 5. Example Usage: An example usage of this function might be to create a new `VM` object before calling the `Initialize` function to set up the virtual machine and deploy a custom dApp on the Avalanche network. The `abciTypes.Application` interface is a key component of the Tendermint consensus engine used by the Avalanche virtual machine. It is used to allow the user to pass any ABCI application that follows this interface via Tendermint, which then works together with the virtual machine. The ABCI (Application BlockChain Interface) is an interface between Tendermint and the application layer of the blockchain. It defines the methods and protocols for communication between the Tendermint consensus engine and the application layer, allowing the two layers to work together seamlessly. The `abciTypes.Application` interface is implemented by the ABCI application layer of the blockchain. By implementing this interface, an application can be plugged into the Tendermint consensus engine, allowing it to interact with the blockchain at a low level. When the `NewVM` function is called with an `abciTypes.Application` object as a parameter, it creates a new `VM` struct that includes a reference to the provided `Application` object. This `Application` object is then used by the Tendermint consensus engine to communicate with the application layer of the blockchain, allowing the two layers to work together in harmony. Overall, the `abciTypes.Application` interface is a key component of the Tendermint consensus engine used by the Avalanche virtual machine, allowing developers to plug in any ABCI-compliant application and use it to build custom dApps on the Avalanche network. # VM tests ### `TestABCIService` `TestABCIService` unit test in the `service_test.go` file. Overall, the `TestABCIService` unit test is testing several methods of the virtual machine service and verifying that they behave as expected. Here's a breakdown of what the test is doing: 1. The `TestABCIService` function starts by calling the `mustNewKVTestVm` function to create a new instance of the virtual machine and virtual machine service, and assigns them to the `vm` and `service` variables. 2. The test then runs several subtests using the `t.Run` method, each of which tests a different method of the virtual machine service. #### Subtests 1. `ABCIInfo`, tests the `ABCIInfo` method of the virtual machine service. It creates a new `ctypes.ResultABCIInfo` variable and passes it to the `ABCIInfo` method. It then asserts that there is no error returned by the method, and that the response contains the expected values for the app version, last block height, and last block app hash. 2. `ABCIQuery`, tests the `ABCIQuery` method of the virtual machine service. It creates a new key-value transaction using the `MakeTxKV` function, broadcasts the transaction using the `BroadcastTxSync` method of the virtual machine service, builds and accepts a new block using the virtual machine, and then queries the virtual machine service for the value of the key using the `ABCIQuery` method. If the query is successful, the subtest asserts that the value returned by the method is equal to the expected value. 3. `BroadcastTxCommit`, tests the `BroadcastTxCommit` method of the virtual machine service. It creates a new key-value transaction using the `MakeTxKV` function, broadcasts the transaction using the `BroadcastTxCommit` method of the virtual machine service, and then asserts that the `CheckTx` and `DeliverTx` fields of the response contain `true`, indicating that the transaction was successfully checked and committed to the blockchain. 4. `BroadcastTxAsync`, tests the `BroadcastTxAsync` method of the virtual machine service. It creates a new key-value transaction using the `MakeTxKV` function, broadcasts the transaction using the `BroadcastTxAsync` method of the virtual machine service, and then asserts that the `Hash` field of the response is not `nil`, indicating that the transaction was successfully added to the mempool. 5. `BroadcastTxSync`, tests the `BroadcastTxSync` method of the virtual machine service. It creates a new key-value transaction using the `MakeTxKV` function, broadcasts the transaction using the `BroadcastTxSync` method of the virtual machine service, and then asserts that the `Code` field of the response is equal to `atypes.CodeTypeOK`, indicating that the transaction was successfully checked and committed to the blockchain. ### `TestHistoryService` The `TestHistoryService` unit test in the `service_test.go` file. Overall, the `TestHistoryService` unit test is testing several methods of the virtual machine service related to blockchain history and verifying that they behave as expected. Here's a breakdown of what the test is doing: 1. The `TestHistoryService` function starts by calling the `mustNewCounterTestVm` function to create a new instance of the virtual machine and virtual machine service, and assigns them to the `vm` and `service` variables. 2. The test then broadcasts a new transaction using the `BroadcastTxSync` method of the virtual machine service and verifies that the response code is `atypes.CodeTypeOK`. 3. The test then builds and accepts a new block using the virtual machine. 4. The test then runs two subtests using the `t.Run` method, each of which tests a different method of the virtual machine service. #### Subtests 1. `BlockchainInfo` tests the `BlockchainInfo` method of the virtual machine service. It creates a new `ctypes.ResultBlockchainInfo` variable and passes it to the `BlockchainInfo` method with a `start` height of `1` and an `end` height of `100`. It then asserts that there is no error returned by the method and that the `LastHeight` field of the response is equal to `1`. 2. `Genesis` tests the `Genesis` method of the virtual machine service. It creates a new `ctypes.ResultGenesis` variable and passes it to the `Genesis` method. It then asserts that there is no error returned by the method and that the `Genesis` field of the response is equal to the expected value from the virtual machine's genesis configuration. ### `TestNetworkService` The `TestNetworkService` unit test in the `service_test.go` file. Overall, the `TestNetworkService` unit test is testing several methods of the virtual machine service related to **networking** and **consensus** and verifying that they behave as expected. Here's a breakdown of what the test is doing: 1. The `TestNetworkService` function starts by calling the `mustNewCounterTestVm` function to create a new instance of the virtual machine and virtual machine service, and assigns them to the `vm` and `service` variables. 2. The test then runs five subtests using the `t.Run` method, each of which tests a different method of the virtual machine service related to networking and consensus. #### Subtests 1. `NetInfo` tests the `NetInfo` method of the virtual machine service. It creates a new `ctypes.ResultNetInfo` variable and passes it to the `NetInfo` method. It then asserts that there is no error returned by the method. 2. `DumpConsensusState` tests the `DumpConsensusState` method of the virtual machine service. It creates a new `ctypes.ResultDumpConsensusState` variable and passes it to the `DumpConsensusState` method. It then asserts that there is no error returned by the method. 3. `ConsensusState` tests the `ConsensusState` method of the virtual machine service. It creates a new `ctypes.ResultConsensusState` variable and passes it to the `ConsensusState` method. It then asserts that there is no error returned by the method. 4. `ConsensusParams` tests the `ConsensusParams` method of the virtual machine service. It creates a new `ctypes.ResultConsensusParams` variable and passes it to the `ConsensusParams` method. It then asserts that there is no error returned by the method and that the `BlockHeight` field of the response is equal to `0`. It then broadcasts a new transaction using the `BroadcastTxSync` method of the virtual machine service, builds and accepts a new block using the virtual machine, and asserts that the `BlockHeight` field of the `ConsensusParams` response is equal to `1`. 5. `Health` tests the `Health` method of the virtual machine service. It creates a new `ctypes.ResultHealth` variable and passes it to the `Health` method. It then asserts that there is no error returned by the method. ### `TestSignService` Sure, I can help you document the `TestSignService` unit test in the `service_test.go` file. Here's a breakdown of what the test is doing: 1. The `TestSignService` function starts by creating a new key-value transaction (`tx`) and creating a new instance of the virtual machine and virtual machine service, which it assigns to the `vm` and `service` variables. 2. The test then performs several subtests using the `t.Run` method, each of which tests a different method of the virtual machine service related to signing and verification of transactions.The `TestSignService` has the following subtests: #### Subtests * `Block`which tests the `Block` method of the virtual machine service with a valid block height. It creates two new `ctypes.ResultBlock` variables and passes them to the `Block` method with a `Height` parameter of the block height. It then asserts that both methods return a `nil` error and that the `Height` field of the response is equal to the expected block height. * `BlockByHash` which tests the `BlockByHash` method of the virtual machine service with a valid block hash. It creates two new `ctypes.ResultBlock` variables and passes them to the `BlockByHash` method with a `Hash` parameter of the block hash. It then asserts that both methods return a `nil` error and that the `Hash` field of the response is equal to the expected block hash. * `BlockResults` which tests the `BlockResults` method of the virtual machine service with a valid block height. It creates two new `ctypes.ResultBlockResults` variables and passes them to the `BlockResults` method with a `Height` parameter of the block height. It then asserts that both methods return a `nil` error and that the `Height` field of the response is equal to the expected block height. * `Tx` which tests the `Tx` method of the virtual machine service with a valid transaction hash. It creates a new `ctypes.ResultTx` variable and passes it to the `Tx` method with a `Hash` parameter of the transaction hash. It then asserts that the method returns a `nil` error and that the `Hash` and `Tx` fields of the response are equal to the expected transaction hash and transaction, respectively. Overall, the `TestSignService` unit test is testing several methods of the virtual machine service related to signing and verification of transactions and verifying that they behave as expected. ### `TestStatusService` The `TestStatusService` unit test in the `service_test.go` file. Here's a breakdown of what the test is doing: 1. The `TestStatusService` function starts by creating a new instance of the virtual machine and virtual machine service, which it assigns to the `vm` and `service` variables. 2. The test then attempts to build a new block from the virtual machine with no pending transactions. It expects this operation to fail with an `errNoPendingTxs` error and a `nil` block. 3. Next, the test creates a new key-value transaction (`tx`) and uses the `BroadcastTxSync` method of the virtual machine service to broadcast the transaction. It asserts that the method returns no error and that the `Code` field of the response is equal to `atypes.CodeTypeOK`. 4. The test then creates a new subtest using the `t.Run` method, which tests the `Status` method of the virtual machine service with two different blocks. It creates two new `ctypes.ResultStatus` variables and passes them to the `Status` method. The first call is made with no arguments and expects the response to contain a `LatestBlockHeight` field with a value of `0`. The second call is made after successfully building and accepting a new block and expects the response to contain a `LatestBlockHeight` field with a value of `1`. Overall, the `TestStatusService` unit test is testing the `Status` method of the virtual machine service with two different blocks and verifying that the expected block height is returned in the response. ### `TestMempoolService` This unit test suite tests the functionalities of the `MempoolService` struct. **Sub-tests:** 1. `UnconfirmedTxs` * Description: Tests the functionality of retrieving unconfirmed transactions in the mempool. * Steps: 1. Build a transaction and broadcast it to the mempool. 2. Call the `UnconfirmedTxs` function of the `MempoolService`. * Expected Results: The function should return the single transaction that was broadcasted to the mempool. 2. `NumUnconfirmedTxs` * Description: Tests the functionality of retrieving the number of unconfirmed transactions in the mempool. * Steps: 1. Build a transaction and broadcast it to the mempool. 2. Call the `NumUnconfirmedTxs` function of the `MempoolService`. * Expected Results: The function should return a count of 1, indicating the single transaction that was broadcasted to the mempool. 3. `CheckTx` * Description: Tests the functionality of checking if a transaction is valid and can be accepted into the mempool. * Steps: 1. Build a transaction and broadcast it to the mempool. 2. Call the `CheckTx` function of the `MempoolService` with the same transaction. 3. Build a block and accept it. 4. Call the `CheckTx` function of the `MempoolService` with the same transaction. * Expected Results: * The first `CheckTx` function should return no errors, indicating the transaction is valid and can be accepted into the mempool. * The second `CheckTx` function should return an error, indicating the transaction has already been accepted into the blockchain and cannot be accepted into the mempool again. # Example ABCI Applications Documentation of Cosmos dApps (ABCI calls) in Landslide Core [This repo](https://github.com/ConsiderItDone/LandslideCore/blob/0.34.19-lanslide-core/vm/vm.go) contains the ABCI application calls. 1. Sample App Names: There are two sample apps provided in the LandslideCore: `KVStoreApplication` and `PersistentKVStoreApplication`. 2. App Functionality: The `KVStoreApplication` is a simple merkle key-value store that allows transactions of the form `key=value` to be stored as key-value pairs in the tree. Transactions without an `=` sign set the value to the key. The app has no replay protection other than what the mempool provides. 3. Additional Features: The `PersistentKVStoreApplication` wraps the `KVStoreApplication` and provides two additional features: persistence of state across app restarts using Tendermint's ABCI-Handshake mechanism, and validator set changes. The state is persisted in leveldb along with the last block committed, and the Handshake allows any necessary blocks to be replayed. Validator set changes are effected using a specific transaction format: `"val:pubkey1!power1,pubkey2!power2,pubkey3!power3"`. In this format, `pubkeyN` is a base64-encoded 32-byte ed25519 key and `powerN` is a new voting power for the validator with `pubkeyN` (possibly a new one). To remove a validator from the validator set, set `power` to 0. There is no sybil protection against new validators joining. 4. Location: The sample apps can be found in the LandslideCore/abci/example/ directory of the Landslide SDK. These sample apps provide developers with a starting point for building custom dApps on the Avalanche network using the Landslide SDK. Developers can use these sample apps as a reference for building their own merkle key-value store or for implementing more advanced features like persistence of state and validator set changes. ``` main.go ``` 1. Package Name: The package name is `main`. 2. Imported Packages: The following packages are imported: * `context`: This package provides functions for working with contexts, which carry deadlines, cancelation signals, and other request-scoped values across API boundaries and between processes. * `fmt`: This package implements formatted I/O with functions analogous to C's printf and scanf. * `github.com/consideritdone/landslidecore/abci/example/counter`: This package contains the implementation for the `counter` application used by the Landslide SDK. * `github.com/consideritdone/landslidecore/vm`: This package contains the implementation for the virtual machine used by the Landslide SDK. * `github.com/ava-labs/avalanchego/utils/logging`: This package provides logging utilities for the AvalancheGo node. * `github.com/ava-labs/avalanchego/utils/ulimit`: This package provides utilities for managing file descriptor limits. * `github.com/ava-labs/avalanchego/vms/rpcchainvm`: This package provides the implementation for the RPC ChainVM. 3. Main Function: The `main` function is the entry point for the LandslideCore executable. It performs the following tasks: * Sets the file descriptor limit using `ulimit.Set`. * Creates a new virtual machine using `landslideCoreVM.NewVM`. * Passes the `counter.NewApplication` as a parameter to `landslideCoreVM.NewVM`. * Calls `rpcchainvm.Serve` to serve the virtual machine and start the RPC server. 4. Example Usage: An example usage of this code might be to build and deploy a custom dApp, like an [Osmosis](https://osmosis.zone/) outpost, or the [Helix DEX](https://helixapp.com/) on the Avalanche network using the Landslide SDK. The `counter.NewApplication` function can be replaced with a custom application implementation, and the resulting executable can be deployed on the network using `rpcchainvm.Serve`. # License License Terms LandlideCore is launched under [Apache 2.0 License](https://github.com/LandslideNetwork/LandslideCore/blob/0.34.19-lanslide-core/LICENSE) and is fully open source. # Slide SDK

Seargent Slide, sliding for duty.

Landslide is a revolutionary IBC-enabled Avalanche L1 that bridges the gap between Avalanche and the interchain ecosystem. It allows any IBC-enabled chain to run natively on the Avalanche network, focusing on CosmWasm-based dApps to run natively on the Avalanche network, opening up new possibilities for cross-chain interactions and development. #### Key Features 1. **Native IBC Connectivity**: Seamlessly transfer assets between Landslide and other IBC-enabled chains. 2. **Sub-Second Finality**: Achieve transaction finality in under 1 second, significantly faster than traditional CometBFT-based chains. 3. **Cosmos SDK Compatibility**: Easily port existing Cosmos-based dApps to Landslide with 100% SDK compatibility. 4. **Cross-Chain DeFi**: Enable sophisticated DeFi operations across multiple blockchain networks. 5. **Avalanche Performance**: Leverage Avalanche's high throughput and low fees for improved user experience. #### Why Landslide? Landslide creates interoperability between the Avalanche and Cosmos ecosystems, fostering a more interconnected and robust blockchain landscape. Developers can utilize Avalanche's performance while maintaining access to the rich Cosmos ecosystem. Users benefit from increased liquidity, a more comprehensive range of applications, and a streamlined experience across multiple networks. #### Getting Started To begin your journey with Landslide, explore the following sections: * Connecting to Landslide Wasm Testnet * Running Landslide Wasm Application Locally * Deploying Smart Contracts on Landslide Join us in shaping the future of interoperable blockchain technology with Landslide! # 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](/product-guides/slide-sdk/run-landslide-locally/how-to-setup-slide-sdk-locally) * Setting up your development environment * Starting a local Landslide network * [How to deploy a CosmWasm contract](/product-guides/slide-sdk/run-landslide-locally/how-to-deploy-a-cosmwasm-contract) * Preparing your CosmWasm contract * Uploading and instantiating contracts on Landslide * [Connect wallet to local network](/product-guides/slide-sdk/run-landslide-locally/conect-your-wallet-to-a-local-network) * 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 [official Go website](https://golang.org/dl/)[.](https://go.dev/doc/install) * 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 * **Go 1.22.7** ### Known Issues * Versions of Go 1.23 and above may encounter WASM compilation errors, particularly with certain dependencies. ### Troubleshooting Steps If you encounter build issues: 1. Check your current Go version: ``` go version ``` 2. If you're not using Go 1.22.7, consider downgrading: * On macOS with Homebrew: ``` brew install go@1.22 brew unlink go brew link go@1.22 ``` * Add to your PATH: ``` echo 'export PATH="/usr/local/opt/go@1.22/bin:$PATH"' >> ~/.zshrc source ~/.zshrc ``` 3. After changing Go versions: * Clean your Go module cache: ``` go clean -modcache ``` * Update your modules: ``` go mod tidy ``` 4. Retry your build process. ### Additional Notes * If you need to manage multiple Go versions across different projects, consider using a Go version manager like `gvm`. * Always refer to the project's `go.mod` file for the most up-to-date Go version and dependency requirements. If you continue to experience issues after following these steps, please contact the development team or open an issue in the project repository. ### 2. AvalancheGo Installation AvalancheGo is the official Go implementation of an Avalanche node. Follow these steps to install it: #### a. Clone [Slide SDK](https://github.com/LandslideNetwork/landslidevm) repository: 
git clone https://github.com/LandslideNetwork/landslidevm.git && cd landslidevm
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: ``` BASEDIR=/tmp/e2e-test-landslide AVALANCHEGO_BUILD_PATH=/tmp/e2e-test-landslide/avalanchego ./scripts/install_avalanchego_release.sh ``` 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: ``` ./scripts/build_wasm.sh /tmp/e2e-test-landslide/avalanchego/plugins/pjSL9ksard4YE96omaiTkGL5H6XX2W5VEo3ZgWC9S2P6gzs9A ``` 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 [landslide-runner](https://github.com/ConsiderItDone/landslide-runner) repository: ``` cd .. && git clone https://github.com/ConsiderItDone/landslide-runner.git && cd landslide-runner ``` b. Start the Avalanche node with Landslide L1: ``` make run-wasm ``` 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: 1. 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. 2. Health Check: * The system will wait for all nodes to report as healthy. 3. Subnet Creation: * A new subnet will be created (you'll see a subnet ID). * The nodes will be added as subnet validators. 4. Blockchain Creation: * A new blockchain for Landslide (referred to as "landslidevm") will be created. * You'll see a blockchain ID generated. 5. Node Restart: * The nodes will be restarted to track the new subnet. 6. Plugin Reload: * The system will reload plugin binaries. 7. Custom Chain Creation: * The Landslide blockchain will be created on the subnet. 8. Health Check for Custom Chains: * The system will wait for the custom chain (Landslide) to report as healthy on all nodes. * You'll see log entries checking for log files on each node. 9. Final Setup: * The system will register blockchain aliases. * A final health check will be performed. 10. RPC URLs: * The system will output RPC and gRPC URLs for each node. These are crucial for interacting with your Landslide network. 11. Network Running: * You'll see a message: "Network will run until you CTRL + C to exit..." Key Information to Note: * Subnet ID: e.g., "2c1CbR7FGYdeFPB4WaeWphHZrChLH7TQ92FRW6U4mCWTnaxVsB" * Blockchain-ID: e.g., "WKQC4prgnS66BYgQw8ZBdjgYtPhKaRmDEqB5iXKG55Wj13gHu" * RPC URLs: e.g., "" * gRPC URLs: e.g., "" 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](https://chromewebstore.google.com/detail/fpkhgmpbidmiogeglndfbkegfdlnajnf) 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: 1. Keep your original terminal window running the Landslide network (`make run-wasm` command) open and active. This terminal maintains your local network. 2. 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 [Wasmd](https://github.com/CosmWasm/wasmd) is the CLI tool for interacting with CosmWasm contracts. a. Clone the Wasmd repository: ```bash git clone https://github.com/CosmWasm/wasmd.git && cd wasmd ``` b. Checkout the most stable version (replace v0.53.0 if needed): ```bash git checkout v0.53.0 ``` c. Install Wasmd: ```bash make install ``` d. Verify the installation: ```bash wasmd version ``` or ```bash ~/go/bin/wasmd version ``` ## 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: ``` ~/go/bin/wasmd keys add privatekey --recover ``` When prompted, enter the following bip39 mnemonic (seed phrase): ``` tip yard art tape orchard universe angle flame wave gadget raven coyote crater ethics able evoke luxury predict leopard delay peanut embody blast soap ``` 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): ```bash ~/go/bin/wasmd tx wasm store "./x/wasm/keeper/testdata/hackatom.wasm" \ --from privatekey \ --gas=auto --gas-adjustment=1.15 \ --node "REPLACE_WITH_YOUR_RPC_URL" \ --chain-id=landslide-test ``` **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: ``` Copycode: 0 codespace: "" data: "" events: [] gas_used: "0" gas_wanted: "0" height: "0" info: "" logs: [] raw_log: "" timestamp: "" tx: null txhash: F15A7FB824FA83D58E556224FE2D5BD59A4FC7FB8E50400D5B0649E78D873D53 ``` Great! Your smart contract has been successfully uploaded to the Landslide network. Here's what you need to know: 1. The `code: 0` indicates that the transaction was successful. 2. 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: ```bash ~/go/bin/wasmd q tx YOUR_TRANSACTION_HASH \ --node "REPLACE_WITH_YOUR_RPC_URL" \ -o json ``` After executing the command to query the transaction, you should see an output similar to this: ```json { "height": "2", "txhash": "F15A7FB824FA83D58E556224FE2D5BD59A4FC7FB8E50400D5B0649E78D873D53", "codespace": "", "code": 0, "data": "124E0A262F636F736D7761736D2E7761736D2E76312E4D736753746F7265436F6465526573706F6E73651224080112203F4CD47C39C57FE1733FB41ED176EEBD9D5C67BAF5DF8A1EEDA1455E758F8514", "raw_log": "", "logs": [], "info": "", "gas_wanted": "1463549", "gas_used": "1274349", "tx": { // ... (tx details) }, "timestamp": "2024-09-06T12:13:32Z", "events": [ // ... (other events) { "type": "store_code", "attributes": [ { "key": "code_checksum", "value": "3f4cd47c39c57fe1733fb41ed176eebd9d5c67baf5df8a1eeda1455e758f8514", "index": true }, { "key": "code_id", "value": "1", "index": true }, { "key": "msg_index", "value": "0", "index": true } ] } ] } ``` Here's what to look for in this output: 1. Check that the `code` field is 0, which indicates the transaction was successful. 2. Look for the `events` array in the output. Find the event with `"type": "store_code"`. 3. Within the `store_code` event, there are `attributes`. Find the attribute with `"key": "code_id"`. 4. The `value` associated with this `code_id` is the unique identifier assigned to your uploaded smart contract. In this example, the `code_id` is 1. 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: ```bash ~/go/bin/wasmd q wasm code-info 1 \ --node "[REPLACE_WITH_YOUR_RPC_URL]" \ -o json ``` Replace `` 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: ```json { "code_id": "1", "creator": "wasm1kng6sqkm0mjuh09cwz6u86f75lmeflj9h0fqhr", "data_hash": "3F4CD47C39C57FE1733FB41ED176EEBD9D5C67BAF5DF8A1EEDA1455E758F8514", "instantiate_permission": { "permission": "Everybody", "addresses": [] } } ``` 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. * `instantiate_permission`: Indicates who can instantiate this contract. In this case, "Everybody" means anyone can create an instance of this contract. 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 [the previous steps](broken://pages/7eySypvP9pOVVLEAvrs3) # Run Landslide on Testnet How to Run Landslide on a Testnet * [How to connect wallet to testnet](broken://pages/ehlkzFG5co2XkpHMh1Pr) * [How to connect Cosmostation](broken://pages/ehlkzFG5co2XkpHMh1Pr) * [How to connect Keplr](broken://pages/AzrqON9dVN5oxJCqfll0) * [How to connect Metamask](broken://pages/PceId1NkpTq8FR2nVVCv) * [How to get tokens from Faucet](broken://pages/yDvbTZRks7vQLa0IuBkW) * [How to deploy CosmWasm contract](broken://pages/06tNUbFr888proKsk4Rf) # How to connect Cosmostation ## Cosmostation Wallet Download and install [Cosmostation Wallet](https://chromewebstore.google.com/detail/fpkhgmpbidmiogeglndfbkegfdlnajnf) as a browser extension * Create Wallet:
* Save the mnemonic phrase afterward. To store this password, we recommend using [Dashlane](https://dashlane.com/), 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:
# WasmVM wasmd storage integrated into LandslideSDK ## Overview The LandslideSDK is designed to support the CosmWasm Virtual Machine (VM) and its methods, such as `read_db`, `write_db`, `remove_db`, and `scan_db`. As a wrapper around the CosmWasm VM, the LandslideSDK enables developers to compile, initialize, and execute CosmWasm smart contracts from their Go applications, including the `x/wasm` module. The CosmWasm VM is a lightweight and efficient Wasm runtime optimized for blockchain applications, and it provides a secure and sandboxed environment for executing smart contracts. With the support of the LandslideSDK, developers can leverage the power of the CosmWasm VM to build scalable and secure dApps on the Avalanche network. ### KVStore The LandslideSDK is designed to be fully compatible with the CosmosSDK and can support the CosmosSDK `KVStore` in a wasm module. This means that developers can use the familiar CosmosSDK `KVStore` to build their applications on Landslide without having to learn a new storage model. Additionally, wasm modules in LandslideSDK can also use the IBC light client to transfer assets between Avalanche and other connected blockchains, further expanding the interoperability of LandslideSDK-based dApps. # Storage Mangement wasmd storage integrated into LandslideSDK ## Overview The Cosmos SDK provides a powerful key-value storage abstraction layer to the developers, making it easier to store and retrieve data in a structured and organized manner. However, the existing CosmosSDK storage layer is written in Go, which is not suitable for smart contracts written in WebAssembly (Wasm). To address this limitation, the Cosmos SDK integrates with the CosmWasm VM, which provides a Rust-based WasmVM engine for executing Wasm smart contracts. The CosmWasm VM comes with its own storage management system that is specifically designed for smart contracts. The storage management system in CosmWasm is based on a simple key-value store that is optimized for the needs of smart contracts. It provides efficient and secure storage for the contract state and supports all the necessary operations for creating, reading, updating, and deleting data. With the LandslideSDK, developers can now take advantage of the CosmWasm VM storage layer in their smart contracts. They can store and retrieve data using the same key-value interface that they are familiar with in the Cosmos SDK. This makes it easier to migrate existing Cosmos SDK applications to the LandslideSDK and take advantage of its advanced features for building smart contracts. ## Storage Management `wasmd` is the WebAssembly runtime for Cosmos SDK-based blockchains. It enables developers to write smart contracts in any language that compiles to WebAssembly, such as Rust or AssemblyScript, and deploy them on a Cosmos SDK-based chain. These smart contracts can be used to implement custom logic, create new digital assets, and enable inter-blockchain communication through the Inter-Blockchain Communication (IBC) protocol. By providing a secure and efficient way to execute code on a blockchain, wasmd opens up a wide range of possibilities for decentralized applications (dApps) and use cases on the Cosmos ecosystem. # Storage Indexing Allows dApps to support all DB methods from WasmVM [WasmVM](https://github.com/CosmWasm/wasmvm/blob/main/internal/api/callbacks.go#L95-L100) The below chart illustrates the flow of data and dependencies between the LandslideCoreVM and CosmWasm, a Go module for executing WebAssembly (WASM) smart contracts on the CosmosSDK. The chart shows that the LandslideCoreVM is built on top of the CosmWasm module, which in turn depends on the WasmVM Go module for executing the smart contracts. The WasmVM module relies on the libWasmVM Rust library, which is compiled as a C library, and is ultimately used by the CosmWasmVM Rust library for executing WASM smart contracts. With these components in place, the LandslideCoreVM can support all DB methods from WasmVM, providing an efficient and flexible platform for executing smart contracts on the Avalanche network. {% @mermaid/diagram content="--- title: CosmWasm --------------- flowchart LR id1(LandslideCoreVM) --> id14("CosmWasm Go Module") --> id15("WasmVM Go Module") --> id16("libWasmVM Rust compiled as C library")--> id17("CosmWasmVM Rust using Wasmer for WASM") \--> id18("WASM smart contract") style id1 fill:#f9f,stroke:#333,stroke-width:4px" %} The below chart illustrates how a Wasm smart contract can make use of DB methods. When a Wasm smart contract calls the storage.set() method, it triggers a call to the db.write() method in the STD library. From there, the CosmWasm VM method do\_db\_write is called, which in turn calls the store.set() method in libWasmVM Rust compiled as C library. Finally, this results in a call to the database, represented by the database node in the chart. This chain of calls demonstrates how DB methods are utilized by Wasm smart contracts in the Cosmos ecosystem. {% @mermaid/diagram content="--- title: DB Method ---------------- flowchart RL id1("Wasm smart contract") -- "calls storage.set()" --> id14("STD Library") -- "calls db.write()" --> id15("CosmWasm VM method do\_db\_write")-- "calls store.set()" --> id16("libWasmVM Rust compiled as C library") -- "calls storage.set()" --> id3\[(database)] " %} # Wasmer Engine Wasmer Engine implementation in Landslide ## Overview The WasmerEngine is an important component of the CosmosSDK's support for CosmWasm, a smart contract execution environment for the Cosmos ecosystem. It is a Go implementation of the CosmWasm's WasmVM interface, which provides an API for executing WebAssembly-based smart contracts. The WasmerEngine is responsible for handling various aspects of contract execution, such as instantiating contract instances, executing contract code, and querying contract state. It is also responsible for analyzing contract code, and providing information about the contract's capabilities and resource requirements. In short, the WasmerEngine is a key component in allowing developers to build and execute smart contracts within the Cosmos ecosystem, enabling a wide range of decentralized applications to be built on top of the network. ## Methods explained As a user of the LandslideSDK, you can now utilize the CosmWasm [WasmerEngine](https://github.com/CosmWasm/wasmd/blob/e6f51498b66591d55c5e5073dad9cadaa1f9608a/x/wasm/types/wasmer_engine.go#L12) through the WasmerEngine interface. With the support of the WasmerEngine, you can easily create, analyze, instantiate, execute, query, migrate, sudo, reply, get code, pin and unpin your CosmWasm smart contracts in your LandslideSDK application. To make this possible, our developers have implemented the following methods in the WasmerEngine interface: 1. `Create`(code wasmvm.WasmCode) (`wasmvm.Checksum`, error): This method takes a WasmCode object as input and returns a checksum and an error. It is responsible for creating a new instance of a WebAssembly module from the given code. 2. `AnalyzeCode`(checksum wasmvm.Checksum) (\*wasmvmtypes.AnalysisReport, error): This method takes a checksum as input and returns an analysis report and an error. It is responsible for analyzing the given WasmCode to determine whether it is compatible with the CosmWasm module. 3. `Instantiate`: This method creates a new instance of the CosmWasm module with the specified environment variables and returns an instance object. 4. `Execute`: This method takes an instance object and an input message as input and returns the output of executing the message on the module. 5. `Query`: This method takes an instance object and an input query as input and returns the result of the query on the module. 6. `Migrate`: This method takes an instance object and a migration message as input and returns the result of migrating the module to a new version. 7. `Sudo`: This method takes an instance object and a sudo message as input and returns the result of executing the message as a privileged operation. 8. `Reply`: This method takes an instance object and an output message as input and returns the result of the reply operation. 9. `GetCode`: This method takes a checksum as input and returns the code associated with the given checksum. 10. `Pin`: This method takes a checksum as input and pins the associated code in memory. 11. `Unpin`: This method takes a checksum as input and unpins the associated code from memory. With these methods, you can enjoy seamless integration of the CosmWasm WasmerEngine in your LandslideSDK application, making it easier to deploy and manage your smart contracts. # License License terms Slide SDK is launched under a [Business Source License 1.1 (BUSL 1.1).](https://github.com/LandslideNetwork/landslidevm/blob/main/LICENSE) 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](https://github.com/oak-security/audit-reports/blob/main/Slide%20SDK/2024-09-20%20Audit%20Report%20-%20Slide%20SDK%20v1.1.pdf). # 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 [Composable DOT IBC light client](https://docs.composable.finance/products/xcvm); 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. This flowchart demonstrates how disparate applications on Cosmos, Polkadot, and Ethereum can be run natively inside an Avalanche subnet, as long as state is transferred safely between IBC light clients running on the source and target chain and transitioned through the IBC bridge.

Landslide IBC EVM Bridge

# IBC Light Client A short primer on IBC Here is a primer on the key aspects of the Inter-blockchain Communication (IBC) protocol: ## [What is IBC?](#what-is-ibc-1) * Standard protocol for blockchain networks to communicate * Allows transfer of data and value between heterogeneous chains * Developed by Cosmos but blockchain agnostic ### Components #### [Clients](#clients-1) * Light clients verify state proofs from other chains * Allow verifying transactions without running a full node #### [Connection Handshake](#connection-handshake-1) * Establishes a verified link between two chain's clients * Enables creation of channels #### [Channels](#channels-1) * Unidirectional data pipes between chains * Facilitate asynchronous, ordered packet passing #### [Relayers](#relayers-1) * Forward packets between chains along opened channels * Can be nodes or external processes ### [Transferring Value](#transferring-value-1) * Asset tracking maintains fungibility across zones * Escrow, transfer and mint/burn allows cross-chain atomicity ### Applications * Token transfers (liquidity, arbitrage) * Atomic swaps * Cross-chain smart contracts * Decentralized bridges * Oracle interoperation ### Benefits * Interoperability between blockchain networks * Expanded liquidity and composability * Trust minimization between counterparties * Censorship resistance via decoupling ## What is IBC? [The Inter-Blockchain Communication (IBC)](https://ibc.cosmos.network/main/ibc/light-clients/overview.html) protocol is a standard communication protocol that enables blockchain networks to interoperate with each other. It allows different blockchain networks to communicate and transfer value in a secure manner, creating a truly decentralized and interconnected ecosystem. For the Cosmos ecosystem, IBC is a critical component that enables Cosmos chains to connect and interact with each other, enabling new use cases and expanding the reach of the ecosystem. With IBC, Cosmos chains can seamlessly transfer assets, data, and logic across different chains, opening up new possibilities for decentralized applications and enabling greater network effects. Additionally, IBC is not limited to only Cosmos chains. With the emergence of multi-chain ecosystems such as Polkadot and Ethereum 2.0, the ability to communicate and transfer value between different chains will become increasingly important for users. IBC provides a standardized protocol for cross-chain communication, allowing for interoperability between chains regardless of their underlying technology or consensus mechanism. This opens up a wide range of possibilities for users, such as accessing decentralized applications and assets on different chains or taking advantage of unique features and capabilities of different ecosystems. ### Clients {% @mermaid/diagram content="sequenceDiagram participant Chain A participant Relayer participant Chain B ``` Note over Chain A, Chain B: Chains establish connection handshake Chain A->>Chain B: Sends header and commit proof Chain B->>Chain B: Verifies proof
Trusts Chain A headers Chain B->>Chain A: Sends header and commit proof Chain A->>Chain A: Verifies proof
Trusts Chain B headers Chain A->>Relayer: Sends IBC packet Relayer->>Chain B: Forwards IBC packet Chain B->>Chain B: Uses Chain A client
Verifies proof of packet data
Trusts validity of packet" %} ``` This shows: * Chains establish IBC connection handshake * Each chain sends header and commit proofs to the other * The receiving chain verifies the proof using the IBC client * This allows each chain to verify proofs from the other without running a full node * When sending IBC packets, the destination chain can use its light client to verify packet proofs from the source chain So the IBC clients allow trustlessly verifying proofs and packet data to facilitate cross-chain interoperation without the overhead of running full nodes. ### Connection Handshake {% @mermaid/diagram content="sequenceDiagram participant Chain A participant Chain B participant Relayer ``` Note over Chain A, Chain B: IBC Connection Handshake Chain A->>Chain A: Client creates connection handshake packet Chain A-->>Relayer: Relays handshake packet to Chain B Relayer->>Chain B: Forwards handshake packet Chain B->>Chain B: Verifies packet signatures and contents Chain B->>Chain B: Stores connection + Chain A client data Chain B-->>Chain A: Returns handshake packet Relayer->>Chain A: Relays handshake response Chain A->>Chain A: Verifies handshake response Chain A-->>Chain B: Confirmation to complete handshake" %} ``` Explanation: * The connection handshake allows two chains to establish a secure, verified link between their respective IBC clients. * Chain A's client creates a connection handshake packet to start the process. This contains data like Chain A's client ID, desired connection version and parameters, proofs, and signatures. * Chain A relays this packet to Chain B via an IBC relayer. * Chain B's client verifies the handshake packet - the signatures match Chain A's client, the proof can be validated, and the parameters are acceptable. * Chain B stores details like Chain A's client ID and consensus state to retain connection information. * Chain B constructs its own handshake packet to respond to Chain A, containing symmetric proofs and details. * Chain B relays its handshake response packet back to Chain A. * Chain A verifies Chain B's handshake response, stores the connection info, and sends a confirmation to complete the handshake. * This establishes an authenticated, verified link between both clients. * Now the chains can construct channels over this connection to pass application data. So the two-way handshake allows the clients to verify each other's proofs and signatures to establish trust required for further cross-chain interactions like creating channels. ### **Channels** {% @mermaid/diagram content="sequenceDiagram participant Osmosis participant IBC Module participant Relayer participant Landslide Osmosis ->> IBC Module: Create packet data IBC Module ->> Relayer: Send packet to Relayer Relayer ->> IBC Module: Relay packet to destination chain IBC Module ->> Landslide: Receive packet on AVAX subnet Landslide ->> IBC Module: Acknowledge packet receipt IBC Module ->> Relayer: Send acknowledgement to relayer Relayer ->> IBC Module: Relay acknowledgement to source chain IBC Module ->> Osmosis: Deliver acknowledgement to dApp " %} Explanation: * IBC channels are unidirectional data pipelines allowing asynchronous cross-chain communication. * Chain A endpoint module sends an IBC data packet destined for Chain B. * Relayer picks up and forwards the packet to Chain B. * Chain B receives the packet on its endpoint module and processes it. * Chain B sends back an acknowledgement to Chain A to confirm receipt. * Relayer forwards this acknowledgement back to Chain A. * Chain A receives confirmation that the packet was processed on Chain B. * Channels have ordering guarantees so packets are processed in order. * Multiple channels can exist between chains for different applications. * Channels are separate data pipes allowing modular communication between chains. So in summary, IBC channels provide ordered, unidirectional data flow between chains facilitated by relayers. This allows modular cross-chain communication. ### Relayers {% @mermaid/diagram content="sequenceDiagram participant Chain A participant Relayer participant Chain B ``` Chain A->>Relayer: Send packet Relayer->>Relayer: Stores packet Relayer->>Chain B: Forwards packet Chain B-->>Relayer: Sends acknowledgement Relayer->>Chain A: Relays acknowledgement" %} ``` Explanation: * IBC relayers forward packets between blockchains along opened IBC channels. * Chain A sends an IBC packet destined to Chain B to a relayer. * The relayer stores the packet temporarily until it can be forwarded. * The relayer then forwards the packet to Chain B along the channel. * Chain B sends back an acknowledgement that is picked up by the relayer. * The relayer completes the loop by relaying the acknowledgement back to Chain A. * Relayers can be blockchain nodes or external validator processes dedicated to packet relaying. * There can be multiple relayers to prevent single points of failure. So in summary, relayers provide the key role of forwarding IBC packets and acknowledgements between blockchains to facilitate cross-chain communication. ## Transferring Value {% @mermaid/diagram content="sequenceDiagram participant Chain A participant Chain B ``` Note over Chain A, Chain B: IBC Value Transfer Chain A->>Chain A: Escrow tokens in IBC module Chain A-->>Chain B: Relay token transfer packet Chain B->>Chain B: Verify packet and mint tokens Chain B-->>Chain A: Confirm successful mint Chain A->>Chain A: Release escrow by burning tokens" %} ``` Explanation: * IBC enables cross-chain atomic token transfers between chains. * On Chain A, the sender escrows tokens into the IBC module. This locks the tokens. * Chain A relays a packet to Chain B to transfer the escrowed tokens. * Chain B verifies the packet data then mints new tokens to the receiver. * Chain B confirms successful minting back to Chain A. * Finally, Chain A releases the tokens from escrow by burning them. * The escrow mechanism ensures the tokens are not double-spent across zones. * Minting/burning allows transfer of fungible value while maintaining total supply. So IBC enables atomic cross-chain token transfers while tracking assets across zones to maintain fungibility. # 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](https://ibcprotocol.org/) 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 [here](https://ibc.cosmos.network/). ### Table Of Contents * [Basic Usage - Relaying Across Chains](#basic-usage-relaying-packets-across-chains) * [Create Path Across Chains](https://github.com/cosmos/relayer/blob/main/docs/create-path-across-chain.md) * [Advanced Usage](https://github.com/cosmos/relayer/blob/main/docs/advanced_usage.md) * [Troubleshooting](https://github.com/cosmos/relayer/blob/main/docs/troubleshooting.md) * [Features](https://github.com/cosmos/relayer/blob/main/docs/features.md) * [Relayer Terminology](https://github.com/cosmos/relayer/blob/main/docs/terminology.md) * [Recommended Pruning Settings](https://github.com/cosmos/relayer/blob/main/docs/node_pruning.md) *** ### 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. *** 1. **Clone, checkout and install the latest release (**[**releases page**](https://github.com/ConsiderItDone/relayer/releases)**).** [*Go*](https://go.dev/doc/install) *needs to be installed and a proper Go environment needs to be configured* ```shell $ git clone https://github.com/ConsiderItDone/relayer.git $ cd relayer && git checkout main $ make install ``` 2. **Initialize the relayer's configuration directory/file.** ```shell $ rly config init ``` **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. ```shell $ rly config init --memo "My custom memo" ``` Custom memos will have `rly(VERSION)` appended. For example, a memo of `My custom memo` running on relayer version `v2.5.2` would result in a transaction memo of `My custom memo | rly(v2.5.2)`. The `--memo` flag is also available for other `rly` commands also that involve sending transactions such as `rly tx link` and `rly start`. It can be passed there to override the `config.yaml` value if desired. To omit the memo entirely, including the default value of `rly(VERSION)`, use `-` for the memo. 3. **Configure the chains you want to relay between.** In our example, we will configure the relayer to operate on the canonical path between the Cosmos Hub and Osmosis.\ The `rly chains add` command fetches chain meta-data from the [chain-registry](https://github.com/cosmos/chain-registry) and adds it to your config file. ```shell $ rly chains add cosmoshub slide ``` Adding chains from the chain-registry randomly selects an RPC address from the registry entry. If you are running your own node, manually go into the config and adjust the `rpc-addr` setting. > NOTE: `rly chains add` will check the liveliness of the available RPC endpoints for that chain in the chain-registry. It is possible that the command will fail if none of these RPC endpoints are available. In this case, you will want to manually add the chain config. To add the chain config files manually, example config files have been included [here](https://github.com/cosmos/relayer/tree/main/docs/example-configs/) ```shell $ rly chains add --url https://raw.githubusercontent.com/cosmos/relayer/main/docs/example-configs/cosmoshub-4.json cosmoshub ``` Slide config example ```yaml global: api-listen-addr: :5183 timeout: 10s memo: "" light-cache-size: 20 log-level: "" ics20-memo-limit: 0 max-receiver-size: 0 chains: slide: type: avalanche value: rpc-addr: http://127.0.0.1:9650/ext/bc/2qdf414xEdWsmjSK1Q59Gautq6fERXbXm4jJnJkZ6MfFBB6PaH/rpc base-rpc-addr: http://127.0.0.1:9650 subnet-id: 2c1CbR7FGYdeFPB4WaeWphHZrChLH7TQ92FRW6U4mCWTnaxVsB blockchain-id: 2qdf414xEdWsmjSK1Q59Gautq6fERXbXm4jJnJkZ6MfFBB6PaH chain-id: "slide" network-id: 1337 timeout: 10s contract-address: 0x0300000000000000000000000000000000000002 transferrer-address: 0x17aB05351fC94a1a67Bf3f56DdbB941aE6c63E25 key-directory: ~.relayer/keys/avalanche-slide key: testkey keyring-backend: test extra-codecs: [] min-loop-duration: 0s ibcgo: type: cosmos value: key-directory: ~/.relayer/keys/ibcgo key: testkey chain-id: ibcgo rpc-addr: http://localhost:26657 account-prefix: cosmos keyring-backend: test dynamic-gas-price: false gas-adjustment: 1.5 gas-prices: 0.025stake min-gas-amount: 0 max-gas-amount: 0 debug: true timeout: 10s block-timeout: "" output-format: json sign-mode: direct extra-codecs: [] coin-type: null signing-algorithm: "" broadcast-mode: batch min-loop-duration: 0s extension-options: [] feegrants: null paths: demo: src: chain-id: slide dst: chain-id: ibcgo src-channel-filter: rule: "" channel-list: [] demo2: src: chain-id: ibcgo dst: chain-id: slide src-channel-filter: rule: "" channel-list: [] ``` 4. **Import OR create new keys for the relayer to use when signing and relaying transactions.** > `key-name` is an identifier of your choosing. If you need to generate a new private key you can use the `add` subcommand. ```shell $ rly keys add ibcgo [key-name] $ rly keys add slide [key-name] ``` If you already have a private key and want to restore it from your mnemonic you can use the `restore` subcommand. ```shell $ rly keys restore ibcgo [key-name] "mnemonic words here" $ rly keys restore slide [key-name] "mnemonic words here" ``` 5. **Use the `key-name` created above.** > This step is necessary if you chose a `key-name` other than "default" ```shell $ rly keys use ibcgo [key-name] $ rly keys use slide [key-name] ``` 6. **Ensure the keys associated with the configured chains are funded.** > Your configured addresses will need to contain some of the respective native tokens for paying relayer fees. > >
You can query the balance of each configured key by running: ```shell $ rly q balance ibcgo $ rly q balance slide ``` 7. **Configure path meta-data in config file.**\ We have the chain meta-data configured, now we need path meta-data. For more info on `path` terminology visit [here](https://github.com/cosmos/relayer/blob/main/docs/troubleshooting.md). > NOTE: Thinking of chains in the config as "source" and "destination" can be confusing. Be aware that most path are bi-directional. > >
`rly paths fetch` will check for IBC path meta data from the [chain-registry](https://github.com/cosmos/chain-registry/tree/master/_IBC) and add these paths to your config file. ```shell $ rly paths fetch ``` > **NOTE:** Don't see the path metadata for paths you want to relay on? Please open a PR to add this metadata to the GitHub repo! 8. **Configure the channel filter.** By default, the relayer will relay packets over all channels on a given connection.\ Each path has a `src-channel-filter` which you can utilize to specify which channels you would like to relay on.\ The `rule` can be one of three values: * `allowlist` which tells the relayer to relay on *ONLY* the channels in `channel-list` * `denylist` which tells the relayer to relay on all channels *BESIDES* the channels in `channel-list` * empty value, which is the default setting, and tells the relayer to relay on all channels
Since we are only worried about the canonical channel between the Cosmos Hub and Landslide our filter settings would look like the following.\ Example: ```yaml hubslide: src: chain-id: ibcgo client-id: 07-tendermint-259 connection-id: connection-257 dst: chain-id: slide client-id: 14-avalanche-1 connection-id: connection-1 src-channel-filter: rule: allowlist channel-list: [channel-141] ``` > Because two channels between chains are tightly coupled, there is no need to specify the dst channels. If you only know the "dst" channel-ID you can query the "src" channel-ID by running: `rly q channel | jq '.channel.counterparty.channel_id'` 9. **Finally, we start the relayer on the desired path.** The relayer will periodically update the clients and listen for IBC messages to relay. ```shell $ rly paths list $ rly start [path] # Optionally you can omit the `path` argument to start all configured paths $ rly start ``` > When running multiple instances of `rly start`, you will need to use the `--debug-addr` flag and provide an address:port. You can also pass an empty string `''` to turn off this feature or pass `localhost:0` to randomly select a port. \[[TROUBLESHOOTING](https://github.com/cosmos/relayer/blob/main/docs/troubleshooting.md)] *** [Create Path Across Chains -->](https://github.com/cosmos/relayer/blob/main/docs/create-path-across-chain.md) # Chain integrators guide * [Lower than version 0.50](broken://pages/mbYhttlrr5bJRtIng8Og) * [Higher than version 0.50](broken://pages/D0HKr5anJDkeBC1BMpnA) # 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. ```go import ( // other imports... ava "github.com/cosmos/ibc-go/v8/modules/light-clients/14-avalanche" ) ``` ### 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: ```go app.ModuleManager = module.NewManager( // other modules... ava.AppModuleBasic{}, ) ``` *** 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. ```go import ( // other imports... ava "github.com/cosmos/ibc-go/v8/modules/light-clients/14-avalanche" ) ``` ### 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: ```go app.ModuleManager = module.NewManager( // other modules... ava.AppModuleBasic{}, ) ``` ### 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. ```go func RegisterIBC(registry cdctypes.InterfaceRegistry) map[string]appmodule.AppModule { modules := map[string]appmodule.AppModule{ // other modules... ava.ModuleName: ava.AppModuleBasic{}, } ... } ``` *** 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 [official documentation.](https://ibc.cosmos.network/) 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). {% @mermaid/diagram content="sequenceDiagram ``` participant Chain A (Osmosis) participant IBC Relayer participant Chain B (Landslide) Chain A (Osmosis)->>Chain A (Osmosis): Process MsgTransfer Message Note left of Chain A (Osmosis): *Create IBC Packet
*Generate Packet
commitment (hash)
* Store Packet commitment
in KV Store by key
(port, channel, sequence)
* Emit Packet Event ``` Chain A (Osmosis)->>IBC Relayer: Handle Packet Event IBC Relayer->>Chain A (Osmosis): Query Packet Commitment Proof Chain A (Osmosis)-->>IBC Relayer: Returns Proof Note over IBC Relayer: Create MsgRecvPacket
with packet and proofs IBC Relayer->>Chain B (Landslide): Relay Message Chain B (Landslide)-->>IBC Relayer: Get WriteAck result IBC Relayer->>Chain B (Landslide): Query Acknowledgement Proof Chain B (Landslide)-->>IBC Relayer: Returns Proof Note over IBC Relayer: Create MsgAcknowledgement
with packet, ack, and proofs IBC Relayer->>Chain A (Osmosis): Send Ack message " %} A more detailed view {% @mermaid/diagram content="sequenceDiagram participant Chain A participant Relayer participant Chain B opt Setup Clients Relayer->>Chain A: Create Client Chain A-->>Relayer: Returns ClientID Relayer->>Chain B: Create Client Chain B-->>Relayer: Returns ClientID end opt Create Connections Relayer->>Chain A: Calls ConnectionOpenInit Chain A-->>Relayer: Returns ConnectionID opt Query Proofs Relayer->>Chain A: Query proof for the client state at latest height Chain A-->>Relayer: Returns ProofClient and ProofHeight by ClientID Relayer->>Chain A: Query proof for the consensus state at ProofHeight Chain A-->>Relayer: Returns ProofConsensus Relayer->>Chain A: Query proof for the connection at ProofHeight Chain A-->>Relayer: Returns ProofConnection end note right of Relayer: with ProofClient, ProofConsensus, ProofConnection Relayer->>Chain B: Calls ConnectionOpenTry Chain B-->>Relayer: Returns ConnectionID opt Query Proofs Relayer->>Chain B: Query proof for the client state at latest height Chain B-->>Relayer: Returns ProofClient and ProofHeight by ClientID Relayer->>Chain B: Query proof for the consensus state at ProofHeight Chain B-->>Relayer: Returns ProofConsensus Relayer->>Chain B: Query proof for the connection at ProofHeight Chain B-->>Relayer: Returns ProofConnection end note left of Relayer: with ProofClient, ProofConsensus, ProofConnection Relayer->>Chain A: Calls ConnectionOpenAck opt Query Proofs Relayer->>Chain B: Query proof for the connection at latest height Chain B-->>Relayer: Returns ProofConnection and ProofHeight end Relayer->>Chain B: Calls ConnectionOpenConfirm Relayer->>Chain A: Update Client end opt Setup Channels Relayer->>Chain A: Calls ChannelOpenInit Chain A-->>Relayer: Returns ChannelID opt Query Proofs Relayer->>Chain A: Query channel proof Chain A-->>Relayer: Returns proof and height end note right of Relayer: with ChannelProof Relayer->>Chain B: Calls ChannelOpenTry Chain B-->>Relayer: Returns ChannelID opt Query Proofs Relayer->>Chain B: Query channel proof Chain B-->>Relayer: Returns proof and height end note left of Relayer: with ChannelProof Relayer->>Chain A: Calls ChannelOpenAck opt Query Proofs Relayer->>Chain A: Query channel proof Chain A-->>Relayer: Returns proof and height end note right of Relayer: with ChannelProof Relayer->>Chain B: Calls ChannelOpenConfirm end " %} # IBC Go How IBC-go interacts with the Avalanche IBC light client See original [documentation here.](https://github.com/ConsiderItDone/ibc-go/tree/main) 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: 1. 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. 2. Create an instance of the IBC light client for Landslide. You can use the Landslide-specific implementation of the IBC light client to connect to the AVAX subnet and receive and send packets over the IBC protocol. 3. Implement the necessary functions to handle incoming packets from other chains. These functions should validate and verify the packets and then trigger the appropriate action within the Landslide network based on the contents of the packet. 4. Implement the necessary functions to send packets to other chains. These functions should prepare the packet data and send it through the IBC light client to the appropriate destination chain. 5. Set up the relayer to relay packets between different chains. The relayer is responsible for forwarding packets between different chains and ensuring that the packets are received in the correct order. Here are some specific functions and interfaces in the IBC-go library that can be used to interact with the Avalanche IBC light client: * `IBCClient`: This interface defines the basic functionality for an IBC client, including sending and receiving packets, creating and updating connections, and handling events. * `ConnState`: This interface defines the possible states of a connection and provides functions for updating the connection state. * `ChannelState`: This interface defines the possible states of a channel and provides functions for updating the channel state. * `Packet`: This struct represents a packet of data that is sent over the IBC protocol. It contains information such as the source and destination chains, sequence number, and packet data. * `IBCReceiver`: This interface defines the necessary functions for handling incoming packets from other chains. These functions should validate and verify the packet and trigger the appropriate action within the Landslide network. * `IBCSender`: This interface defines the necessary functions for sending packets to other chains. These functions should prepare the packet data and send it through the IBC light client to the appropriate destination chain. By using these functions and interfaces from the IBC-go library, the Avalanche IBC light client for Landslide implements the necessary functionality to send and receive packets over the IBC protocol. # 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. {% @mermaid/diagram content="sequenceDiagram participant Relayer participant L1 Node 1 participant L1 Validator 1 participant L1 Node N participant L1 Validator N opt Get Proof from Node 1 Relayer -->> L1 Node 1: Query Proof by Key L1 Node 1->>L1 Node 1: Get payload by Key alt Signature is in cache L1 Node 1->>L1 Node 1: Get signature from internal cache else Signature is not in cache note right of L1 Node 1: Call through VM Context L1 Node 1->>L1 Validator 1: Sign payload L1 Validator 1-->>L1 Node 1: Returns signature end L1 Node 1->>Relayer: Returns signature end opt Get Proof from Node N Relayer-->>L1 Node N: Query Proof by Key L1 Node N->>L1 Node N: Get payload by Key note right of L1 Node N: Call through VM Context L1 Node N->>L1 Validator N: Sign payload L1 Validator N-->>L1 Node N: Returns signature L1 Node N->>Relayer: Returns signature end Relayer->>Relayer: Compose signatures \nfrom Node1, Node2... NodeN" %} # RPC This file defines the JSON-RPC spec of CometBFT vs Landslide SDK. This is meant to be implemented by all clients. | **Routes** | [**CometBFT**](https://github.com/cometbft/cometbft) | [**Landslide SDK**](https://github.com/LandslideNetwork/slide-sdk) | | --------------------------------------- | :--------------------------------------------------: | :----------------------------------------------------------------: | | [Health](#health) | ✅ | ✅ | | [Status](#status) | ✅ | ✅ | | NetInfo | ✅ | ❌ | | [Blockchain](#blockchain) | ✅ | ✅ | | [Block](#block) | ✅ | ✅ | | [BlockByHash](#blockbyhash) | ✅ | ✅ | | [BlockResults](#blockresults) | ✅ | ✅ | | [Commit](#commit) | ✅ | ✅ | | [Validators](#validators) | ✅ | ✅ | | [Genesis](#genesis) | ✅ | ✅ | | [GenesisChunked](#genesischunked) | ✅ | ✅ | | [ConsensusParams](#consensusparams) | ✅ | ✅ | | [UnconfirmedTxs](#unconfirmedtxs) | ✅ | ✅ | | [NumUnconfirmedTxs](#numunconfirmedtxs) | ✅ | ✅ | | [Tx](#tx) | ✅ | ✅ | | [TxSearch](#txsearch) | ❌ | ✅ | | [BlockSearch](#blocksearch) | ❌ | ✅ | | [BroadCastTxSync](#broadcasttxsync) | ✅ | ✅ | | [BroadCastTxAsync](#broadcasttxasync) | ✅ | ✅ | | [ABCIInfo](#abciinfo) | ✅ | ✅ | | [ABCIQuery](#abciquery) | ✅ | ✅ | | BroadcastEvidence | ✅ | ❌ | ## Info Routes *** ### Health Node heartbeat #### **Parameters** None #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"health\"}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": {} } ``` ### Status Get CometBFT status including node info, pubkey, latest block hash, app hash, block height and time. #### **Parameters** None #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"status\"}" ``` #### **Response** 
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "node_info": {
      "protocol_version": {
        "p2p": "8",
        "block": "11",
        "app": "0"
      },
      "id": "cb912d5ed8d2cdc31ba42aad6ec37bd640fdce62",
      "listen_addr": "/ext/bc/2rUgWwRguT2uAzPFTZSz2XrJiVZhif5Yv6NKGupFj89CJTEfQu/rpc",
      "network": "landslide-test",
      "version": "0.38.9",
      "channels": "",
      "moniker": "cb912d5ed8d2cdc31ba42aad6ec37bd640fdce62",
      "other": {
        "tx_index": "",
        "rpc_address": ""
      }
    },
    "sync_info": {
      "latest_block_hash": "775DD3BBA679E6B6467CCCA2E67E7498BE5F2F60219EEEFE34EF40C28D5EA5CC",
      "latest_app_hash": "A3C8A1E113E269D723F33A0483ADCEB3EE25D2EC23690BB2E4574367F0EF6417",
      "latest_block_height": "39",
      "latest_block_time": "2024-09-20T14:37:47.720065252Z",
      "earliest_block_hash": "44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC",
      "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
      "earliest_block_height": "1",
      "earliest_block_time": "2024-06-11T19:47:02.588140664Z",
      "catching_up": false
    },
    "validator_info": {
      "address": "29CFC6376255A78451EEB4B129ED8EACFFA2FEEF",
      "pub_key": {
        "type": "tendermint/PubKeySecp256k1",
        "value": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
      },
      "voting_power": "0"
    }
  }
}
### Blockchain Get block headers. Returned in descending order. May be limited in quantity. #### **Parameters** * `minHeight (integer)`: The lowest block to be returned in the response * `maxHeight (integer)`: The highest block to be returned in the response #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"blockchain\",\"params\":{\"minHeight\":\"1\", \"maxHeight\":\"2\"}}" ``` #### **Response** 
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "last_height": "67",
    "block_metas": [
      {
        "block_id": {
          "hash": "565633D9EF2063810FEDC5716CFFDED1879F334D051BEC8DCE9BBBD99F9DA478",
          "parts": {
            "total": 1,
            "hash": "974BADDC7392A1DE56C3C586730C37371AF76B2F95BF155AF730B71C757A5ED6"
          }
        },
        "block_size": "913",
        "header": {
          "version": {
            "block": "11"
          },
          "chain_id": "landslide-test",
          "height": "2",
          "time": "2024-08-29T13:03:49.002664646Z",
          "last_block_id": {
            "hash": "44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC",
            "parts": {
              "total": 1,
              "hash": "4001074D14084CC16C61F106675C45DB62732F0A8B5CFBEBD866AB283122C72F"
            }
          },
          "last_commit_hash": "0165478ECE0A31DF2A5F8CF42DA468B42FEB1929404D28E05F587C82B8B69249",
          "data_hash": "1969C3306F08030618232225F8B445BD32046E7C297EE2DDA10DC2747EB3F7AC",
          "validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981",
          "next_validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981",
          "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F",
          "app_hash": "63C7D00C46CAA24D0F8745F90CBBC4F573CB77FD1D5F9B80A50AFBEFD83386CB",
          "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "proposer_address": "0000000000000000000000000000000000000000"
        },
        "num_txs": "1"
      },
      {
        "block_id": {
          "hash": "44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC",
          "parts": {
            "total": 1,
            "hash": "4001074D14084CC16C61F106675C45DB62732F0A8B5CFBEBD866AB283122C72F"
          }
        },
        "block_size": "347",
        "header": {
          "version": {
            "block": "11"
          },
          "chain_id": "landslide-test",
          "height": "1",
          "time": "2024-06-11T19:47:02.588140664Z",
          "last_block_id": {
            "hash": "",
            "parts": {
              "total": 0,
              "hash": ""
            }
          },
          "last_commit_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981",
          "next_validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981",
          "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F",
          "app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
          "proposer_address": "0000000000000000000000000000000000000000"
        },
        "num_txs": "0"
      }
    ]
  }
}
### 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** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block\",\"params\":{\"height\":\"1\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "block_id": { "hash": "44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC", "parts": { "total": 1, "hash": "4001074D14084CC16C61F106675C45DB62732F0A8B5CFBEBD866AB283122C72F" } }, "block": { "header": { "version": { "block": "11" }, "chain_id": "landslide-test", "height": "1", "time": "2024-06-11T19:47:02.588140664Z", "last_block_id": { "hash": "", "parts": { "total": 0, "hash": "" } }, "last_commit_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981", "next_validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981", "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F", "app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "proposer_address": "0000000000000000000000000000000000000000" }, "data": { "txs": [] }, "evidence": { "evidence": [] }, "last_commit": { "height": "0", "round": 0, "block_id": { "hash": "", "parts": { "total": 0, "hash": "" } }, "signatures": [] } } } } ``` ### BlockByHash #### **Parameters** * `hash (string)`: Hash of the block to query for. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block_by_hash\",\"params\":{\"hash\":\"44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "block_id": { "hash": "", "parts": { "total": 0, "hash": "" } }, "block": null } } ``` ### 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** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block_results\",\"params\":{\"height\":\"1\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": null } ``` ### 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** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"commit\",\"params\":{\"height\":\"1\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "signed_header": { "header": { "version": { "block": "11" }, "chain_id": "landslide-test", "height": "1", "time": "2024-06-11T19:47:02.588140664Z", "last_block_id": { "hash": "", "parts": { "total": 0, "hash": "" } }, "last_commit_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981", "next_validators_hash": "B797D57B0083DA5EE04C7966CB8F3FA7F75B5767B1F5FCABABB53B0765738981", "consensus_hash": "048091BC7DDC283F77BFBF91D73C44DA58C3DF8A9CBC867405D8B7F3DAADA22F", "app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "proposer_address": "0000000000000000000000000000000000000000" }, "commit": { "height": "1", "round": 0, "block_id": { "hash": "44F0AC57A9A6FA4647A5F6CEA962D081DA9AD1CC8C871BE9725716F34CA08FAC", "parts": { "total": 1, "hash": "4001074D14084CC16C61F106675C45DB62732F0A8B5CFBEBD866AB283122C72F" } }, "signatures": [ { "block_id_flag": 3, "validator_address": "CB3E8C3DF2B14CBB3538043B49C39DFBEF4B0F80", "timestamp": "2024-08-29T13:03:49.002664646Z", "signature": "SWJPZyHs3GpGxGf3UG1iBJAoc9Sd2b6vBKU1n16iRPk22ZcFEMSdCwoCq9uh7t2/Lvk66byOW0P05/2Q0+2aRA==" } ] } }, "canonical": true } } ``` ### 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** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"validators\",\"params\":{\"height\":\"1\", \"page\":\"1\", \"per_page\":\"20\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "block_height": "1", "validators": [ { "address": "CB3E8C3DF2B14CBB3538043B49C39DFBEF4B0F80", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "yD+2h7vYYmrU1AA+7sMTv1UjKE8T7hVhgMqr9Ez/HA8=" }, "voting_power": "250", "proposer_priority": "0" } ], "count": "1", "total": "1" } } ``` ### Genesis Get Genesis of the chain. If the response is large, this operation will return an error: use `genesis_chunked` instead. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"genesis\"}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "genesis": { "genesis_time": "2024-06-11T19:47:02.588140664Z", "chain_id": "landslide-test", "initial_height": "1", "consensus_params": { "block": { "max_bytes": "22020096", "max_gas": "-1" }, "evidence": { "max_age_num_blocks": "100000", "max_age_duration": "172800000000000", "max_bytes": "1048576" }, "validator": { "pub_key_types": [ "ed25519" ] }, "version": { "app": "0" }, "abci": { "vote_extensions_enable_height": "0" } }, "app_hash": "", "app_state": { "07-tendermint": null, "auth": { "params": { "max_memo_characters": "256", "tx_sig_limit": "7", "tx_size_cost_per_byte": "10", "sig_verify_cost_ed25519": "590", "sig_verify_cost_secp256k1": "1000" }, "accounts": [ { "@type": "/cosmos.auth.v1beta1.BaseAccount", "address": "wasm1vcw0he5l9mu54zawg3h440p83ex70ccmme53ac", "pub_key": null, "account_number": "0", "sequence": "0" }, { "@type": "/cosmos.auth.v1beta1.BaseAccount", "address": "wasm1kng6sqkm0mjuh09cwz6u86f75lmeflj9h0fqhr", "pub_key": null, "account_number": "1", "sequence": "0" }, { "@type": "/cosmos.auth.v1beta1.BaseAccount", "address": "wasm1c4w4jxdkvj3ygdycdkjy98jve6w0d7257eqfx9", "pub_key": null, "account_number": "2", "sequence": "0" } ] }, "authz": { "authorization": [] }, "bank": { "params": { "send_enabled": [], "default_send_enabled": true }, "balances": [ { "address": "wasm1vcw0he5l9mu54zawg3h440p83ex70ccmme53ac", "coins": [ { "denom": "stake", "amount": "1000000000" } ] }, { "address": "wasm1kng6sqkm0mjuh09cwz6u86f75lmeflj9h0fqhr", "coins": [ { "denom": "stake", "amount": "1000000000" } ] } ], "supply": [ { "denom": "stake", "amount": "2000000000" } ], "denom_metadata": [], "send_enabled": [] }, "capability": { "index": "1", "owners": [] }, "circuit": { "account_permissions": [], "disabled_type_urls": [] }, "consensus": null, "crisis": { "constant_fee": { "denom": "stake", "amount": "1000" } }, "distribution": { "params": { "community_tax": "0.020000000000000000", "base_proposer_reward": "0.000000000000000000", "bonus_proposer_reward": "0.000000000000000000", "withdraw_addr_enabled": true }, "fee_pool": { "community_pool": [] }, "delegator_withdraw_infos": [], "previous_proposer": "", "outstanding_rewards": [], "validator_accumulated_commissions": [], "validator_historical_rewards": [], "validator_current_rewards": [], "delegator_starting_infos": [], "validator_slash_events": [] }, "evidence": { "evidence": [] }, "feegrant": { "allowances": [] }, "feeibc": { "identified_fees": [], "fee_enabled_channels": [], "registered_payees": [], "registered_counterparty_payees": [], "forward_relayers": [] }, "genutil": { "gen_txs": [ { "body": { "messages": [ { "@type": "/cosmos.staking.v1beta1.MsgCreateValidator", "description": { "moniker": "node1", "identity": "", "website": "", "security_contact": "", "details": "" }, "commission": { "rate": "0.100000000000000000", "max_rate": "0.200000000000000000", "max_change_rate": "0.010000000000000000" }, "min_self_delegation": "1", "delegator_address": "", "validator_address": "wasmvaloper1vcw0he5l9mu54zawg3h440p83ex70ccmw9pdnz", "pubkey": { "@type": "/cosmos.crypto.ed25519.PubKey", "key": "yD+2h7vYYmrU1AA+7sMTv1UjKE8T7hVhgMqr9Ez/HA8=" }, "value": { "denom": "stake", "amount": "250000000" } } ], "memo": "195cbe2ac4a3f2e051d6cc58096a55172d930d3e@192.168.50.251:26656", "timeout_height": "0", "extension_options": [], "non_critical_extension_options": [] }, "auth_info": { "signer_infos": [ { "public_key": { "@type": "/cosmos.crypto.secp256k1.PubKey", "key": "AhFggXG8fW08HKDacLjhUV28l6qQQz67ZAuoHGDlwCx4" }, "mode_info": { "single": { "mode": "SIGN_MODE_DIRECT" } }, "sequence": "0" } ], "fee": { "amount": [], "gas_limit": "200000", "payer": "", "granter": "" }, "tip": null }, "signatures": [ "elAiSB50eI2jd8Oi/GRePGKiaA4YQ5v2mUmZoTyl1fYPuFG/PDvrQfO8puQjgQ7tAshWVUxWIQt9VDgRhxOrww==" ] } ] }, "gov": { "starting_proposal_id": "1", "deposits": [], "votes": [], "proposals": [], "deposit_params": null, "voting_params": null, "tally_params": null, "params": { "min_deposit": [ { "denom": "stake", "amount": "10000000" } ], "max_deposit_period": "172800s", "voting_period": "172800s", "quorum": "0.334000000000000000", "threshold": "0.500000000000000000", "veto_threshold": "0.334000000000000000", "min_initial_deposit_ratio": "0.000000000000000000", "proposal_cancel_ratio": "0.500000000000000000", "proposal_cancel_dest": "", "expedited_voting_period": "86400s", "expedited_threshold": "0.667000000000000000", "expedited_min_deposit": [ { "denom": "stake", "amount": "50000000" } ], "burn_vote_quorum": false, "burn_proposal_deposit_prevote": false, "burn_vote_veto": true, "min_deposit_ratio": "0.010000000000000000" }, "constitution": "" }, "group": { "group_seq": "0", "groups": [], "group_members": [], "group_policy_seq": "0", "group_policies": [], "proposal_seq": "0", "proposals": [], "votes": [] }, "ibc": { "client_genesis": { "clients": [], "clients_consensus": [], "clients_metadata": [], "params": { "allowed_clients": [ "06-solomachine", "07-tendermint", "09-localhost" ] }, "create_localhost": false, "next_client_sequence": "0" }, "connection_genesis": { "connections": [], "client_connection_paths": [], "next_connection_sequence": "0", "params": { "max_expected_time_per_block": "30000000000" } }, "channel_genesis": { "channels": [], "acknowledgements": [], "commitments": [], "receipts": [], "send_sequences": [], "recv_sequences": [], "ack_sequences": [], "next_channel_sequence": "0" } }, "interchainaccounts": { "controller_genesis_state": { "active_channels": [], "interchain_accounts": [], "ports": [], "params": { "controller_enabled": true } }, "host_genesis_state": { "active_channels": [], "interchain_accounts": [], "port": "icahost", "params": { "host_enabled": true, "allow_messages": [ "*" ] } } }, "mint": { "minter": { "inflation": "0.130000000000000000", "annual_provisions": "0.000000000000000000" }, "params": { "mint_denom": "stake", "inflation_rate_change": "0.130000000000000000", "inflation_max": "0.200000000000000000", "inflation_min": "0.070000000000000000", "goal_bonded": "0.670000000000000000", "blocks_per_year": "6311520" } }, "nft": { "classes": [], "entries": [] }, "params": null, "slashing": { "params": { "signed_blocks_window": "100", "min_signed_per_window": "0.500000000000000000", "downtime_jail_duration": "600s", "slash_fraction_double_sign": "0.050000000000000000", "slash_fraction_downtime": "0.010000000000000000" }, "signing_infos": [], "missed_blocks": [] }, "staking": { "params": { "unbonding_time": "1814400s", "max_validators": 100, "max_entries": 7, "historical_entries": 10000, "bond_denom": "stake", "min_commission_rate": "0.000000000000000000" }, "last_total_power": "0", "last_validator_powers": [], "validators": [], "delegations": [], "unbonding_delegations": [], "redelegations": [], "exported": false }, "transfer": { "port_id": "transfer", "denom_traces": [], "params": { "send_enabled": true, "receive_enabled": true }, "total_escrowed": [] }, "upgrade": {}, "vesting": {}, "wasm": { "params": { "code_upload_access": { "permission": "Everybody", "addresses": [] }, "instantiate_default_permission": "Everybody" }, "codes": [], "contracts": [], "sequences": [] } } } } } ``` ### GenesisChunked Get the genesis document in a chunks to support easily transferring larger documents. #### **Parameters** * `chunk` (integer): the index number of the chunk that you wish to fetch. These IDs are 0 indexed. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"genesis_chunked\",\"params\":{\"chunk\":\"0\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "chunk": "0", "total": "1", "data": "ewogICJhcHBfbmFtZSI6ICJ3YXNtZCIsCiAgImFwcF92ZXJzaW9uIjogIjAuNTAuMCIsCiAgImdlbmVzaXNfdGltZSI6ICIyMDI0LTA2LTExVDE5OjQ3OjAyLjU4ODE0MDY2NFoiLAogICJjaGFpbl9pZCI6ICJsYW5kc2xpZGUtdGVzdCIsCiAgImluaXRpYWxfaGVpZ2h0IjogIjAiLAogICJhcHBfaGFzaCI6IG51bGwsCiAgImFwcF9zdGF0ZSI6IHsKICAgICIwNy10ZW5kZXJtaW50IjogbnVsbCwKICAgICJhdXRoIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJtYXhfbWVtb19jaGFyYWN0ZXJzIjogIjI1NiIsCiAgICAgICAgInR4X3NpZ19saW1pdCI6ICI3IiwKICAgICAgICAidHhfc2l6ZV9jb3N0X3Blcl9ieXRlIjogIjEwIiwKICAgICAgICAic2lnX3ZlcmlmeV9jb3N0X2VkMjU1MTkiOiAiNTkwIiwKICAgICAgICAic2lnX3ZlcmlmeV9jb3N0X3NlY3AyNTZrMSI6ICIxMDAwIgogICAgICB9LAogICAgICAiYWNjb3VudHMiOiBbCiAgICAgICAgewogICAgICAgICAgIkB0eXBlIjogIi9jb3Ntb3MuYXV0aC52MWJldGExLkJhc2VBY2NvdW50IiwKICAgICAgICAgICJhZGRyZXNzIjogIndhc20xdmN3MGhlNWw5bXU1NHphd2czaDQ0MHA4M2V4NzBjY21tZTUzYWMiLAogICAgICAgICAgInB1Yl9rZXkiOiBudWxsLAogICAgICAgICAgImFjY291bnRfbnVtYmVyIjogIjAiLAogICAgICAgICAgInNlcXVlbmNlIjogIjAiCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5hdXRoLnYxYmV0YTEuQmFzZUFjY291bnQiLAogICAgICAgICAgImFkZHJlc3MiOiAid2FzbTFrbmc2c3FrbTBtanVoMDljd3o2dTg2Zjc1bG1lZmxqOWgwZnFociIsCiAgICAgICAgICAicHViX2tleSI6IG51bGwsCiAgICAgICAgICAiYWNjb3VudF9udW1iZXIiOiAiMSIsCiAgICAgICAgICAic2VxdWVuY2UiOiAiMCIKICAgICAgICB9LAogICAgICAgIHsKICAgICAgICAgICJAdHlwZSI6ICIvY29zbW9zLmF1dGgudjFiZXRhMS5CYXNlQWNjb3VudCIsCiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMWM0dzRqeGRrdmozeWdkeWNka2p5OThqdmU2dzBkNzI1N2VxZng5IiwKICAgICAgICAgICJwdWJfa2V5IjogbnVsbCwKICAgICAgICAgICJhY2NvdW50X251bWJlciI6ICIyIiwKICAgICAgICAgICJzZXF1ZW5jZSI6ICIwIgogICAgICAgIH0KICAgICAgXQogICAgfSwKICAgICJhdXRoeiI6IHsKICAgICAgImF1dGhvcml6YXRpb24iOiBbXQogICAgfSwKICAgICJiYW5rIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJzZW5kX2VuYWJsZWQiOiBbXSwKICAgICAgICAiZGVmYXVsdF9zZW5kX2VuYWJsZWQiOiB0cnVlCiAgICAgIH0sCiAgICAgICJiYWxhbmNlcyI6IFsKICAgICAgICB7CiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMXZjdzBoZTVsOW11NTR6YXdnM2g0NDBwODNleDcwY2NtbWU1M2FjIiwKICAgICAgICAgICJjb2lucyI6IFsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICAgImFtb3VudCI6ICIxMDAwMDAwMDAwIgogICAgICAgICAgICB9CiAgICAgICAgICBdCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAiYWRkcmVzcyI6ICJ3YXNtMWtuZzZzcWttMG1qdWgwOWN3ejZ1ODZmNzVsbWVmbGo5aDBmcWhyIiwKICAgICAgICAgICJjb2lucyI6IFsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICAgImFtb3VudCI6ICIxMDAwMDAwMDAwIgogICAgICAgICAgICB9CiAgICAgICAgICBdCiAgICAgICAgfQogICAgICBdLAogICAgICAic3VwcGx5IjogWwogICAgICAgIHsKICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAiYW1vdW50IjogIjIwMDAwMDAwMDAiCiAgICAgICAgfQogICAgICBdLAogICAgICAiZGVub21fbWV0YWRhdGEiOiBbXSwKICAgICAgInNlbmRfZW5hYmxlZCI6IFtdCiAgICB9LAogICAgImNhcGFiaWxpdHkiOiB7CiAgICAgICJpbmRleCI6ICIxIiwKICAgICAgIm93bmVycyI6IFtdCiAgICB9LAogICAgImNpcmN1aXQiOiB7CiAgICAgICJhY2NvdW50X3Blcm1pc3Npb25zIjogW10sCiAgICAgICJkaXNhYmxlZF90eXBlX3VybHMiOiBbXQogICAgfSwKICAgICJjb25zZW5zdXMiOiBudWxsLAogICAgImNyaXNpcyI6IHsKICAgICAgImNvbnN0YW50X2ZlZSI6IHsKICAgICAgICAiZGVub20iOiAic3Rha2UiLAogICAgICAgICJhbW91bnQiOiAiMTAwMCIKICAgICAgfQogICAgfSwKICAgICJkaXN0cmlidXRpb24iOiB7CiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgImNvbW11bml0eV90YXgiOiAiMC4wMjAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJiYXNlX3Byb3Bvc2VyX3Jld2FyZCI6ICIwLjAwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImJvbnVzX3Byb3Bvc2VyX3Jld2FyZCI6ICIwLjAwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgIndpdGhkcmF3X2FkZHJfZW5hYmxlZCI6IHRydWUKICAgICAgfSwKICAgICAgImZlZV9wb29sIjogewogICAgICAgICJjb21tdW5pdHlfcG9vbCI6IFtdCiAgICAgIH0sCiAgICAgICJkZWxlZ2F0b3Jfd2l0aGRyYXdfaW5mb3MiOiBbXSwKICAgICAgInByZXZpb3VzX3Byb3Bvc2VyIjogIiIsCiAgICAgICJvdXRzdGFuZGluZ19yZXdhcmRzIjogW10sCiAgICAgICJ2YWxpZGF0b3JfYWNjdW11bGF0ZWRfY29tbWlzc2lvbnMiOiBbXSwKICAgICAgInZhbGlkYXRvcl9oaXN0b3JpY2FsX3Jld2FyZHMiOiBbXSwKICAgICAgInZhbGlkYXRvcl9jdXJyZW50X3Jld2FyZHMiOiBbXSwKICAgICAgImRlbGVnYXRvcl9zdGFydGluZ19pbmZvcyI6IFtdLAogICAgICAidmFsaWRhdG9yX3NsYXNoX2V2ZW50cyI6IFtdCiAgICB9LAogICAgImV2aWRlbmNlIjogewogICAgICAiZXZpZGVuY2UiOiBbXQogICAgfSwKICAgICJmZWVncmFudCI6IHsKICAgICAgImFsbG93YW5jZXMiOiBbXQogICAgfSwKICAgICJmZWVpYmMiOiB7CiAgICAgICJpZGVudGlmaWVkX2ZlZXMiOiBbXSwKICAgICAgImZlZV9lbmFibGVkX2NoYW5uZWxzIjogW10sCiAgICAgICJyZWdpc3RlcmVkX3BheWVlcyI6IFtdLAogICAgICAicmVnaXN0ZXJlZF9jb3VudGVycGFydHlfcGF5ZWVzIjogW10sCiAgICAgICJmb3J3YXJkX3JlbGF5ZXJzIjogW10KICAgIH0sCiAgICAiZ2VudXRpbCI6IHsKICAgICAgImdlbl90eHMiOiBbCiAgICAgICAgewogICAgICAgICAgImJvZHkiOiB7CiAgICAgICAgICAgICJtZXNzYWdlcyI6IFsKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5zdGFraW5nLnYxYmV0YTEuTXNnQ3JlYXRlVmFsaWRhdG9yIiwKICAgICAgICAgICAgICAgICJkZXNjcmlwdGlvbiI6IHsKICAgICAgICAgICAgICAgICAgIm1vbmlrZXIiOiAibm9kZTEiLAogICAgICAgICAgICAgICAgICAiaWRlbnRpdHkiOiAiIiwKICAgICAgICAgICAgICAgICAgIndlYnNpdGUiOiAiIiwKICAgICAgICAgICAgICAgICAgInNlY3VyaXR5X2NvbnRhY3QiOiAiIiwKICAgICAgICAgICAgICAgICAgImRldGFpbHMiOiAiIgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJjb21taXNzaW9uIjogewogICAgICAgICAgICAgICAgICAicmF0ZSI6ICIwLjEwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgICAgICAgICAgICJtYXhfcmF0ZSI6ICIwLjIwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgICAgICAgICAgICJtYXhfY2hhbmdlX3JhdGUiOiAiMC4wMTAwMDAwMDAwMDAwMDAwMDAiCiAgICAgICAgICAgICAgICB9LAogICAgICAgICAgICAgICAgIm1pbl9zZWxmX2RlbGVnYXRpb24iOiAiMSIsCiAgICAgICAgICAgICAgICAiZGVsZWdhdG9yX2FkZHJlc3MiOiAiIiwKICAgICAgICAgICAgICAgICJ2YWxpZGF0b3JfYWRkcmVzcyI6ICJ3YXNtdmFsb3BlcjF2Y3cwaGU1bDltdTU0emF3ZzNoNDQwcDgzZXg3MGNjbXc5cGRueiIsCiAgICAgICAgICAgICAgICAicHVia2V5IjogewogICAgICAgICAgICAgICAgICAiQHR5cGUiOiAiL2Nvc21vcy5jcnlwdG8uZWQyNTUxOS5QdWJLZXkiLAogICAgICAgICAgICAgICAgICAia2V5IjogInlEKzJoN3ZZWW1yVTFBQSs3c01UdjFVaktFOFQ3aFZoZ01xcjlFei9IQTg9IgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJ2YWx1ZSI6IHsKICAgICAgICAgICAgICAgICAgImRlbm9tIjogInN0YWtlIiwKICAgICAgICAgICAgICAgICAgImFtb3VudCI6ICIyNTAwMDAwMDAiCiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgfQogICAgICAgICAgICBdLAogICAgICAgICAgICAibWVtbyI6ICIxOTVjYmUyYWM0YTNmMmUwNTFkNmNjNTgwOTZhNTUxNzJkOTMwZDNlQDE5Mi4xNjguNTAuMjUxOjI2NjU2IiwKICAgICAgICAgICAgInRpbWVvdXRfaGVpZ2h0IjogIjAiLAogICAgICAgICAgICAiZXh0ZW5zaW9uX29wdGlvbnMiOiBbXSwKICAgICAgICAgICAgIm5vbl9jcml0aWNhbF9leHRlbnNpb25fb3B0aW9ucyI6IFtdCiAgICAgICAgICB9LAogICAgICAgICAgImF1dGhfaW5mbyI6IHsKICAgICAgICAgICAgInNpZ25lcl9pbmZvcyI6IFsKICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAicHVibGljX2tleSI6IHsKICAgICAgICAgICAgICAgICAgIkB0eXBlIjogIi9jb3Ntb3MuY3J5cHRvLnNlY3AyNTZrMS5QdWJLZXkiLAogICAgICAgICAgICAgICAgICAia2V5IjogIkFoRmdnWEc4ZlcwOEhLRGFjTGpoVVYyOGw2cVFRejY3WkF1b0hHRGx3Q3g0IgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJtb2RlX2luZm8iOiB7CiAgICAgICAgICAgICAgICAgICJzaW5nbGUiOiB7CiAgICAgICAgICAgICAgICAgICAgIm1vZGUiOiAiU0lHTl9NT0RFX0RJUkVDVCIKICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJzZXF1ZW5jZSI6ICIwIgogICAgICAgICAgICAgIH0KICAgICAgICAgICAgXSwKICAgICAgICAgICAgImZlZSI6IHsKICAgICAgICAgICAgICAiYW1vdW50IjogW10sCiAgICAgICAgICAgICAgImdhc19saW1pdCI6ICIyMDAwMDAiLAogICAgICAgICAgICAgICJwYXllciI6ICIiLAogICAgICAgICAgICAgICJncmFudGVyIjogIiIKICAgICAgICAgICAgfSwKICAgICAgICAgICAgInRpcCI6IG51bGwKICAgICAgICAgIH0sCiAgICAgICAgICAic2lnbmF0dXJlcyI6IFsKICAgICAgICAgICAgImVsQWlTQjUwZUkyamQ4T2kvR1JlUEdLaWFBNFlRNXYybVVtWm9UeWwxZllQdUZHL1BEdnJRZk84cHVRamdRN3RBc2hXVlV4V0lRdDlWRGdSaHhPcnd3PT0iCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICBdCiAgICB9LAogICAgImdvdiI6IHsKICAgICAgInN0YXJ0aW5nX3Byb3Bvc2FsX2lkIjogIjEiLAogICAgICAiZGVwb3NpdHMiOiBbXSwKICAgICAgInZvdGVzIjogW10sCiAgICAgICJwcm9wb3NhbHMiOiBbXSwKICAgICAgImRlcG9zaXRfcGFyYW1zIjogbnVsbCwKICAgICAgInZvdGluZ19wYXJhbXMiOiBudWxsLAogICAgICAidGFsbHlfcGFyYW1zIjogbnVsbCwKICAgICAgInBhcmFtcyI6IHsKICAgICAgICAibWluX2RlcG9zaXQiOiBbCiAgICAgICAgICB7CiAgICAgICAgICAgICJkZW5vbSI6ICJzdGFrZSIsCiAgICAgICAgICAgICJhbW91bnQiOiAiMTAwMDAwMDAiCiAgICAgICAgICB9CiAgICAgICAgXSwKICAgICAgICAibWF4X2RlcG9zaXRfcGVyaW9kIjogIjE3MjgwMHMiLAogICAgICAgICJ2b3RpbmdfcGVyaW9kIjogIjE3MjgwMHMiLAogICAgICAgICJxdW9ydW0iOiAiMC4zMzQwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJ0aHJlc2hvbGQiOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJ2ZXRvX3RocmVzaG9sZCI6ICIwLjMzNDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgIm1pbl9pbml0aWFsX2RlcG9zaXRfcmF0aW8iOiAiMC4wMDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJwcm9wb3NhbF9jYW5jZWxfcmF0aW8iOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJwcm9wb3NhbF9jYW5jZWxfZGVzdCI6ICIiLAogICAgICAgICJleHBlZGl0ZWRfdm90aW5nX3BlcmlvZCI6ICI4NjQwMHMiLAogICAgICAgICJleHBlZGl0ZWRfdGhyZXNob2xkIjogIjAuNjY3MDAwMDAwMDAwMDAwMDAwIiwKICAgICAgICAiZXhwZWRpdGVkX21pbl9kZXBvc2l0IjogWwogICAgICAgICAgewogICAgICAgICAgICAiZGVub20iOiAic3Rha2UiLAogICAgICAgICAgICAiYW1vdW50IjogIjUwMDAwMDAwIgogICAgICAgICAgfQogICAgICAgIF0sCiAgICAgICAgImJ1cm5fdm90ZV9xdW9ydW0iOiBmYWxzZSwKICAgICAgICAiYnVybl9wcm9wb3NhbF9kZXBvc2l0X3ByZXZvdGUiOiBmYWxzZSwKICAgICAgICAiYnVybl92b3RlX3ZldG8iOiB0cnVlLAogICAgICAgICJtaW5fZGVwb3NpdF9yYXRpbyI6ICIwLjAxMDAwMDAwMDAwMDAwMDAwMCIKICAgICAgfSwKICAgICAgImNvbnN0aXR1dGlvbiI6ICIiCiAgICB9LAogICAgImdyb3VwIjogewogICAgICAiZ3JvdXBfc2VxIjogIjAiLAogICAgICAiZ3JvdXBzIjogW10sCiAgICAgICJncm91cF9tZW1iZXJzIjogW10sCiAgICAgICJncm91cF9wb2xpY3lfc2VxIjogIjAiLAogICAgICAiZ3JvdXBfcG9saWNpZXMiOiBbXSwKICAgICAgInByb3Bvc2FsX3NlcSI6ICIwIiwKICAgICAgInByb3Bvc2FscyI6IFtdLAogICAgICAidm90ZXMiOiBbXQogICAgfSwKICAgICJpYmMiOiB7CiAgICAgICJjbGllbnRfZ2VuZXNpcyI6IHsKICAgICAgICAiY2xpZW50cyI6IFtdLAogICAgICAgICJjbGllbnRzX2NvbnNlbnN1cyI6IFtdLAogICAgICAgICJjbGllbnRzX21ldGFkYXRhIjogW10sCiAgICAgICAgInBhcmFtcyI6IHsKICAgICAgICAgICJhbGxvd2VkX2NsaWVudHMiOiBbCiAgICAgICAgICAgICIwNi1zb2xvbWFjaGluZSIsCiAgICAgICAgICAgICIwNy10ZW5kZXJtaW50IiwKICAgICAgICAgICAgIjA5LWxvY2FsaG9zdCIKICAgICAgICAgIF0KICAgICAgICB9LAogICAgICAgICJjcmVhdGVfbG9jYWxob3N0IjogZmFsc2UsCiAgICAgICAgIm5leHRfY2xpZW50X3NlcXVlbmNlIjogIjAiCiAgICAgIH0sCiAgICAgICJjb25uZWN0aW9uX2dlbmVzaXMiOiB7CiAgICAgICAgImNvbm5lY3Rpb25zIjogW10sCiAgICAgICAgImNsaWVudF9jb25uZWN0aW9uX3BhdGhzIjogW10sCiAgICAgICAgIm5leHRfY29ubmVjdGlvbl9zZXF1ZW5jZSI6ICIwIiwKICAgICAgICAicGFyYW1zIjogewogICAgICAgICAgIm1heF9leHBlY3RlZF90aW1lX3Blcl9ibG9jayI6ICIzMDAwMDAwMDAwMCIKICAgICAgICB9CiAgICAgIH0sCiAgICAgICJjaGFubmVsX2dlbmVzaXMiOiB7CiAgICAgICAgImNoYW5uZWxzIjogW10sCiAgICAgICAgImFja25vd2xlZGdlbWVudHMiOiBbXSwKICAgICAgICAiY29tbWl0bWVudHMiOiBbXSwKICAgICAgICAicmVjZWlwdHMiOiBbXSwKICAgICAgICAic2VuZF9zZXF1ZW5jZXMiOiBbXSwKICAgICAgICAicmVjdl9zZXF1ZW5jZXMiOiBbXSwKICAgICAgICAiYWNrX3NlcXVlbmNlcyI6IFtdLAogICAgICAgICJuZXh0X2NoYW5uZWxfc2VxdWVuY2UiOiAiMCIKICAgICAgfQogICAgfSwKICAgICJpbnRlcmNoYWluYWNjb3VudHMiOiB7CiAgICAgICJjb250cm9sbGVyX2dlbmVzaXNfc3RhdGUiOiB7CiAgICAgICAgImFjdGl2ZV9jaGFubmVscyI6IFtdLAogICAgICAgICJpbnRlcmNoYWluX2FjY291bnRzIjogW10sCiAgICAgICAgInBvcnRzIjogW10sCiAgICAgICAgInBhcmFtcyI6IHsKICAgICAgICAgICJjb250cm9sbGVyX2VuYWJsZWQiOiB0cnVlCiAgICAgICAgfQogICAgICB9LAogICAgICAiaG9zdF9nZW5lc2lzX3N0YXRlIjogewogICAgICAgICJhY3RpdmVfY2hhbm5lbHMiOiBbXSwKICAgICAgICAiaW50ZXJjaGFpbl9hY2NvdW50cyI6IFtdLAogICAgICAgICJwb3J0IjogImljYWhvc3QiLAogICAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgICAiaG9zdF9lbmFibGVkIjogdHJ1ZSwKICAgICAgICAgICJhbGxvd19tZXNzYWdlcyI6IFsKICAgICAgICAgICAgIioiCiAgICAgICAgICBdCiAgICAgICAgfQogICAgICB9CiAgICB9LAogICAgIm1pbnQiOiB7CiAgICAgICJtaW50ZXIiOiB7CiAgICAgICAgImluZmxhdGlvbiI6ICIwLjEzMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImFubnVhbF9wcm92aXNpb25zIjogIjAuMDAwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAicGFyYW1zIjogewogICAgICAgICJtaW50X2Rlbm9tIjogInN0YWtlIiwKICAgICAgICAiaW5mbGF0aW9uX3JhdGVfY2hhbmdlIjogIjAuMTMwMDAwMDAwMDAwMDAwMDAwIiwKICAgICAgICAiaW5mbGF0aW9uX21heCI6ICIwLjIwMDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImluZmxhdGlvbl9taW4iOiAiMC4wNzAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJnb2FsX2JvbmRlZCI6ICIwLjY3MDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgImJsb2Nrc19wZXJfeWVhciI6ICI2MzExNTIwIgogICAgICB9CiAgICB9LAogICAgIm5mdCI6IHsKICAgICAgImNsYXNzZXMiOiBbXSwKICAgICAgImVudHJpZXMiOiBbXQogICAgfSwKICAgICJwYXJhbXMiOiBudWxsLAogICAgInNsYXNoaW5nIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJzaWduZWRfYmxvY2tzX3dpbmRvdyI6ICIxMDAiLAogICAgICAgICJtaW5fc2lnbmVkX3Blcl93aW5kb3ciOiAiMC41MDAwMDAwMDAwMDAwMDAwMDAiLAogICAgICAgICJkb3dudGltZV9qYWlsX2R1cmF0aW9uIjogIjYwMHMiLAogICAgICAgICJzbGFzaF9mcmFjdGlvbl9kb3VibGVfc2lnbiI6ICIwLjA1MDAwMDAwMDAwMDAwMDAwMCIsCiAgICAgICAgInNsYXNoX2ZyYWN0aW9uX2Rvd250aW1lIjogIjAuMDEwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAic2lnbmluZ19pbmZvcyI6IFtdLAogICAgICAibWlzc2VkX2Jsb2NrcyI6IFtdCiAgICB9LAogICAgInN0YWtpbmciOiB7CiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgInVuYm9uZGluZ190aW1lIjogIjE4MTQ0MDBzIiwKICAgICAgICAibWF4X3ZhbGlkYXRvcnMiOiAxMDAsCiAgICAgICAgIm1heF9lbnRyaWVzIjogNywKICAgICAgICAiaGlzdG9yaWNhbF9lbnRyaWVzIjogMTAwMDAsCiAgICAgICAgImJvbmRfZGVub20iOiAic3Rha2UiLAogICAgICAgICJtaW5fY29tbWlzc2lvbl9yYXRlIjogIjAuMDAwMDAwMDAwMDAwMDAwMDAwIgogICAgICB9LAogICAgICAibGFzdF90b3RhbF9wb3dlciI6ICIwIiwKICAgICAgImxhc3RfdmFsaWRhdG9yX3Bvd2VycyI6IFtdLAogICAgICAidmFsaWRhdG9ycyI6IFtdLAogICAgICAiZGVsZWdhdGlvbnMiOiBbXSwKICAgICAgInVuYm9uZGluZ19kZWxlZ2F0aW9ucyI6IFtdLAogICAgICAicmVkZWxlZ2F0aW9ucyI6IFtdLAogICAgICAiZXhwb3J0ZWQiOiBmYWxzZQogICAgfSwKICAgICJ0cmFuc2ZlciI6IHsKICAgICAgInBvcnRfaWQiOiAidHJhbnNmZXIiLAogICAgICAiZGVub21fdHJhY2VzIjogW10sCiAgICAgICJwYXJhbXMiOiB7CiAgICAgICAgInNlbmRfZW5hYmxlZCI6IHRydWUsCiAgICAgICAgInJlY2VpdmVfZW5hYmxlZCI6IHRydWUKICAgICAgfSwKICAgICAgInRvdGFsX2VzY3Jvd2VkIjogW10KICAgIH0sCiAgICAidXBncmFkZSI6IHt9LAogICAgInZlc3RpbmciOiB7fSwKICAgICJ3YXNtIjogewogICAgICAicGFyYW1zIjogewogICAgICAgICJjb2RlX3VwbG9hZF9hY2Nlc3MiOiB7CiAgICAgICAgICAicGVybWlzc2lvbiI6ICJFdmVyeWJvZHkiLAogICAgICAgICAgImFkZHJlc3NlcyI6IFtdCiAgICAgICAgfSwKICAgICAgICAiaW5zdGFudGlhdGVfZGVmYXVsdF9wZXJtaXNzaW9uIjogIkV2ZXJ5Ym9keSIKICAgICAgfSwKICAgICAgImNvZGVzIjogW10sCiAgICAgICJjb250cmFjdHMiOiBbXSwKICAgICAgInNlcXVlbmNlcyI6IFtdCiAgICB9CiAgfSwKICAiY29uc2Vuc3VzIjogewogICAgInBhcmFtcyI6IHsKICAgICAgImJsb2NrIjogewogICAgICAgICJtYXhfYnl0ZXMiOiAiMjIwMjAwOTYiLAogICAgICAgICJtYXhfZ2FzIjogIi0xIgogICAgICB9LAogICAgICAiZXZpZGVuY2UiOiB7CiAgICAgICAgIm1heF9hZ2VfbnVtX2Jsb2NrcyI6ICIxMDAwMDAiLAogICAgICAgICJtYXhfYWdlX2R1cmF0aW9uIjogIjE3MjgwMDAwMDAwMDAwMCIsCiAgICAgICAgIm1heF9ieXRlcyI6ICIxMDQ4NTc2IgogICAgICB9LAogICAgICAidmFsaWRhdG9yIjogewogICAgICAgICJwdWJfa2V5X3R5cGVzIjogWwogICAgICAgICAgImVkMjU1MTkiCiAgICAgICAgXQogICAgICB9LAogICAgICAidmVyc2lvbiI6IHsKICAgICAgICAiYXBwIjogIjAiCiAgICAgIH0sCiAgICAgICJhYmNpIjogewogICAgICAgICJ2b3RlX2V4dGVuc2lvbnNfZW5hYmxlX2hlaWdodCI6ICIwIgogICAgICB9CiAgICB9CiAgfQp9" } } ``` ### ConsensusParams Get the consensus parameters. #### **Parameters** * `height (integer)`: Block height at which the consensus params would like to be fetched for. #### **Request** **JSONRPC** ``` curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"consensus_params\",\"params\":{\"height\":\"0\"}}" ``` #### **Response** ``` { "jsonrpc": "2.0", "id": 1, "result": { "block_height": "67", "consensus_params": { "block": { "max_bytes": "22020096", "max_gas": "-1" }, "evidence": { "max_age_num_blocks": "100000", "max_age_duration": "172800000000000", "max_bytes": "1048576" }, "validator": { "pub_key_types": [ "ed25519" ] }, "version": { "app": "0" }, "abci": { "vote_extensions_enable_height": "0" } } } } ``` ### UnconfirmedTxs Get a list of unconfirmed transactions. #### **Parameters** * `limit (integer)` The amount of txs to respond with. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d '{"jsonrpc":"2.0","id":1,"method":"unconfirmed_txs","params":{"limit":"20"}}' ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "n_txs": "0", "total": "0", "total_bytes": "0", "txs": [] } } ``` ### NumUnconfirmedTxs Get data about unconfirmed transactions. #### **Parameters** None #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"num_unconfirmed_txs\"}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "n_txs": "0", "total": "0", "total_bytes": "0", "txs": null } } ``` ### Tx #### **Parameters** * `hash (string)`: The hash of the transaction * `prove (bool)`: If the response should include proof the transaction was included in a block. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"num_unconfirmed_txs\"}" ``` **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "n_txs": "0", "total": "0", "total_bytes": "0", "txs": null } } ``` ### 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. * **per\_page** (`string`): The number of transactions to show per page. * **order\_by** (`string`): Specifies the sort order (`"asc"` or `"desc"`). #### **Request** **JSONRPC** ``` curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tx_search\",\"params\":{\"query\":\"tx.height=1\",\"prove\":true,\"page\":\"1\",\"per_page\":\"30\",\"order_by\":\"asc\"}}" ``` #### **Response** ``` { "jsonrpc": "2.0", "id": 1, "result": { "txs": [], "total_count": "0" } } ``` ### 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. * **order\_by** (`string`): Specifies the sort order (`"asc"` or `"desc"`). #### **Request** **JSONRPC** ``` curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block_search\",\"params\":{\"query\":\"block.height > 1\",\"page\":\"1\",\"per_page\":\"20\",\"order_by\":\"desc\"}}" ``` #### **Response** ``` { "jsonrpc": "2.0", "id": 1, "result": { "blocks": [], "total_count": "0" } } ``` ## Transaction Routes *** ### BroadCastTxSync Returns with the response from CheckTx. Does not wait for DeliverTx result. #### **Parameters** * `tx (string)`: The transaction encoded #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"broadcast_tx_sync\",\"params\":{\"tx\":\"a/null/c\"}}" ``` **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "code": 2, "data": "", "log": "expected 2 wire type, got 3: tx parse error", "codespace": "sdk", "hash": "8C4547C2D0B04641DB22F4F5B10B64A1A8181AD514352795022B9EFC86A67056" } } ``` ### BroadCastTxAsync Returns right away, with no response. Does not wait for CheckTx nor DeliverTx results. #### **Parameters** * `tx (string)`: The transaction encoded #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"broadcast_tx_async\",\"params\":{\"tx\":\"a/null/c\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "code": 0, "data": "", "log": "", "codespace": "", "hash": "8C4547C2D0B04641DB22F4F5B10B64A1A8181AD514352795022B9EFC86A67056" } } ``` ### CheckTx Checks the transaction without executing it. #### **Parameters** * `tx (string)`: String of the encoded transaction #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"check_tx\",\"params\":{\"tx\":\"a/null/c\"}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "code": 2, "data": null, "log": "expected 2 wire type, got 3: tx parse error", "info": "", "gas_wanted": "0", "gas_used": "1174", "events": [], "codespace": "sdk" } } ``` ## ABCI Routes *** ### ABCIInfo Get some info about the application. #### **Parameters** None #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"abci_info\"}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "response": { "data": "WasmApp", "last_block_height": "67", "last_block_app_hash": "S6enjHgkIVQb/2Avml61hJNuqPNO0we3IpFZ9RbaB+Y=" } } } ``` ### ABCIQuery Query the application for some information. #### **Parameters** * `path (string)`: A request path for the application to interpret analogously to a [URI path component](https://www.rfc-editor.org/rfc/rfc3986#section-3.3) in e.g. routing. * `data (string)`: Request parameters for the application to interpret analogously to a [URI query component](https://www.rfc-editor.org/rfc/rfc3986#section-3.4), expressed as hexadecimal-serialized bytes (convert `WasmApp` to hex is `5761736d417070`). * `height (integer)`: The block height against which to query. * `prove (bool)`: Return Merkle proof with response if possible. #### **Request** **JSONRPC** ```sh curl -X POST https://cometrpc.testnet.landslide.network -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"abci_query\",\"params\":{\"path\":\"/key\", \"data\":\"5761736d417070\", \"height\":\"1\", \"prove\":true}}" ``` #### **Response** ```json { "jsonrpc": "2.0", "id": 1, "result": { "response": { "code": 6, "log": "unknown query path: unknown request", "info": "", "index": "0", "key": null, "value": null, "proofOps": null, "height": "0", "codespace": "sdk" } } } ``` # API endpoints ## 🔌 Landslide Network Testnet Endpoints The following endpoints are available for connecting to the Landslide Network testnet: ### RPC Endpoint ```bash https://cometrpc.testnet.landslide.network ``` 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. ### gRPC Endpoint ```bash https://grpc.testnet.landslide.network ``` The gRPC endpoint provides high-performance, bi-directional streaming capabilities. Ideal for applications requiring efficient data streaming and complex service definitions. ### REST API Endpoint ```bash https://api.testnet.landslide.network ``` The REST API endpoint offers a RESTful interface for blockchain interactions. Perfect for web applications and clients that prefer standard HTTP methods. ### Usage Examples #### RPC Connection (JavaScript) ```javascript const provider = new JsonRpcProvider("https://cometrpc.testnet.landslide.network"); ``` #### REST API Query (cURL) ```bash curl https://api.testnet.landslide.network/cosmos/bank/v1beta1/balances/{address} ``` #### gRPC Connection (Python) ```python import grpc channel = grpc.insecure_channel('grpc.testnet.landslide.network:443') ``` ### ⚠️ Note These endpoints are for the testnet environment and should not be used for production applications. Network performance and availability may vary as this is a test network. # 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](https://docs.google.com/presentation/d/1eV4IGMB7qNV7Fc4hp7NplWxK_1cFycwCMhjrcnsE9mU/edit).
{% @mermaid/diagram content="sequenceDiagram Actor Sender Note right of Sender: Create ExportTX message:
\*Source chain
\*Destination chain
\*Recipient address
\*amount Sender->>Subnet A: sign message Activate Subnet A\ Note right of Subnet A: Create Payload:
\*Source chain
\*Destination chain
\*Recipient address
\*amount Subnet A->>Subnet A:\ Note right of Subnet A: Create UnsignedMessage:
\*Source chain
\*Destination chain
\*Payload
Subnet A->>Avalanche: Calls NewUnsignedMessage
using WARP (Go module call) Avalanche->>Subnet A: Returns WARP unsigned Subnet A->>Subnet A: Save message into state Subnet A->>Sender: Returns Tx ID deactivate Subnet A participant Subnet A participant Subnet B actor Receiver Sender->>Receiver: Shares Tx ID Note left of Receiver: Provides list of URIs
of subnet A Validators
and Tx ID
Receiver->>Subnet B: Activate Subnet B Subnet B->>Subnet A: Query Unsigned Message and Signature by Tx ID Activate Subnet A Subnet A->>Subnet A: Get Unsigned message from state Subnet A->>Avalanche: Query Signature of Message activate Avalanche Note left of Avalanche: Validator keeps BLS private key
it uses this key to sign the Message
and Tx ID
Avalanche->>Subnet A: Returns Signature deactivate Avalanche Subnet A->>Subnet B: Returns Unsigned Message and Signature deactivate Subnet A Avalanche->>Subnet B: Get Validator Node Public Key Subnet B->>Subnet B: verifies Signature against Public Key Note left of Subnet B: \*Combines all Signatures together
Verifies that this signature was signed
by at least \[quorumNum/quorumDen]
of the validators of
\[msg.SourceChainID] at \[pChainHeight]. Subnet B->>Subnet B: Build and accept block deactivate Subnet B " %} # Building with Andromeda ## Slide SDK Documentation: Installing and Configuring Andromeda ### Prerequisites * Slide SDK and landslide-runner are already installed and set up. * You have obtained a Blockchain ID from the landslide-runner. ### Installing and Configuring Andromeda #### 1. Deploy Andromeda to Local Network First, we need to deploy Andromeda to your local Landslide network: 1. Navigate to the landslide-runner directory (installed earlier): ``` cd path/to/landslide-runner ``` 2. Run the following command to deploy Andromeda: ``` ./andr.sh ``` Replace `` with the actual Blockchain ID you received from the landslide-runner. For example: ``` ./andr.sh M5Rj4ySM3g3ZREBJDJgaRCQxbqQutF1MXcHcniZEVZRKm9TPG ``` 3. Wait for the deployment process to complete. This may take a few minutes. ## Understanding Your Andromeda Deployment Let's break down what happened when you ran that `./andr.sh` command. ### What the Command Does The `./andr.sh` command sets up Andromeda on your local Landslide network. It deploys several smart contracts that make up the Andromeda system. ### What Happened **The Good Stuff:** * The script connected to your Landslide network successfully. Yay! * It deployed several important contracts: * Andromeda Kernel (the brain of the system) * VFS (Virtual File System, for managing data) * ADODB (Andromeda Digitial Object Database; another data management component) * CW20 (a token contract) * CW20 Exchange (for trading those tokens) ### What This Means for You 1. **Your Andromeda system is mostly set up.** 🎉 ### Next Steps 1. **Try using the Andromeda CLI** to interact with your newly deployed contracts. This will help you confirm what's working. 2. It might be helpful to check the current state of your network before running the deployment script. There could be existing contracts or transactions that are affecting the process. 3. If you continue to encounter issues, it may be worth discussing with more experienced team members or consulting the Andromeda documentation for troubleshooting steps. ### Pro Tip As you work more with blockchain systems like Andromeda, you'll encounter various errors and edge cases. Each one is an opportunity to deepen your understanding of how these systems work under the hood. ### 2. Install Andromeda CLI After deploying Andromeda to your local network, install the Andromeda CLI globally: ```bash npm install -g @andromedaprotocol/cli ``` ### 3. Configure Andromeda CLI Now, configure the Andromeda CLI to connect to your local Landslide network: 1. Create the configuration directory (if it doesn't exist): ``` mkdir -p ~/.andr-cli ``` 2. Create and open the configuration file in a text editor: ``` nano ~/.andr-cli/chainConfigs.json ``` 3. Copy and paste the following JSON content into the file: ```json [ { "chainName": "landslide", "chainId": "landslide-test", "chainUrl": "http://127.0.0.1:9754/ext/bc//rpc", "chainType": "testnet", "registryAddress": "", "addressPrefix": "wasm", "defaultFee": "0.5stake", "name": "landslide", "blockExplorerAddressPages": [], "blockExplorerTxPages": [], "kernelAddress": "wasm14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9s0phg4d" } ] ``` 4. Replace `` in the `chainUrl` field with your actual Landslide blockchain ID (the same one used in step 1). 5. Save the file and exit the text editor (in nano, press `Ctrl+X`, then `Y`, then `Enter`). ### 4. Verify the Installation and Configuration To verify that Andromeda is correctly installed and configured: 1. Start the Andromeda CLI: ``` andr ``` 2. In the CLI, switch to the Landslide network: ``` chain use landslide ``` 3. If successful, you should now be connected to your local Landslide network. #### Andromeda CLI Output Explanation When you run the command `chain use landslide-test` in the Andromeda CLI, you should expect to see output similar to the following: ``` ? test@landslide-test> chain use landslide-test - Loading configs... — Loading config... Config loaded! – Connecting client...Error: Query failed with (6): type: cosmwasm_std::addresses::Addr; key: [00, 10, 6B, 65, 72, 6E, 65, 6C, 5F, 61, 64, 64, 72, 65, 73, 73, 65, 73, 76, 66, 73] not found: query wasm contract failed: unknown request [... stack trace ...] ``` ### Understanding the Output 1. **Successful Steps:** * The CLI successfully loads the configurations. * It confirms that the config is loaded. * It attempts to connect to the client (your local Landslide network). 2. **Expected Error:** * You will see an error message starting with "Error: Query failed with (6):..." * This error is **expected** and **not a cause for concern** at this stage of setup. * The error occurs because the CLI is trying to query certain contracts (like the kernel or VFS) that aren't fully set up yet on your local network. 3. **Prompt Change:** * Despite the error, you should notice that your prompt changes to `test@landslide-test>`. * This indicates that you have successfully switched to the landslide-test network. ### What This Means * The configuration for your landslide-test network is correct and recognized by the CLI. * The CLI can connect to your local Landslide network. * Some expected contracts or data aren't available yet, which is normal at this stage. * You can proceed with the next steps in setting up your Andromeda environment. ### Next Steps After seeing this output, you can continue with the next steps in the setup process, such as adding a wallet or deploying contracts. The error message does not prevent you from proceeding with these tasks. If you encounter different errors or issues, please consult with your team lead or refer to the troubleshooting section of the Andromeda documentation. ## Adding a Wallet to Andromeda CLI After successfully connecting to the landslide-test network, the next step is to add a wallet. This wallet will be used for transactions and interactions with smart contracts on your local Landslide network. ### Adding a Wallet Using Recovery 1. In the Andromeda CLI, enter the following command: ``` wallet add test --recover ``` 2. You will be prompted to enter a password. Choose a secure password and remember it, as you'll need it for future interactions with this wallet. 3. After entering the password, you'll be asked to input a mnemonic phrase. For this setup, use \*this specific private key\*, as we loaded it with testnet tokens. Enter this mnemonic: ``` tip yard art tape orchard universe angle flame wave gadget raven coyote crater ethics able evoke luxury predict leopard delay peanut embody blast soap ``` 4. Enter the mnemonic phrase exactly as shown above when prompted. 5. You may see an error message after adding the wallet. This is expected and not a cause for concern. ### Expected Output After entering the mnemonic, you should see output similar to the following: ``` ? Enter password for wallet test: ******** ? Enter mnemonic: **************************************************************************************** Error: Query failed with (6): type: cosmwasm_std::addresses::Addr; key: [00, 10, 6B, 65, 72, 6E, 65, 6C, 5F, 61, 64, 64, 72, 65, 73, 73, 65, 73, 76, 66, 73] not found: query wasm contract failed: unknown request [... stack trace ...] ``` ### Understanding the Output * The error message is similar to what you saw when connecting to the network. This is normal at this stage of the setup. * Despite the error, the wallet should be successfully added to your Andromeda CLI configuration. ### Verifying Wallet Addition To confirm that the wallet was added successfully: 1. Exit the Andromeda CLI: ``` exit ``` 2. Restart the Andromeda CLI: ``` andr ``` 3. Once back in the CLI, you should see a prompt indicating you're using the test wallet: ``` ? test@> ``` 4. You can now switch to the landslide-test network again: ``` chain use landslide-test ``` ### Next Steps With your wallet set up, you're now ready to interact with your local Landslide network using the Andromeda CLI. The next steps typically involve deploying contracts or interacting with existing ones on your network. Remember, the mnemonic phrase is crucial for accessing your wallet. In a real-world scenario, you should never share your mnemonic phrase. This test mnemonic is for local development purposes only. If you encounter any issues during this process that differ from what's described here, please consult with your team lead or refer to the troubleshooting section of the Andromeda documentation. ## Basic Andromeda CLI Operations Now that you've set up Andromeda, here are some basic operations you can perform: ### 1. Check Balance To check the balance of an address, follow these steps: 1. In the Andromeda CLI, type the following command and hit Enter: ``` Copybank balance ``` 2. You will be prompted to enter the denom (denomination) of the token. For our current setup, we are using "stake". So, type: ``` Copystake ``` and hit Enter. 3. Next, you'll be prompted to enter the address. Use this address: ``` Copywasm1kng6sqkm0mjuh09cwz6u86f75lmeflj9h0fqhr ``` and hit Enter. 4. The CLI will display the balance of the specified address in the "stake" denomination. ### 2. Transfer Funds To transfer funds to another address: ``` transfer wasm1c4w4jxdkvj3ygdycdkjy98jve6w0d7257eqfx9 10stake ``` #### Set Keys in Kernel You can set various keys in the kernel. Here are examples for economics, vfs, and adodb keys: ``` kernel set-key economics wasm1nc5tatafv6eyq7llkr2gv50ff9e22mnf70qgjlv737ktmt4eswrqr5j2ht kernel set-key vfs wasm17p9rzwnnfxcjp32un9ug7yhhzgtkhvl9jfksztgw5uh69wac2pgsm0v070 kernel set-key adodb wasm1ghd753shjuwexxywmgs4xz7x2q732vcnkm6h2pyv9s6ah3hylvrq8epk7w ``` #### Query Kernel To query the kernel for set keys: ``` kernel query ``` ### Interacting with Smart Contracts #### Get ADO Info To get information about a deployed contract: ``` ado info wasm1eyfccmjm6732k7wp4p6gdjwhxjwsvje44j0hfx8nkgrm8fs7vqfsuw7sel ``` #### CW20 Token Operations **Mint Tokens** ``` execute wasm1eyfccmjm6732k7wp4p6gdjwhxjwsvje44j0hfx8nkgrm8fs7vqfsuw7sel '{"mint":{"recipient":"wasm1c4w4jxdkvj3ygdycdkjy98jve6w0d7257eqfx9","amount":"1000"}}' ``` **Transfer Tokens** ``` execute wasm1eyfccmjm6732k7wp4p6gdjwhxjwsvje44j0hfx8nkgrm8fs7vqfsuw7sel '{"transfer":{"recipient":"wasm1kng6sqkm0mjuh09cwz6u86f75lmeflj9h0fqhr","amount":"500"}}' ``` **Check Token Balance** ``` query wasm1eyfccmjm6732k7wp4p6gdjwhxjwsvje44j0hfx8nkgrm8fs7vqfsuw7sel '{"balance":{"address":"wasm1c4w4jxdkvj3ygdycdkjy98jve6w0d7257eqfx9"}}' ``` #### VFS Operations To interact with the VFS (Virtual File System): ``` execute wasm17p9rzwnnfxcjp32un9ug7yhhzgtkhvl9jfksztgw5uh69wac2pgsm0v070 '{"get_possible_vfs_path":{"address":"wasm1nc5tatafv6eyq7llkr2gv50ff9e22mnf70qgjlv737ktmt4eswrqr5j2ht"}}' ``` #### Economics Operations To interact with the economics contract: ``` execute wasm1nc5tatafv6eyq7llkr2gv50ff9e22mnf70qgjlv737ktmt4eswrqr5j2ht '{"get_funds":{}}' ``` #### CW20-Exchange Operations To check current sales on the CW20-Exchange: ``` query wasm1pvrwmjuusn9wh34j7y520g8gumuy9xtl3gvprlljfdpwju3x7ucsfg5rpz '{"sale":{"asset":{"cw20":"wasm1eyfccmjm6732k7wp4p6gdjwhxjwsvje44j0hfx8nkgrm8fs7vqfsuw7sel"}}}' ``` ### Conclusion This guide covers the basics of setting up and using the Slide SDK with Andromeda CLI. As you become more familiar with these operations, you'll be able to build more complex interactions and applications on the Landslide network. Remember to always refer to the most up-to-date documentation and seek help from more experienced developers when dealing with advanced topics or issues. # Connecting Existing Cosmos dApps to Avalanche {% hint style="info" %} **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. {% endhint %} ## 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. ### Benefits 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 {% @mermaid/diagram content="sequenceDiagram participant Osmosis participant IBC Module participant Relayer participant Landslide Osmosis ->> IBC Module: Create packet data IBC Module ->> Relayer: Send packet to Relayer Relayer ->> IBC Module: Relay packet to destination chain IBC Module ->> Landslide: Receive packet on AVAX subnet Landslide ->> IBC Module: Acknowledge packet receipt IBC Module ->> Relayer: Send acknowledgement to relayer Relayer ->> IBC Module: Relay acknowledgement to source chain IBC Module ->> Osmosis: Deliver acknowledgement to dApp " %} 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. # Case Study: Osmosis Explaining the Osmosis integration ## Cosmoswap Here is a quick overview of how [Cosmoswap](https://blog.nabla.studio/nabla-ogp-present-cosmoswap-91b83464f285) 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. This allows users on Avalanche to tap into swaps powered by Osmosis's deep liquidity pools in a decentralized manner. Avalanche validators handle trades while Osmosis validators govern pool actions. Cosmoswap outposts like Landslide go beyond basic bridges. They create customizable DEX environments tuned to each chain's needs while benefiting from Osmosis's back-end infrastructure. Active transaction listening via WebSockets provides rich insights into swap status and performance. This enhances user experience with timely notifications. Overall, Cosmoswap unlocks new horizons for multi-chain decentralization by deploying adaptable outposts that harness Osmosis's liquidity. This delivers on the vision of fluid interoperability across heterogeneous networks. {% @mermaid/diagram content="sequenceDiagram participant Osmosis participant IBC Module participant Relayer participant Landslide Osmosis ->> IBC Module: Create packet data IBC Module ->> Relayer: Send packet to Relayer Relayer ->> IBC Module: Relay packet to destination chain IBC Module ->> Landslide: Receive packet on AVAX subnet Landslide ->> IBC Module: Acknowledge packet receipt IBC Module ->> Relayer: Send acknowledgement to relayer Relayer ->> IBC Module: Relay acknowledgement to source chain IBC Module ->> Osmosis: Deliver acknowledgement to dApp " %}
## Cross Chain Validation When utilizing Cosmoswap's outpost architecture, transaction validation occurs across both chains: {% @mermaid/diagram content="sequenceDiagram participant User participant Landslide participant Osmosis participant Avalanche ``` User->>Landslide: Initiates swap on Avalanche Landslide->>Osmosis: Checks liquidity on Osmosis Osmosis-->>Landslide: Approves withdrawal from core pools Avalanche->>Avalanche: Validates swap transaction Osmosis->>Osmosis: Validates IBC transfers Landslide-->>User: Returns swap result Osmosis->>Landslide: Relays IBC packets Avalanche->>Osmosis: Confirms IBC packets" %} ``` * Trades executed on the Landslide outpost on Avalanche are validated by Avalanche validators, not Osmosis validators. * However, the IBC packet transfers enabling asset flows between Osmosis and Landslide are validated on both sides: * Osmosis validators validate escrowing, transferring, and releasing assets on the Osmosis chain side. * Avalanche validators validate unwrapping assets and confirming token releases on Landslide. * The core liquidity pools reside on Osmosis. Osmosis validators govern deposit and withdrawal transactions for these pools. * Landslide contains router contracts that direct trades to the Osmosis pools while handling the user-facing Avalanche side. * This separation of duties retains security while maximizing performance. Osmosis secures the central pools while Avalanche validators handle end-user trades. In summary, Osmosis validators secure core pool liquidity and IBC transactions while Avalanche/Landslide validators govern swap execution and finality on the user front-end. This hybrid validation approach powers decentralized cross-chain swaps. # ABCI Calls ### 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. ### How to Connect Existing Cosmos dApps to Avalanche To connect existing Cosmos dApps to Avalanche using the Landslide Core repository, developers need to implement the necessary ABCI calls in their application. This includes implementing the `InitChain`, `BeginBlock`, `DeliverTx`, `CheckTx`, and `EndBlock` ABCI calls, which enable the dApp to interact with the Avalanche network. Once the ABCI calls are implemented, the dApp can be compiled using the Landslide SDK and deployed to the Avalanche network. The ABCI calls in the Landslide Core repository provide the interface for Cosmos-based dApps to interact with the Avalanche network. * `InitChain`: This ABCI call is used to initialize the application state. It is called once when the application is first started or when a new chain is created. This is where the initial genesis state of the application is set. * `BeginBlock`: This ABCI call is called at the beginning of each block. It provides information about the current block and allows the application to update its state based on the contents of the block. * `DeliverTx`: This ABCI call is called when a new transaction is delivered to the application. It is used to validate the transaction and update the application state if the transaction is valid. * `CheckTx`: This ABCI call is called when a new transaction is received by the node. It is used to validate the transaction before it is included in a block. * `EndBlock`: This ABCI call is called at the end of each block. It provides information about the current block and allows the application to update its state based on the contents of the block. To connect an existing Cosmos dApp to Avalanche using Landslide Core, developers need to implement these ABCI calls in their application. This is done by creating a new ABCI application that implements the necessary functions for each of the ABCI calls. These functions will define how the application interacts with the Avalanche network. Once the ABCI application is implemented, it can be compiled using the Landslide SDK and deployed to the Avalanche network. The Landslide SDK is a fork of the Cosmos SDK that is 99% compatible with the existing Cosmos SDK, with the exception of the consensus algorithm. The Landslide SDK includes all the necessary libraries and modules needed to build and deploy the ABCI application to the Avalanche network. In summary, 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. # 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.](https://docs.avax.network/reference/avalanchego/p-chain/api#platformgetvalidatorsat)\ \ 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 [here](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#limitations-on-the-number-of-validators).\ "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 [here](https://assets.website-files.com/5d80307810123f5ffbb34d6e/6008d7bbf8b10d1eb01e7e16_Avalanche%20Platform%20Whitepaper.pdf). "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 [here](https://docs.landslide.network/use-cases/connecting-existing-cosmos-dapps-to-avalanche#sharing-liquidity-outposts) 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. 1. A connection to a Cosmos dApp is only secured by IBC light client verification. 2. The Cosmos dApp (including its VM) will be redeployed on its original VM with a new Avalanche consensus algoritm.
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. [Avalanche currently has 1,238 validators](https://stats.avax.network/dashboard/network-status/), 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 [Avalanche documentation](https://docs.avax.network/learn/avalanche/avalanche-consensus), 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. 2.) Fast Finality: Avalanche consensus provides sub-second, immutable finality, ensuring that transactions are quickly confirmed and irreversible. This is achieved without needing to limit the number of validators, as the consensus process is not dependent on the size of the validator set. 3.) Security Guarantees: Avalanche consensus is designed to resist various attacks, including Sybil attacks, distributed denial-of-service (DDoS) attacks, and collusion attacks. Its probabilistic nature (rather than the deterministic nature of [all Tendermint chains](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html)) ensures that the consensus outcome converges to the desired state, even when the network is under attack. 4.) Proven Scalability: The scalability of the Avalanche consensus protocol is not just theoretical. The protocol has been implemented and tested live in the Avalanche network, demonstrating its ability to handle a large number of validators ([currently 1,238](https://stats.avax.network/dashboard/network-status/)) without compromising on performance or security.
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 [Landslide SDK](/product-guides/slide-sdk) 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. [Interchain Foundation](https://interchain.io/) 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. One important aspect of expanding the Landslide ecosystem is the development of an open source IBC light client, which is being funded by the Interchain Foundation. This light client will allow Avalanche to communicate with other blockchain networks that also support IBC, enabling cross-chain communication and interoperability. LandslideCore and LandslideSDK are important components in the development of this IBC light client, as they provide the necessary tools and infrastructure for building and deploying dApps on the Avalanche network. With the help of LandslideCore and LandslideSDK, developers can create and manage dApps that communicate with other blockchain networks through IBC, expanding the capabilities and reach of the Avalanche network.
Doesn't Cosmos already have very fast finality? It depends on the chain. Take Injective for example, [here](https://www.mintscan.io/injective/validators) is the block explorer.\ Notice that while there are blocks that are 1 second apart, their validator set is 60.\ [The current validator set](broken://spaces/HHJSeBjX6V24RAqZD42m/pages/pEYHsyWmkk631IXdPv5B) 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? [Check this repo.](https://github.com/ConsiderItDone/LandslideCore/blob/0.34.19-lanslide-core/consensus/reactor.go#L516-L606) 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: 1. Sampling: A network subsampling algorithm is used to gather opinions from a random subset of the validator set. 2. Metastability: The algorithm is designed to be meta-stable, meaning that it can tolerate temporary partitions or forks in the network without compromising safety. 3. Binary consensus: Each validator in the subsample independently chooses between two binary values (e.g., 0 or 1) and broadcasts their decision to the rest of the subsample. 4. Repeated subsampling: If the subsample reaches consensus, the decision is propagated up to a larger subsample until the full validator set reaches agreement. Overall, the Avalanche consensus algorithm is designed to be scalable, secure, and fast, with finality times on the order of seconds rather than minutes or multiple seconds.
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 [here](https://github.com/cosmos/ibc/discussions/824). 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 [IBC documentation here](https://ibc.cosmos.network/main/ibc/light-clients/overview.html), and check out a detailed diagram of the AVAX IBC light client [here](/product-guides/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. [The IBC documentation](https://ibc.cosmos.network/main/ibc/light-clients/overview.html) provides a detailed overview of how light clients can be used to verify packet data from other chains. It describes the different components of an IBC light client, including the header, proof, and verification algorithm. Landslide's IBC light client for AVAX verifies and validates packet data from other chains using the existing open source IBC light client specification and appropriate cryptographic algorithms.
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 [generalized abstraction layer](https://twitter.com/burnt_xion/status/1746910163645112445?s=20). 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..
# Roadmap A regularly updated roadmap. | Completed | Current Sprint | Q4 | | ------------------------------------------------------------------- | ---------------------------------------------- | --------------- | | [S](/product-guides/slide-sdk)[lide SDK](/product-guides/slide-sdk) | IBC Light Client testnet | Osmosis testnet | | Avalanche VM | IBC Light Client audit | Archway testnet | | API | Cosmoswap/Osmosis integration | | | Run local private Avalanche network | Andromeda Integration | | | | [Landslide EVM](/product-guides/landslide-evm) | | # 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. CometBFT consensus uses a deterministic finality mechanism, which means that once a block is added to the blockchain, it is considered final and cannot be changed. This makes CometBFT consensus highly secure, as it resists attacks that try to modify or manipulate the blockchain. However, the deterministic nature of CometBFT consensus can also make it slower than other consensus algorithms, as it requires every node in the network to confirm each transaction before it can be added to the blockchain. This can lead to longer confirmation times and slower transaction throughput than probabilistic consensus algorithms like Avalanche consensus. CometBFT consensus is a widely used consensus algorithm in blockchain networks that prioritizes security and determinism. However, its deterministic finality mechanism can make it slower than other consensus algorithms in certain circumstances. # What is Avalanche Consensus? Some background on Snow and Avalanche Consensus. Watch this video for a full explanation. ## Avalanche Consensus Watch [this video](https://twitter.com/avaxdevelopers/status/1667253050451591168?s=12\&t=xQJRN34GuaYYj-D6IhqVTw) for a full explanation with animations. Landslide replaced Tendermint consensus with [Avalanche consensus](https://assets.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf) 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: {% embed url="" %} # Features Landslide Network features ## Features The Landslide Network offers several features that make it an attractive platform for developers and users alike. These include: 1. 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. 2. Native support for IBC: The Landslide Network natively supports IBC, enabling seamless transfer of assets between the Landslide Network and other IBC-enabled chains. 3. 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. 4. 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. # Getting set up How to set up Landslide Core ### Installation 1. Ensure that you have Go installed on your computer. You can download and install the latest version of Go from the official website at . 2. Clone the LandslideCore repository to your local machine by running the following command: ```bash git clone https://github.com/ConsiderItDone/LandslideCore.git ``` 3. Once you have cloned the repository, navigate to the root directory of the repository in your terminal. 4. Build the LandslideCore binary by running the following command: ```go make build ``` This will create the `landslide` binary in the `build` directory. 5. Optionally, you can install the LandslideCore binary system-wide by running the following command: ```go make install ``` This will copy the `landslide` binary to `/usr/local/bin`, making it accessible from anywhere on your system. If you encounter any issues during the installation process, please refer to the documentation or open an issue on the LandslideCore repository for assistance. # 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.](https://www.youtube.com/watch?t=3034\&v=8vkFMYglI6Y\&feature=youtu.be) ### 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 [specification](https://github.com/cosmos/ibc/blob/main/spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md) 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: 1. #### 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. 2. #### 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. 3. #### 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). 4. #### 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. 5. #### 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. 6. #### 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. 7. 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: [GoGoPool](https://docs.gogopool.com/) 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.