[PAUSED] [DRAFT] Reduce the Cosmos Hub active validator set from 180 to 100

Hub Proposals Parameter Change
1

Change log

  • 2026-07-13 Created initial post

Summary

This proposal aims to reduce the Cosmos Hub active validator set from 180 to 100 by updating the on-chain max_provider_consensus_validators parameter (provider module), and to reduce the bonded validator cap from 200 to 100 by updating max_validators (staking module), aligning both at 100.

The creation of new consumer chains has been disabled at the protocol level since the gaia v27 upgrade. The two active consumer chains, comdex-1 and elys-1, are secured almost entirely by validators within the top 100 by stake, so reducing the bonded cap to 100 has minimal impact on them (see Background). Aligning both parameters also keeps the active set at 100 if the provider module is later removed, at which point the active set would revert to being governed by max_validators.

The objective is to improve the long-term health, sustainability and operational quality of the validator set while maintaining a high level of security.

A validator set where operators can sustainably run professional infrastructure is expected to be healthier than a large validator set containing economically unsustainable operators.

A leaner validator set may also provide a stronger foundation for future infrastructure improvements and protocol upgrades, including potential future requirements such as Dual VM and EVM-related workloads.

This proposal is focused solely on validator set size. No other protocol parameters are modified.

Background: active set vs bonded set

The Cosmos Hub uses two separate parameters for validator counts. max_validators (staking module, currently 200) is the bonded cap. max_provider_consensus_validators (provider module, currently 180) determines how many of those bonded validators actually enter consensus, sign blocks and earn rewards. The 20 bonded validators outside the active set do not sign Hub blocks and earn no Hub rewards; they remain bonded and can be opted in to secure Partial Set Security (PSS) consumer chains.

The Hub currently secures two active consumer chains, comdex-1 and elys-1, and the creation of new consumer chains has been disabled at the protocol level since the gaia v27 upgrade. As of 13 July 2026, every validator securing comdex-1 is within the top 100 by stake, and every validator securing elys-1 is within the top 100 except for one validator ranked below 100 (holding about 2,000 ATOM, with a moniker indicating it is shutting down). Reducing the bonded cap to 100 would therefore, among the validators currently securing these chains, unbond only that single low-ranked validator on elys-1. This proposal sets both parameters to 100 on that basis. Aligning both values also ensures the active set stays at 100 if the provider module is later removed, since the active set would then revert to being governed by max_validators alone.

Details

The Cosmos Hub currently operates one of the largest active validator sets in the Cosmos ecosystem.

While a large validator set increases decentralization in theory, the current stake distribution shows that the lowest-ranked validators contribute very little to the network’s effective economic security while increasing operational complexity.

Consensus in CometBFT is finalized once validators representing more than 66.67% of the bonded stake have signed a block. Today, approximately the top 16 validators already represent this threshold.

Validators ranked from 101 to 180 collectively represent only a small fraction of the bonded stake. Based on current distribution, these validators secure roughly 2% of bonded ATOM, meaning the measurable security impact of removing these slots is expected to be limited.

Reducing the validator set is therefore expected to improve the operational quality of the active validator set while preserving a high level of economic security.

Benefits include:

  • healthier validator economics by concentrating rewards among sustainable operators;
  • improved operational standards and infrastructure quality;
  • lower probability of unreliable or poorly maintained validators remaining active;
  • improved governance participation and upgrade coordination;
  • stronger delegator protection by reducing exposure to inactive, underfunded or poorly maintained validators;
  • more effective delegation programs, as support is concentrated among fewer sustainable operators instead of being diluted across a larger set;
  • stronger support for future infrastructure requirements, including potential Dual VM and EVM-related workloads;
  • consistency with validator set reductions already implemented by other Cosmos chains. Osmosis, for example, progressively reduced its validator set from 150 to 120, then 100 and eventually 70 without significant security or decentralization issues.

Potential drawbacks:

  • reducing the validator set may raise concerns about decreased decentralization, as fewer validators participate directly in consensus;
  • some smaller or newer validators may be excluded from the active set, potentially limiting opportunities for new entrants and reducing diversity among operators;
  • there is also a risk that stake concentration could increase among top validators if delegators do not actively redistribute their stake;
  • additionally, removing validators may impact community representation, as fewer operators participate in governance discussions and decision-making.

Implementation

If this proposal receives sufficient community support, the on-chain parameter change is intended to be submitted on 1 August 2026.

