> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hyperlane.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Cosmos SDK Module
The SDK module enables seamless interchain communication by integrating Hyperlane directly into Cosmos SDK-based chains. This module provides a permissionless way for Cosmos chains to communicate with external ecosystems, including EVM and other blockchains.
While Hyperlane already supports Cosmos chains via [CosmWasm](https://github.com/many-things/cw-hyperlane?tab=readme-ov-file), this module expands accessibility by enabling Cosmos SDK chains—regardless of CosmWasm support—to leverage Hyperlane’s interoperability capabilities.
## Key Features
* **Hyperlane Compatibility:** This module fully implements the Hyperlane messaging protocol, enabling seamless cross-chain functionality across all Hyperlane-compatible chains.
* **Hyperlane Warp Routes (HWR):** Leveraging the core functionality, tokens can be created and transferred across all Hyperlane-compatible chains.
* **End-to-End Interop Solution**: Implements messaging, transport, and security modules of the Hyperlane cross-chain interoperability framework for Cosmos SDK-based chains.
* **Permissionless & Open-Source**: Anyone can deploy and configure the module to fit their needs without relying on intermediaries.
* **Built by KYVE**: Developed by the [KYVE](https://www.kyve.network/) team to extend Cosmos interoperability beyond IBC.
## Module Overview
### `x/core`
The `core` module is intended to implement the fundamental functionalities of the Hyperlane protocol to dispatch and process messages, which can then be used by applications like `warp`. It includes mailboxes and registers hooks that are implemented in the submodules.
#### Mailbox
* Responsible for dispatching and processing messages
* Ensures replay protection
* Specifies `default` or `required` hooks like `IGP` or `MerkleTreeHook`
* Calls registered `PostDispatch` hooks
* Important methods:
* `dispatch()`
* `process()`
#### Submodules
Interchain Security and Post Dispatch are submodules with dedicated keepers and restricted access to the core keeper. This architecture was designed to facilitate extensibility, allowing developers to integrate their own implementations seamlessly.
#### `01_interchain_security`
This submodule implements the ISM logic and is responsible for verifying that interchain messages being delivered on the destination chain were *actually sent* on the origin chain. The modular design allows developers to easily add custom ISM implementations. Currently, three ISM types are available: `MessageIdMultisig`, `MerkleRootMultisig`, and `Noop`.
```
type IInterchainSecurityModule interface { Verify(ctx context.Context, ismId HexAddress, metadata []byte, message HyperlaneMessage) (bool, error)}
```
**`MultisigIsm`**
* Verifies that `m` of `n` validators have signed the validity of a message
* `MessageIdMultisig` → censorship-friendly, minimizes gas
* `MerkleRootMultisig` → censorship resistance guarantee
* Important methods:
* `verify()`
#### `02_post_dispatch`[](#02_post_dispatch "Direct link to 02_post_dispatch")
This submodule implements the PostDispatch interface and the hook instances like the `InterchainGasPaymaster` or `MerkleTreeHook`. The modular design allows developers to easily add custom PostDispatch hook implementations.
```
type PostDispatchHook interface { HookType() uint8 SupportsMetadata(metadata any) bool PostDispatch(ctx sdk.Context, metadata util.StandardHookMetadata, message util.HyperlaneMessage, maxFee sdk.Coins) (sdk.Coins, error) QuoteDispatch(ctx context.Context, hookId HexAddress, metadata util.StandardHookMetadata, message HyperlaneMessage) (sdk.Coins, error)}
```
**`InterchainGasPaymaster`**
* Allows message sender to pay fees to the relayer to deliver a message on the destination chain
* `DestinationGasConfig` is used to determine the correct `InterchainGasPayment`
* Important methods:
* `postDispatch()`
* `payForGas()`
* `claim()`
**`MerkleTreeHook`**
* Inserts dispatched messages into an on-chain Merkle tree
* Required for `MessageIdMultisig` and `MerkleRootMultisig` ISMs
* Important methods:
* `postDispatch()`
* `InsertedIntoTree()` *(event)*
### `x/warp`
`warp` builds on-top of the core functionality by enabling token creation and cross-chain transfers between chains already connected via Hyperlane. These tokens leverage modular security through specific ISMs.
* Currently, two token types are available:
1. **Collateral:** Locks tokens as collateral on the source chain for cross-chain transfers.
2. **Synthetic:** Mints new tokens on the destination chain to represent the original tokens.
* Important methods:
* `createToken()`
* `remoteTransfer()`
* `enrollRemoteRouter()`
## HWR - Remote Transfer Lifecycle
#### `Dispatch()`
#### `Process()`
## EVM / Cosmos SDK Differences
### EVM ≠ Cosmos SDK
1. Instances instead of Contracts
2. IDs instead of Contract addresses
3. Tokens: Cosmos uses denoms (including native denoms and IBC denoms) instead of token contract addresses, so IGP config must specify a `denom`. There is no `NativeCollateralToken` contract abstraction.
### Tool Integration
The Hyperlane CLI supports the Cosmos SDK module for deploying and managing core infrastructure and Warp Routes. The CLI handles Cosmos-specific details like bech32 address derivation, denom-based token references, and message-based deployment automatically.
Step-by-step core deployment guide
Bridge tokens between Cosmos chains
For cross-chain routes, see the [EVM ↔ Cosmos HWR Guide](/docs/guides/warp-routes/evm-cosmos-warp-route-guide) or the [Cosmos ↔ SVM HWR Guide](/docs/guides/warp-routes/cosmos-svm-warp-route-guide).