Cosmos Hub v20 Upgrade Explained: Permissionless ICS and the New Interchain Security Model

The Cosmos Hub v20 upgrade was a major architectural update that made Interchain Security more open, flexible and operationally efficient. Activated on October 2, 2024, the upgrade introduced Permissionless Interchain Security for opt-in consumer chains, allowed validators outside the Hub’s active consensus set to validate consumer chains and removed the dependency between Cosmos Hub undelegations and consumer-chain liveness.

The upgrade did not radically change how ordinary ATOM holders used the Cosmos Hub. Its most important effects were experienced by consumer-chain teams, validator operators, infrastructure providers and developers building around Interchain Security.

Cosmos Hub v20 should now be understood as a historical infrastructure milestone rather than a current upgrade instruction. Later Gaia versions have superseded it operationally. However, many of the Interchain Security concepts introduced or expanded by v20 remain important for understanding how projects can launch application-specific chains secured through the Cosmos Hub.

What Was the Cosmos Hub v20 Upgrade?

The Cosmos Hub v20 upgrade moved the network to Gaia v20.0.0 and upgraded its Interchain Security implementation to ICS v6.1.0.

Gaia is the application-specific blockchain software that powers the Cosmos Hub. Validators and full-node operators run the gaiad binary to participate in consensus, process transactions, maintain network state and expose infrastructure services.

Gaia v20.0.0 was released as a mandatory update for validators and full-node operators. The coordinated upgrade occurred at block height 22,443,500, on October 2, 2024. The official post-upgrade review reported approximately six minutes of network downtime during the transition.

The upgrade’s three defining changes were:

1. Permissionless ICS for opt-in consumer chains
2. Interchain Security participation for inactive Cosmos Hub validators
3. Removal of unbonding pausing from the provider side of ICS

Gaia v20 also upgraded supporting dependencies, including CosmWasm/wasmd to version 0.53.0 and IBC-Go to version 8.5.1.

What Is Interchain Security?

Interchain Security, commonly abbreviated as ICS, allows a provider chain such as the Cosmos Hub to share some or all of its validator set with separate consumer chains.

A consumer chain remains an independent blockchain with its own application logic, governance model and users. However, instead of building a validator community entirely from zero, it can use validators connected to the Cosmos Hub’s security environment.

This model is designed for teams that want the sovereignty of an application-specific chain while gaining access to an established validator and staking ecosystem.

Interchain Security originally focused on replicated security, where a consumer chain used the provider’s validator set more broadly. The introduction of Partial Set Security created a more flexible model in which only a subset of provider validators may be required or permitted to validate a given consumer chain.

Within that model, consumer chains generally fall into two important categories:

Top N consumer chains require the validators representing the top specified percentage of provider voting power to participate.

Opt-in consumer chains allow individual validators to decide whether they want to support the chain.

This distinction is essential to understanding the Cosmos Hub v20 upgrade.

Permissionless ICS: The Most Important Gaia v20 Feature

Permissionless ICS allows an opt-in consumer chain to register and launch through provider-chain transactions without first receiving approval through Cosmos Hub governance.

Before this feature, joining Interchain Security required a governance proposal. That requirement was logical when the Hub’s validators could be obligated to operate infrastructure for a new consumer chain. Governance allowed ATOM stakeholders to decide whether the network should accept that responsibility.

Partial Set Security changed the risk model.

An opt-in consumer chain does not automatically require every provider validator to participate. Validators voluntarily choose whether to run the chain. Because participation is optional, requiring a full Cosmos Hub governance process for every opt-in chain became less necessary.

Permissionless ICS therefore enables an eligible project to register an opt-in consumer chain by submitting the relevant transaction to the provider chain.

Does Permissionless ICS Remove Governance Completely?

No.

Permissionless ICS applies to opt-in consumer chains. A Top N consumer chain still requires governance because it creates participation obligations for validators that fall within the selected voting-power threshold.

The distinction can be summarized as follows:

Permissionless does not mean that a consumer chain immediately receives substantial economic security.

An opt-in chain still needs enough validators to choose to participate. Official ICS documentation notes that at least one validator must opt in before the configured spawn time for the chain to start. Consumer-chain teams must therefore communicate with validators, define a sustainable reward model and monitor the amount and distribution of participating voting power.

Why Permissionless Consumer-Chain Registration Matters