This transition period is intended to provide validators, delegators and infrastructure providers with adequate time to prepare before the change takes effect.

During this period:

  • delegators staking with validators that may leave the active set will have sufficient time to review their validator choice, including considering validators eligible for the ICF delegation program, and redelegate if they wish, avoiding unnecessary interruptions to staking rewards;
  • affected validators will have time to notify their delegators, communicate their plans and facilitate an orderly transition;
  • wallets, explorers, staking providers and other ecosystem services will have time to verify compatibility and prepare for the updated validator set.

The objective is to ensure that the validator set reduction is implemented in a predictable and coordinated manner, minimizing disruption for all participants while allowing the ecosystem to prepare in advance.

The proposed implementation timeline is therefore:

  1. Forum discussion and community feedback.
  2. Final review of the proposal.
  3. Submission of the on-chain MsgUpdateParams proposal on 1 August 2026.
  4. Standard governance voting period.

Q&A

Q: Why discuss reducing the validator set?

A: The Cosmos Hub currently has one of the largest active validator sets in the Cosmos ecosystem. This proposal asks whether reducing that number to 100 validators would provide a healthier long-term balance between decentralization, security, operational quality and future scalability.

Q: Does reducing the validator set reduce security?

A: No. Consensus in CometBFT is finalized once more than 66.67% of the bonded voting power has signed a block. Today, roughly the top 16 validators already control this threshold. Validators near the bottom of the active set collectively secure only a small percentage of the network. Removing these validators is expected to have a limited impact on economic security while improving the overall quality of the validator set.

Q: Why can fewer validators improve validator quality?

A: Running a professional validator requires reliable infrastructure, monitoring systems, backups, security practices and operational expertise. Lower-ranked validators often operate with very limited economics. When validator operations become unprofitable, operators may be forced to reduce costs through cheaper infrastructure, limited monitoring or reduced redundancy. A smaller validator set where every operator can sustainably maintain professional infrastructure may provide better long-term network reliability than a large validator set containing economically unsustainable operators.

Q: Will remaining validators earn significantly more?

A: Only marginally. Validator rewards follow delegated stake, not the number of validator slots. Because the validators expected to leave collectively represent only about 6,800,000 ATOM out of roughly 331,000,000 bonded ATOM, around 2%, the additional rewards distributed among remaining validators would also be limited. The main goal of this proposal is therefore not revenue redistribution, but creating a healthier validator ecosystem.

Q: Does this proposal create centralization concerns?

A: Reducing the number of active validators naturally creates a perception of reduced decentralization. However, decentralization should be evaluated through effective voting power distribution, geographic diversity, operational quality and validator independence rather than only the number of active slots. The proposal aims to remove economically unsustainable validators while maintaining a strong and diverse validator ecosystem.

Q: Will this immediately make the Hub faster?

A: No. Reducing the validator set alone does not create 1-second blocks. The main benefit is reducing operational variability by removing slower potential proposers. Experiences from other Cosmos chains suggest validator set reductions provide improvements measured in milliseconds rather than seconds. The current block time is primarily influenced by consensus timing configuration. Any future block time reduction would require separate technical work and governance discussion.

Parameters and new values

This proposal submits two MsgUpdateParams messages. The provider module message sets max_provider_consensus_validators from 180 to 100. The staking module message sets max_validators from 200 to 100. All other parameters in both messages remain unchanged from their current on-chain values.

