Cosmos is a technology stack for building and connecting sovereign blockchains. Cosmos SDK defines application logic, CometBFT handles consensus, and IBC uses light clients to verify messages between different chains.
The Cosmos ecosystem is not a single blockchain controlled by a parent chain. Appchains generally have their own validators, governance, and native assets, while Cosmos Hub is only one chain within the ecosystem.

Cosmos SDK divides blockchain applications into modules such as accounts, transfers, staking, and governance. Developers can combine existing modules or write chain-level business logic and custom transaction types.
CometBFT handles peer-to-peer networking, block proposals, and BFT consensus. ABCI is the interface between the consensus engine and the application state machine. The application returns transaction execution results and a new state commitment.
| Layer | Primary responsibility |
|---|---|
| CometBFT | Network propagation, block production, and Byzantine fault-tolerant consensus |
| ABCI | Connecting consensus events with application execution |
| BaseApp | Routing transactions, managing state versions, and defining execution semantics |
| Cosmos SDK modules | Defining business rules for accounts, banking, staking, governance, and more |
| IBC | Verifying and transmitting interchain data packets |
Separating consensus from the application means teams do not need to rebuild an entire network protocol. However, custom modules can still introduce state-machine vulnerabilities or incompatible upgrades.
An appchain places business rules at the protocol layer, allowing it to customize fees, validators, governance, transaction ordering, and native assets. A general-purpose smart contract chain lets many applications share one execution environment and security budget.
| Appchain advantage | Corresponding cost |
|---|---|
| Protocol-level customization | Nodes, upgrades, and clients must be maintained |
| Dedicated blockspace | The chain must establish its own validator set and economic security |
| Independent fees and governance | Governance mistakes are borne by the chain itself |
| Ability to connect through IBC | Light clients, channels, and relayer services must be maintained |
Using Cosmos SDK does not automatically give an appchain the protection of Cosmos Hub's validators. Unless an additional shared-security model is adopted, the cost of attacking a chain depends on its own stake and validator distribution.

IBC stores a light client of the counterparty's consensus state on-chain. A relayer reads packets and proofs from the source chain and submits them to the destination chain, which verifies the proofs itself instead of directly trusting the relayer.
After a connection is established, channels deliver packets to specific application modules, such as token transfers. Timeouts and acknowledgement packets help both chains handle messages that were not delivered or have already been executed.
| Component | Trust boundary |
|---|---|
| Light client | Verifies the counterparty's chain headers and consensus proofs |
| Relayer | Delivers data and should not have the power to forge valid proofs |
| Connections and channels | Bind clients and application ports on both sides |
| Application module | Determines how receiving a packet changes state |
IBC security still depends on the finality of both chains. If the source chain is compromised, the destination chain's light client may accept a malicious state signed by that chain's valid consensus process.
Cosmos Hub is an independent blockchain built with Cosmos SDK and IBC. ATOM is used for its staking, governance, and fees. The Hub can provide routing, account, and security-related services, but it is not a central control layer for every Cosmos SDK chain.
Other chains have their own native assets, validators, and governance. Attributing all activity in the Cosmos ecosystem to ATOM's value, or assuming all IBC assets are guaranteed by the Hub, confuses these protocol relationships.
To compare this model with Polkadot's shared security, read the Polkadot guide. For the broader public-chain landscape, see the 2025 Overview of Leading Blockchain Ecosystems.
No. A chain must integrate and enable the relevant IBC modules, light clients, and channels. Governance may also suspend a specific client or connection.
The source-chain asset is generally locked or accounted for, while the destination chain mints a voucher containing path information. When the asset returns along its original path, the voucher is burned and the source-chain asset is released.
Being offline by itself generally delays messages rather than granting the ability to forge proofs. Users still need to consider timeouts, channel status, and the security of both chains.
That description can be misleading. The Hub is an important appchain and IBC participant, but Cosmos SDK chains can operate independently and do not have to connect through the Hub to communicate with one another.