Permissionless ICS reduces governance overhead during the early stages of launching an application-specific chain.

For a project team, the previous process could require:

• Preparing a formal governance proposal
• Coordinating community discussion
• Waiting through the voting period
• Convincing ATOM stakeholders to approve the launch
• Coordinating validator participation before technical onboarding could proceed

After the Cosmos Hub v20 upgrade, an opt-in chain could begin the registration process through transactions and focus governance effort on its own chain-level decisions.

This potentially improves the launch process in several ways.

Faster Experimentation

Early-stage projects can test consumer-chain architecture without treating every deployment as a Hub-wide governance decision.

Lower Coordination Requirements

Validators remain free to evaluate the project independently and opt in according to their infrastructure capacity, risk assessment and expected rewards.

More Diverse Consumer Chains

The Cosmos Hub can support a wider range of specialized networks without requiring all Hub validators to operate every consumer chain.

Clearer Separation of Responsibility

The Hub provides a security coordination platform, while the consumer-chain team remains responsible for attracting validators, setting suitable parameters and creating an economically viable network.

Permissionless registration lowers one barrier. It does not remove the operational, economic or security responsibilities involved in running a blockchain.

Why Permissionless ICS Introduced Consumer IDs

Permissionless registration created an identity problem.

A provider chain cannot assume that a consumer chain’s chainId is globally unique. When anyone can submit a transaction to register a chain, multiple registrations may use the same proposed chain ID.

Permissionless ICS therefore introduced a provider-assigned consumerId. Each registered consumer chain receives a unique identifier that can be used to manage its configuration and interact with the provider module.

The distinction is useful:

• chainId identifies the blockchain network in its own operating environment.
• consumerId identifies the registered consumer-chain record within the provider’s ICS state.

Developers building management interfaces, explorers, deployment tools or monitoring systems must avoid treating these identifiers as interchangeable.

Inactive Validators Can Participate in Consumer Chains

The second major feature of the Cosmos Hub v20 upgrade allowed validators outside the Cosmos Hub’s active consensus set to validate eligible consumer chains.

Before this change, the set of bonded validators recognized by the staking module was effectively aligned with the validators actively participating in Hub consensus. Validators outside the active set could not use ICS as an alternative path for providing security services to consumer chains.

Gaia v20 separated these concepts more clearly.

After the change:

• Active validators participate in Cosmos Hub consensus.
• Bonded but inactive validators do not participate in Hub consensus.
• Eligible inactive validators can still validate consumer chains that permit their participation.

The technical model increased the number of validators that could remain bonded while introducing a separate provider parameter that limits how many validators are sent to the Hub’s consensus engine.

Active and Inactive Validators Are Not Economically Identical

Inactive validators do not receive every benefit or responsibility associated with active Hub validators.

Official integration documentation states that only active validators:

• Receive ATOM inflation rewards
• Participate in Cosmos Hub consensus
• Can be slashed for Hub downtime
• Vote on behalf of delegators under the relevant governance behaviour

Bonded but inactive validators can still receive delegations and may earn rewards by validating consumer chains.

This creates an additional competitive path for validators that are below the Hub’s active-set threshold.

Instead of waiting exclusively for enough delegation to enter Hub consensus, they may provide infrastructure to opt-in consumer chains, build a performance history and generate consumer-chain rewards.

How Inactive Validators Change Consumer-Chain Security

Allowing inactive validators into ICS expands the potential security supply available to consumer chains.

The change can benefit a consumer chain in several ways.

A Larger Potential Validator Pool

A new chain is no longer limited to validators already inside the Cosmos Hub consensus set.

Reduced Validator-Concentration Risk

Projects can recruit additional operators rather than relying only on a small subset of large Hub validators.

Lower Entry Barriers for Infrastructure Providers

Smaller validators can compete for consumer-chain opportunities even when they do not have enough ATOM delegation to enter the active Hub set.

Reduced Risk of Complete Opt-Out

If active Hub validators choose not to support a particular opt-in chain, eligible inactive validators can still provide the infrastructure required for that chain to operate.

This does not automatically guarantee decentralization. A consumer chain must still evaluate how much stake supports it, how that stake is distributed and whether the validators are operationally independent.

RPC and Indexing Implications of Inactive Validators

The active-versus-bonded distinction also changed how some staking data should be interpreted.