{
  "messages": [
    {
      "@type": "/interchain_security.ccv.provider.v1.MsgUpdateParams",
      "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "params": {
        "template_client": {
          "chain_id": "",
          "trust_level": {
            "numerator": "1",
            "denominator": "3"
          },
          "trusting_period": "0s",
          "unbonding_period": "0s",
          "max_clock_drift": "10s",
          "frozen_height": {
            "revision_number": "0",
            "revision_height": "0"
          },
          "latest_height": {
            "revision_number": "0",
            "revision_height": "0"
          },
          "proof_specs": [
            {
              "leaf_spec": {
                "hash": "SHA256",
                "prehash_key": "NO_HASH",
                "prehash_value": "SHA256",
                "length": "VAR_PROTO",
                "prefix": "AA=="
              },
              "inner_spec": {
                "child_order": [
                  0,
                  1
                ],
                "child_size": 33,
                "min_prefix_length": 4,
                "max_prefix_length": 12,
                "empty_child": null,
                "hash": "SHA256"
              },
              "max_depth": 0,
              "min_depth": 0,
              "prehash_key_before_comparison": false
            },
            {
              "leaf_spec": {
                "hash": "SHA256",
                "prehash_key": "NO_HASH",
                "prehash_value": "SHA256",
                "length": "VAR_PROTO",
                "prefix": "AA=="
              },
              "inner_spec": {
                "child_order": [
                  0,
                  1
                ],
                "child_size": 32,
                "min_prefix_length": 1,
                "max_prefix_length": 1,
                "empty_child": null,
                "hash": "SHA256"
              },
              "max_depth": 0,
              "min_depth": 0,
              "prehash_key_before_comparison": false
            }
          ],
          "upgrade_path": [
            "upgrade",
            "upgradedIBCState"
          ],
          "allow_update_after_expiry": true,
          "allow_update_after_misbehaviour": true
        },
        "trusting_period_fraction": "0.66",
        "ccv_timeout_period": "2419200s",
        "slash_meter_replenish_period": "3600s",
        "slash_meter_replenish_fraction": "0.05",
        "consumer_reward_denom_registration_fee": {
          "denom": "uatom",
          "amount": "10000000"
        },
        "blocks_per_epoch": "600",
        "number_of_epochs_to_start_receiving_rewards": "24",
        "max_provider_consensus_validators": "100"
      }
    },
    {
      "@type": "/cosmos.staking.v1beta1.MsgUpdateParams",
      "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "params": {
        "unbonding_time": "1814400s",
        "max_validators": 100,
        "max_entries": 7,
        "historical_entries": 10000,
        "bond_denom": "uatom",
        "min_commission_rate": "0.050000000000000000"
      }
    }
  ]
}

Governance votes

YES - You support reducing the Cosmos Hub active validator set from 180 to 100 validators.

NO - You do not support reducing the Cosmos Hub active validator set from 180 to 100 validators.

NO WITH VETO - A NoWithVeto vote indicates a proposal either (1) is deemed to be spam, i.e. irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of NoWithVeto votes is greater than one-third of total votes, the proposal is rejected and the deposits are burned.

ABSTAIN - You wish to contribute to quorum but formally decline to vote either for or against the proposal.

1 Like
2

Nah this ain’t it bro.

3

Hey @Guinch_Roze, thanks for putting this together!

We’re directionally supportive of a smaller, more sustainable validator set, and we’ve mentioned in several places that consolidation could align well with where the Hub roadmap is heading. But this isn’t just a minor change, and it shouldn’t be treated as one in a short 2-week discussion.

The problem the proposal correctly identifies is that the economics at the bottom of the active set don’t work for the operators themselves. Validators securing ~2% of stake collectively can’t cover professional infrastructure, monitoring, and redundancy from the rewards that stake generates. Keeping operators in a position where validating the Hub is a money-losing hobby isn’t doing them, their delegators, or the network any favors. A right-sized set is one where every active operator can actually sustain a professional operation.

However, the current economic model isn’t fixed in stone. The tokenomics redesign work underway is looking at how validators are rewarded, not just how many there are, and the future may hold more differentiated ways for operators of different sizes to participate in and earn from the Hub than the single stake-weighted model we have today. This is why sequencing matters. We don’t know that 100 is the right number. It could be less, it could be more.

So before we make a huge cut that, at this time, is largely based on vibes, I think this should be paused until two important things are done.

1. Sequencing: this decision should be informed by the tokenomics research

Validator set size, reward distribution, and stake concentration dynamics are in scope for the ongoing ATOM tokenomics research work. Phase 2 will produce exactly the kind of modeling that should inform a decision like this one (optimal set size included).

There is virtually zero harm to the network in waiting for that research before acting. The status quo isn’t causing acute damage, and the ~2% of stake at issue isn’t a security risk. But there is hard-to-reverse risk in cutting 80 operators based on a rough directional argument and finding out afterward that we got the number or the sequencing wrong.

Before we make decisions around reducing the size of the set, we’d strongly prefer waiting until after Phase 2 rather than ahead of it, so we’re making any calls around valset size with data and it’s included within a broader plan. Phase 2 specifically goes into the nitty-gritty of simulating these configurations and how they affect rewards, so we come out of it with a phased plan with clear tradeoffs.

2. Any valset reduction should be done in stages

