Cosmos and Polkadot both connect many specialized blockchains, but they split responsibility differently. A Cosmos chain is sovereign: it recruits its own validators and connects to other chains through IBC. A Polkadot parachain rents blockspace and security from one shared validator set, paying in DOT, and talks to other chains using XCM. The central trade-off is independence versus inherited security, and both networks have changed course recently.
What problem do Cosmos and Polkadot both solve?
Both projects are built around app-chains: a blockchain dedicated to one application or a narrow set of them. An app-chain does not compete with thousands of unrelated apps for space, and it can set its own fee rules, upgrades and on-chain governance.
Running a separate blockchain creates two hard problems. It needs security, and it needs to talk to other chains. Cosmos and Polkadot give different answers to both.
How Cosmos works
Cosmos is a family of independent chains that share software, not a single chain. Developers typically build with the Cosmos SDK and the CometBFT consensus engine, then launch their own proof-of-stake network.
Each chain recruits its own validators and backs them with its own token. The Cosmos Hub is one chain in this family, secured by 180 validators according to its documentation. A common misconception is that every Cosmos chain depends on the Hub. IBC connections can be made between chains directly, and the Hub does not sit underneath the whole family.
The cost of this freedom is that security is only as strong as the chain's own stake. A new chain with a small, cheap token has little protecting it.
How Polkadot works
Polkadot has a central relay chain and many connected parachains. Its documentation describes the split like this: parachains propose blocks, and the relay chain's validators check them for availability and validity before finalizing them.
A parachain still runs its own nodes, called collators, which maintain the chain and build block candidates. It does not need its own validator set, because the relay chain's validators secure its state transitions. Each parachain keeps its own logic, economy and governance.
Polkadot's stake rules also changed in 2026. Since July 6, 2026, nominators, the holders who back validators with DOT, can no longer be slashed. Validators keep that risk on their own stake.
IBC vs XCM: two different kinds of thing
IBC (Inter-Blockchain Communication) and XCM (Cross-Consensus Messaging) are often compared directly, but they sit at different levels. IBC is a protocol built on light clients, relayers and cryptographic proofs. XCM is a message format. Polkadot's wiki states plainly that "XCM cannot actually send messages between systems."
| IBC | XCM | |
|---|---|---|
| What it is | Transport and application protocol | Message format and language |
| How messages move | Off-chain relayers carry packets and proofs | Separate transports such as HRMP and XCMP |
| How the receiver trusts it | Its light client checks the sending chain's consensus | Within Polkadot, both parachains are validated by the relay chain's validators |
| Delivery feedback | Acknowledgment, or a refund on failure | "Fire and forget," with a separate message for any reply |
| Reach | More than 115 chains by IBC's own count, and Ethereum since April 2025 | Mainly the Polkadot ecosystem, though the format is not limited to it |
On Polkadot today, most messages pass through HRMP, a stopgap that stores messages in relay chain storage. The wiki says the intended replacement, XCMP, is "not yet fully implemented." Channels are one-way and require a DOT deposit.
A worked example: 100 ATOM over IBC
Say you send 100 ATOM from the Cosmos Hub to Osmosis, an IBC-connected exchange chain. The ICS-20 transfer standard handles it:
- Escrow. The Hub locks your 100 ATOM in an escrow account.
- Relay. An off-chain relayer carries the packet and a proof to Osmosis. Relayers move data, but the chain checks the proof itself.
- Verify and mint. Osmosis checks the proof against its light client of the Hub, then mints 100 vouchers with an
ibc/...name. - Return. To go back, you send the vouchers along the same path. Osmosis burns them, and the Hub releases your ATOM.
Your vouchers are only as safe as both chains. If a chain's validators were corrupted, they could mislead the light client that other chains rely on. This is one way IBC differs from the external bridges that rely on their own signers: it has no separate signer group, but it does inherit each chain's security.
Paths matter too. The denomination records the route, so the same ATOM sent through different chains ends up as different tokens that can't simply be swapped one for one.
Sovereign vs shared security, and the end of Interchain Security on the Hub
The sovereign model has one main risk: thin security. The shared model has a different one, which is reliance on a common base layer and its rules.
Cosmos tried a middle path. Interchain Security let Cosmos Hub validators also secure "consumer" chains, which paid fees or inflation in return. Many guides still present it as Cosmos's answer to Polkadot. That is out of date.
- February 2026. A forum proposal argued for deprecation, citing little demand, consumer revenue too small to justify validators' costs, and extra risk for validators. It noted that Neutron had already left in March 2025.
- March 2026. Proposal 1025 passed, with an upgrade that stops new consumer chains.
- September 2026. Proposal 1052 passed, with an upgrade that removes Interchain Security from the Hub. The Hub's documentation now lists gaia v28, the software line from that upgrade.
As of November 2026, then, Cosmos means sovereign chains by default. Teams wanting rented security from Ethereum stakers may look at restaking instead, which has its own risks.
Shared security also has clear limits. It protects consensus, not application logic. In August 2022, a misconfigured pool on the Acala parachain let users error mint about 3 billion aUSD, Acala's stablecoin. Polkadot's validators could not prevent that, because the chain was following its own rules. Acala's holders and its governance dealt with the fallout.
Coretime and JAM: where Polkadot is heading
Polkadot used to allocate parachain slots by auction, with long leases. That ended on September 19, 2024, when existing leases were converted to coretime, a way of buying validator capacity as you need it.
There are two ways to buy it:
- Bulk coretime. A fixed 28-day period, bought in DOT, represented as an NFT that can be split, shared or resold. Keeping it assigned to one parachain qualifies for a price-capped renewal.
- On-demand coretime. Pay in DOT per block, and only for what you use.
Some rough numbers show what that buys. A chain producing a block every 6 seconds on one core for a whole bulk period gets up to 403,200 blocks (28 days × 86,400 seconds ÷ 6). A quiet app that needs only occasional blocks can pay per block instead. If a parachain lets bulk coretime lapse without buying on demand, it keeps its ID but loses access to a core, so it stops producing blocks until it buys more.
The next step is JAM, the Join-Accumulate Machine. Polkadot's wiki calls it a successor to the relay chain, with parachains becoming one of the services that run on it. As of November 2026 it is not live on mainnet. Parity's September 10, 2026 post lists four projects, including a production node and a service to handle parachain finality, but gives no date for the switchover.
Cosmos and Polkadot compared
| Question | Cosmos | Polkadot |
|---|---|---|
| Basic unit | Sovereign app-chain | Parachain |
| Who secures it | Its own validators | Relay chain validators, with its own collators |
| What backs security | The chain's own token | Stake on the relay chain |
| Ongoing cost of security | Rewards to attract validators, often from its own token | Coretime paid in DOT |
| Cross-chain standard | IBC | XCM over Polkadot's transports |
| Who sets the rules | The chain itself | The parachain, within rules set by Polkadot's governance |
| Main failure mode | Weak stake on a small chain | Dependence on the relay chain and on keeping coretime |
| Direction in 2026 | Shared security removed from the Hub; IBC reaching beyond Cosmos | Coretime live; JAM in development |
Which trade-offs suit whom?
No design wins outright. These are the patterns to look for when choosing to build on, or use, either network.
Cosmos tends to fit a team with a strong community and a token that can attract validators, or one that needs control over its validator set, fees or upgrades. It also suits teams that expect to bridge widely through IBC. The team takes on validator recruitment and the risk of thin security.
Polkadot tends to fit a team that wants strong security from day one and would rather budget for coretime than build a validator community. The team accepts paying in DOT and relying on Polkadot's governance and roadmap, including the coming JAM transition.
Neither may be needed. Plenty of apps do fine as a smart contract on an existing chain or a layer 2. An app-chain makes most sense when the app truly needs custom rules or dedicated capacity.
As a user, ask three things about any chain in either family. How much stake secures it? Which route did your bridged token take? Who can upgrade its code? You can find more on these questions in our coverage of bridges and governance.
Key takeaways
- Both networks support app-chains, but Cosmos chains secure themselves while Polkadot parachains rent security from the relay chain.
- IBC is a protocol that moves and verifies messages. XCM is a format that needs a separate transport.
- The Cosmos Hub voted in 2026 to remove Interchain Security, so older descriptions of shared security on Cosmos are out of date.
- Polkadot replaced slot auctions with coretime in 2024, and JAM has no mainnet date as of November 2026.
- Shared security does not stop application bugs, as Acala's 2022 error mint showed.
- The practical choice is who carries the cost of security: a chain's own token and validators, or rent paid to a shared base layer.
Sources
Get the weekly commit
New blockchain deep dives every week.