After the feature was introduced, staking queries could report bonded validators that were not members of the Cosmos Hub consensus set. The bonded_tokens value could include stake assigned to all bonded validators rather than only those actively producing Hub blocks.

Applications that need to identify the active consensus validators should query the CometBFT validator set rather than inferring activity solely from a validator’s bonded staking status.

This distinction matters for:

• Block explorers
• Validator dashboards
• Delegation interfaces
• Governance analytics
• Staking-data providers
• Consumer-chain onboarding platforms
• Validator-performance systems

A validator marked as bonded is not necessarily active in Cosmos Hub consensus.

Data products that continued to treat “bonded” and “active” as synonyms after the v20 model risked presenting inaccurate validator-set statistics.

Removal of Unbonding Pausing

The third major component of Gaia v20 simplified how Interchain Security interacted with undelegation operations on the Cosmos Hub.

Earlier versions of ICS used VSCMaturedPackets as part of a process connecting validator-set updates on consumer chains with the completion of unbonding operations on the provider chain.

In simplified terms, an undelegation on the Hub could remain paused while the protocol waited for maturity information associated with consumer chains.

This created a dependency between:

• The liveness and packet flow of consumer chains
• The ability of delegators to complete unbonding on the Cosmos Hub

ADR 018 concluded that this mechanism added considerable complexity and could negatively affect user experience without providing the security guarantees its complexity appeared to imply.

The provider-side changes introduced with the v20-era ICS update removed unbonding pausing. Hub undelegation liveness was no longer dependent on waiting for VSCMaturedPackets from consumer chains.

Did Gaia v20 Remove the Unbonding Period?

No.

Removing unbonding pausing did not eliminate the Cosmos Hub’s normal unbonding period.

The change removed a protocol dependency that could delay an unbonding operation because of consumer-chain communication. Standard staking rules and the configured unbonding duration still applied.

This distinction is important because “removing unbonding pausing” can otherwise be misinterpreted as instant undelegation.

The Removal Was Designed as a Multi-Release Process

ADR 018 separated the change into two stages:

1. The provider stops depending on and processing VSCMaturedPackets.
2. Consumer chains stop producing and sending those packets.

The Cosmos Hub v20 upgrade implemented the provider-side simplification. Consumer-side logic was removed through subsequent ICS development. This staged approach allowed consumer chains to upgrade without requiring every provider and consumer component to change simultaneously.

What Changed for Validators and Node Operators?

Gaia v20 was a mandatory coordinated upgrade for Cosmos Hub validators and full nodes.

Operators needed to:

• Install or build the Gaia v20 binary
• Use Go 1.22 when building from source
• Stop at the designated upgrade height
• Replace the previous Gaia binary
• Restart the node using the upgraded software
• Verify synchronization and consensus participation
• Monitor ICS and validator-set behaviour after activation

The official proposal also described contingency planning. In the event of a serious failure, validators could have coordinated an emergency patch or reverted to the previous Gaia v19.2.0 release. The final upgrade completed successfully with only a short network interruption.

Operators supporting consumer chains had additional considerations:

• Deciding which opt-in chains to validate
• Assigning infrastructure and signing keys
• Estimating operating costs
• Reviewing chain-specific power-shaping parameters
• Monitoring rewards and uptime
• Ensuring consumer-chain participation did not affect Hub operations

Official ICS guidance recommends using separate consumer-chain keys rather than reusing the provider key across multiple chains.

What Did the Upgrade Mean for Consumer-Chain Teams?

The Cosmos Hub v20 upgrade gave consumer-chain teams greater control over their launch pathway, but also placed more responsibility on them.

An opt-in chain could avoid the Cosmos Hub governance process, but it still needed to:

• Configure its consumer-chain parameters
• Register the chain correctly
• Recruit validators
• Design validator incentives
• Prepare genesis and launch coordination
• Establish IBC and CCV infrastructure
• Monitor participating voting power
• Define incident-response procedures
• Communicate technical requirements to operators

Permissionless launch should therefore be understood as permissionless registration and coordination, not infrastructure automation.

A blockchain still requires reliable nodes, genesis coordination, relayers, monitoring, explorers, endpoints and validator participation.

What Did Cosmos Hub v20 Mean for ATOM?

Gaia v20 expanded the possible role of the Cosmos Hub as a security coordination layer for independent blockchains.