Cutting 80 validators in a single parameter change is risky. As stated above, we don’t know that 80 is the correct number to cut. The big open question is how the ATOM delegated to validators ranked 101-180 behaves once those validators fall out of the set:

  • Does it redelegate to active validators? (Ideal)

  • Does it sit idle with unbonded validators? (This passively increases voting power concentration among the top of the set)

  • Does it unbond and exit the network entirely? (Worst-case scenario)

Moreover, we need to track how the performance and stability of the Hub change over time.

The only safe way to find out is to cut in smaller blocks (20-30 slots at a time) and monitor stake movement between each step before proceeding to any additional cuts. Osmosis essentially did this. They stepped down progressively (150 → 120 → 100 → 70), evaluating along the way to find out what the best set size was. We’d scope this out as part of the phase 2 workstream and, ideally, get lots of feedback from validators themselves in advance before making changes.

Given both points above, submitting on-chain on August 1 feels premature to me. I’d suggest pausing this for now pending the outcome of the tokenomics research and then revisiting with a concrete plan that includes changes to validator compensation (if applicable) and a phased rollout of any cut with lots of notice given beforehand.

That said, thank you, Guinch, for the proposal and for driving the discussion. We should keep the conversation going here on the fine details ahead of Phase 2, I think that’s still very productive, and would love to hear more from validators/the community on this.

2 Likes
4

This could be seen as a malicious and harmful proposal for the Cosmos hub. We have seen recently major validators like Cosmostation, Citadel, and others winding down all operations and validator health has become a critical issue now. Cosmos Labs already emphasized before that there are no plans for the active set reduction, and any reduction would be done slowly and gradually, certainly not an extreme and sudden almost 50% cut of the active set.

Why are you even mentioning these projects? They are totally irrelevant, seems by now even not listed on coingecko.

Really? To put an example, we are one of the few validators contributing here in the governance forum for years, helped to dismantle the AADAO and saved millions for the Cosmos hub, and now trying to support with the implementation of the VP tax, do you think eliminating validators like us is good for the Cosmos hub?

Totally not true. Nothing changes mostly for the remaining 100 validators, while you kill almost 50% of the active set including many contributing validators like ourselves!

Also a flawed argument, higher VP doesn’t imply better infrastructure or quality of engineers

Same flawed argument, higher VP power doesn’t imply higher governance participation or forum participation, if anything the opposite, with the top validators never in this forum and some never voting

What do you mean by this? Delegators can get harmed by double sign, downtime slashing or validator in inactive set. Double sign slashing is very rare and the risk is not related to VP. Downtime slashing risk also is not related with VP. Of course if a delegator delegates to a validator in position 180th there is some risk that it may go to the inactive set but they can easily minimize this risk, a 50% active set reduction is not needed for this

Are you even following updates? Now it is a requirement to participate in the Cosmos hub testnet to be eligible for the ICF delegation program and the number of validators selected went down from over 70 to around 50 which will be a 50% delegation increase. Again, a 50% reduction of the active set is NOT needed for a more effective ICF delegation program

The opposite, Monad and other networks are increasing the number of validator and decentralization which adds value to the networks rather than centralizing more

Why are you even talking about Osmosis? They tried to get the full Cosmos hub CP as exit liquidity and their governance proposal nearly passed, if actions taken by Osmosis were so successful why they came for the rescue to the Cosmos hub, if anything this Osmosis example is another reason against your proposal

Strongly against this proposal and will vote NO

2 Likes
5

Thank you for the detailed response.

I think the arguments you’ve raised are valid, particularly regarding the importance of sequencing and having proper modeling before making a decision of this magnitude.

Based on your feedback, I’ll pause this proposal and wait for the results of Phase 2 of the ATOM tokenomics research, as suggested by Robo. It makes sense to revisit validator set size once we have stronger data and a broader understanding of the trade-offs involved.

I also appreciate you clarifying several points that were not widely known within the community. Having more transparency around the ongoing research helps everyone better understand where this discussion fits into the broader roadmap.

For now, let’s continue gathering feedback and refining the discussion so that, when the time comes, the community can make an informed decision based on data rather than assumptions.

Finally, thank you to the Hub Unit for taking the time to engage on what is clearly a very sensitive topic. In my opinion, validator sustainability, decentralization and the long-term structure of the validator set are among the most important subjects for the future of the Cosmos Hub, and I’m glad to see they’re being actively considered.

2 Likes
6

The best and most comprehensive answer, to which there is nothing to even add… I fully support it!

1 Like
7

Good idea and reasoning. I would start with 150 perhaps though.