Its potential value to the Hub and ATOM ecosystem was based on increasing the number and diversity of chains that could use Interchain Security.

More consumer chains could potentially produce:

• Additional opportunities for Cosmos validators
• Consumer-chain reward streams
• Greater demand for Hub-connected security
• More application-specific networks connected through IBC
• Stronger utility for the Cosmos Hub as an interchain coordination platform

However, the upgrade did not guarantee that every permissionlessly registered chain would succeed or create value for ATOM stakeholders.

Opt-in chains still needed to attract validators and users. Their economic relationship with validators depended on chain-specific rewards, operational costs and security requirements.

The upgrade expanded the available design space. Market adoption remained dependent on the projects using it.

Cosmos Hub v20 in the Wider Evolution of ICS

The significance of v20 becomes clearer when viewed as one stage in a longer Interchain Security roadmap.

Earlier versions established replicated security and provider-consumer communication. Partial Set Security then enabled consumer chains to use subsets of the provider validator set.

Gaia v20 expanded that flexibility through:

• Permissionless opt-in chain registration
• Inactive validator participation
• Simplified unbonding behaviour

Subsequent releases continued developing reward flexibility, consumer-chain configuration, slashing policies, chain-management tools and provider-consumer interoperability.

The architectural direction was consistent: transform ICS from a relatively rigid shared-security model into a configurable platform for launching sovereign Cosmos SDK chains.

Frequently Asked Questions

When did the Cosmos Hub v20 upgrade happen?

The upgrade occurred on October 2, 2024, at Cosmos Hub block height 22,443,500. It moved the network to Gaia v20.0.0 and was completed with approximately six minutes of reported downtime.

What was the main feature of Gaia v20?

The most visible feature was Permissionless ICS, which allowed opt-in consumer chains to register without first passing a Cosmos Hub governance proposal.

Can any consumer chain use the full Hub validator set permissionlessly?

No. Permissionless registration applies to opt-in consumer chains. Top N consumer chains, which require participation from validators representing a specified share of Hub voting power, still require governance approval.

What is an inactive Cosmos Hub validator?

An inactive validator is bonded through the Hub staking system but is not part of the validator set currently participating in Cosmos Hub consensus. After the v20-era change, eligible inactive validators could validate consumer chains that enabled their participation.

Do inactive validators receive ATOM inflation rewards?

Official ICS documentation states that only validators active in Cosmos Hub consensus receive ATOM inflation rewards. Inactive bonded validators may still receive delegations and earn rewards from consumer chains they validate.

Did Cosmos Hub v20 remove ATOM’s unbonding period?

No. It removed the ICS mechanism that could pause undelegation while waiting for consumer-chain maturity messages. The normal staking unbonding period remained in place.

Did ordinary wallet users need to upgrade anything?

No protocol-level software upgrade was generally required from ordinary wallet users. The mandatory binary update applied to validators and full-node operators. Wallets, explorers and data platforms still needed to verify compatibility with changed network and validator-set behaviour.

Is Gaia v20 still the current Cosmos Hub version?

No. Gaia v20 is a historical release and has been superseded by later Cosmos Hub software versions. Its Interchain Security changes remain relevant for understanding the evolution of permissionless consumer-chain deployment.

Why the Cosmos Hub v20 Upgrade Still Matters

The Cosmos Hub v20 upgrade changed the logic of shared security from a governance-heavy onboarding model into a more open platform for validator and consumer-chain coordination.

Its importance came from three related changes:

• Projects could register opt-in consumer chains permissionlessly.
• Validators outside the active Hub consensus set could participate in consumer-chain security.
• Delegator unbonding was no longer dependent on consumer-chain liveness through the previous pausing mechanism.

Together, these changes made Interchain Security more modular.

Consumer chains gained more control over how they launched. Validators gained more ways to compete and provide infrastructure. The Cosmos Hub reduced unnecessary protocol coupling while retaining governance for consumer chains that impose broader participation requirements.

The upgrade did not make chain launches automatic or guarantee economic security. It shifted more decisions from Hub-wide governance to consumer-chain teams and individual validators.

That is the core legacy of the Cosmos Hub v20 upgrade:

Interchain Security became less about requiring one uniform validator model and more about giving sovereign chains configurable access to the Cosmos Hub’s broader security ecosystem.