[LAST CALL] CHIPs signaling phase : Validator Vote Power Cap

Hub Proposals CHIPs
1

Cosmos Hub Improvement Proposal (CHIP): Validator Vote Power Cap

Summary

This proposal introduces a vote power cap for validators in governance. The mechanism would ensure that no validator can unilaterally cast more than a fixed share of delegated voting power (e.g. 3%), while preserving both:

  • The autonomy of delegators, whose votes are never reduced or capped if cast directly.
  • The self-delegated stake of validators, which remains fully effective and is not subject to the cap.

This aims to mitigate governance centralization risks while maintaining the security and economic integrity of the staking system.

Motivation

The Cosmos Hub governance process inherits validator voting power from the staking module. Today, large validators may control substantial fractions of the voting power, particularly if delegators do not vote directly. This concentration creates several issues:

  • Governance centralization: A handful of validators can disproportionately influence outcomes.
  • Reduced delegator sovereignty: Passive delegators effectively cede control to their validator, potentially against their intended interest.
  • Misalignment of roles: Validators are primarily responsible for network security and operations, not unilateral political decision-making.

The proposed mechanism seeks to rebalance governance power by enforcing a ceiling on how much delegated vote power a single validator can cast. This nudges the system toward broader participation, reduces systemic risks, and aligns with the Hub’s values of neutrality and decentralization.

Proposal Design

Core Mechanism

  1. Validator Vote Cap:

    • Each validator’s delegated voting power is capped at a fixed fraction of total voting power (e.g., 3%).
    • Self-delegated stake is excluded from this cap and always counted fully.

  2. Delegator Override:

    • Any delegator voting directly retains full voting rights, independent of the cap.
    • Only delegated stake that defaults to validator voting is subject to reduction when a validator exceeds the cap.

  3. Adjustable Parameter:

    • The cap (expressed as a percentage of total voting power) is a governance parameter that can be modified through on-chain governance.

Example

  • A validator controls 10% of the Hub’s total delegated stake.

  • The governance-defined cap is set at 3%.

  • At tally time:

    • The validator’s self-delegation is fully included.
    • The validator can only exercise 3% of delegated stake.
    • Remaining delegations (7%) remain fully available if delegators vote directly.

Implementation Considerations

  • Module changes: Requires modification to the x/gov tallying logic to introduce the cap at the level of validator-delegated votes.
  • Staking alignment: Does not alter validator voting power for consensus or block production — this is purely a governance rule.
  • Transparency: Governance proposals and tally results should clearly display capped vs. uncapped vote shares to improve understanding.
  • Flexibility: Initial cap can be set conservatively (e.g., 3%) and adjusted over time based on observed impact.

Benefits

  • Decentralization of governance outcomes.
  • Encouragement of delegator participation — especially among delegators currently passive.
  • Reduction of systemic governance risks associated with validator concentration.

Potential Risks & Mitigations

  • Validator opposition: Larger validators may argue this reduces their governance influence. Mitigation: the cap excludes self-delegations and does not affect consensus security.
  • Implementation complexity: Requires precise modification to x/gov tally. Mitigation: we proposed a PR diff example in the appendix below to demonstrate how little changes this mechanism introduces.
  • Passive delegator inertia: If delegators remain inactive, capped votes may remain unused. Mitigation: community education and improved UX for direct voting.

Next Steps

  • Community discussion: Gather feedback on the principle, threshold (e.g., 3%), and design details. Propose initial cap value and procedure for future adjustment.
  • Technical specification: Work with Cosmos SDK contributors to define exact changes to the tallying process. We provided a PR diff suggesting changes in the appendix section of this post to highlight the relative simplicity of the proposed changes.
  • On-Chain Constitution Amendment: Draft an on-chain legally binding constitution document making it clear that any entity caught in allegedly duplicating validators to avoid this cap will be subject to sanctions. Additionally, it is worth exploring further mitigation measures to prevent custodial entities tempted to bypass this cap. It should be stated that custodians cannot self-delegate the assets of their clients, as well as casting direct votes on these accounts. Infringement of said rules should leverage on-chain votes, including tombstoning of entities involved in the misconduct and an elevated %slashing of their delegations to discourage any attempt.

Conclusion

By introducing a validator vote power cap, the Cosmos Hub can strengthen decentralization, reduce governance capture risks, and reinforce the principle that governance is a collective responsibility shared across all stakeholders, not concentrated in a few validators.

This CHIP presents a pragmatic and adjustable path forward to align governance more closely with the Hub’s mission of neutrality and resilience.

Updated on 10/8/25 :
Incorporating feedback from the community we proposed to adjust the parameter to 3% instead of 2%. This is meant to ensure quorum is not affected in the early days, leaving room for future lower adjustments if necessary.

Appendix:

In order to facilitate the CHIP process, we built a proposed PR diff example demonstrating how simple it could be to implement the vote-power cap feature in the x/gov module. Our demonstration includes:

  • New governance params: VotePowerCap (sdk.Dec) and VotePowerCapEnabled (bool).
  • Param registration and validation.
  • A concrete change to the Tally implementation that caps only delegator-defaulted voting power for each validator while excluding self-delegation and preserving delegator direct votes.
  • Migration skeleton to add the new params at upgrade time.
  • A focused unit test template that covers the main behaviors.

To avoid bloating this post we invite community members interested in this PR to look at this document: CHIP: Validator Vote Power Cap - Google Docs

6 Likes
[IDEA] Improve the Nakamoto Coefficient
[IDEA] Improve the Nakamoto Coefficient
2

Thank you for this proposal aimed at greater decentralization of governance.
The core issue, however, remains the same as the one you have already highlighted: validator duplication. Whatever method is used to improve decentralization or make governance more equitable, this risk inevitably persists.

Personally, I’m not certain what the best path is to strengthen the Hub’s decentralization. It’s ultimately a political question: should we directly limit the voting power of validators who hold too much influence? Or should we introduce a Nakamoto bonus to let stakers themselves arbitrate decentralization, as @Guinch_Roze suggest here? Either way, the underlying structural problem is the same validators may choose to duplicate themselves.

Personally, I believe it’s time to end the completely open entry to the validator set by freezing the current list and preventing new competitors. Existing validators should gradually be required to meet stricter formal obligations to professionalize their operations and make them fully accountable, with clear duties mandated by governance. Failure to comply should trigger sanctions, including potential removal and replacement by a more professional candidate who meets minimum standards defined by a commission and ratified through governance.

In this scenario, validators would gain a form of public recognition and be subject to specific governance similar to local authorities or federal states: trusted entities recognized by the community and, this time, legitimately empowered with enhanced voting rights.
By contrast, under today’s system a validator’s legitimacy comes only from entering the set through a purely market-based competition.

In short, regardless of the specific vision for improving network decentralization, one key principle stands out: validators cannot be left entirely free. They must be selected and overseen to legitimize their role and safeguard the network. Achieving this requires not only governance reform, as you mention, but also the removal of open, unrestricted access to the validator set.

2 Likes
3

We fully agree with this point and would add that custodial entities could potentially employ other bypass mechanisms as well. As we noted in our original post:

The Core Challenge

The real difficulty lies in identifying major threats and designing remedies that are both effective and resource-efficient. On-chain detection of fraud — such as validator duplication, bypassing caps through self-bonding, or manipulating direct votes — is technically infeasible.

A Path Forward

These issues are far easier to address on a human and legal level rather than purely through technical measures. We believe solutions should be anchored in legal settlement mechanisms, with governance acting as the coordinating layer.

One possible approach would be to allocate the slashing penalty to whichever entity can provide legal proof of misconduct — for example, a custodian self-delegating client assets or casting direct votes on behalf of users to bypass the cap could easily be identified and proven by a human, while totally impossible through technical means. This somehow refers to the notion of intersubjective-fault proofs. Rewarding the human resource that solved the issue would create a clear deterrent while minimizing the burden on-chain resources.

It is also important to stress that this proposal would only affect the top validators in the set — entities that are already well-known, often custodial in nature, and subject to legal obligations regarding user funds. The Hub’s role would simply be to clearly state the rules, ensure they are collectively ratified, and enforce penalties if violations are documented.

When infringements occur, enforcement could follow a two-tier model:

  • On-chain governance acting as a court, voting to impose slashing penalties, with part of the proceeds directed to the plaintiff to offset legal efforts.
  • Real-world settlement where necessary, if a company attempts to evade on-chain penalties by exiting the Hub before enforcement.

Reputation and Incentives

Beyond custodial entities, the other affected parties would be large validators whose reputation in the Cosmos ecosystem is of critical importance. It is difficult to imagine these entities deliberately undermining decentralization, given the reputational and financial risks. Any confirmed attempt would not only result in slashing but also cause irreparable reputational damage.

Conclusion

At the end of the day, this solution requires human coordination and governance clarity, not complex technical enforcement. The essential step is to codify these rules through a constitution amendment, ratified by governance, with penalties clearly defined. Once these rules are in place, all parties can be held accountable — either through on-chain enforcement or external legal mechanisms where necessary.

1 Like
4

I fully understand and respect your point of view.
That said, I advocate a different political approach that seems more viable and secure, both in the short and long term.

The issue with your model is that it relies solely on limiting governance power without directly addressing voting power.
As a result, an operator like Coinbase would still sign the same number of blocks its governance weight might decrease, but its influence on the network would remain unchanged.
Another challenge, which you correctly mention, is that most of these entities provide custody services.
Capping their delegated voting power at 2 % would not prevent them from accumulating substantial governance power.
Finally, validator duplication would still be possible albeit less attractive because duplication would only affect governance power, not voting power or APR.

In your model, the safeguard is essentially a constitution, a framework enforced by humans, with oversight committees and slashing penalties.
While I agree on the importance of such a constitution, I don’t believe the Hub will adopt one until we have a clear PMF.
This could take several years, during which we would have to rely on today’s rather fragile governance system.

Key Observations

  • Yes, we need a governance reform, but it will not happen quickly.

  • Yes, network decentralization must improve as soon as possible.

  • And we also need to professionalize the current validator set.

Intermediate Proposal:

Introduce Quadratic Voting Power
The simplest way to enhance decentralization is to give smaller validators disproportionately more voting power relative to their stake.
This would rebalance block signing, directly affect APR, and adjust influence in governance proposals.
The idea is to use inflation incentives so stakers can arbitrate decentralization themselves.
Of course, the precise strength of the quadratic curve must be tuned to keep the network stable.

Close Entry to New Validators
This is crucial for moving from a weighted staking module to a partially or fully quadratic one.
Governance should publish a whitelist of validator addresses authorized to participate.
No new validator could join without an explicit governance decision.
If a validator misbehaves, it could simply be removed and replaced by a candidate who proves their professionalism. The advantage of this strategy is that the risks of validator misconduct are already largely limited, which gives time for a potential constitutional reform to emerge.

Gradually Impose Validator Obligations
Once selected, validators should immediately face guardrails: minimum/maximum commission, mandatory self-stake, and so on.
The Hub would already gain stronger decentralization and improve the economics of smaller validators while avoiding opportunistic new entries and duplication.
More advanced requirements accountability standards, transfer restrictions, operational transparency could come later as part of a future constitutional framework, overseen by an elected legal committee if needed.

Conclusion

The goal is to transform validators into administrative agents of the Hub: professional operators approved by governance vote and bound by increasingly strict obligations.
Decentralization would shift from being validator driven to staker driven, rewarding those who delegate to smaller validators with higher yields.
Even top rank validators, even in self-stake, would be constrained by quadratic voting power and would no longer sign as many blocks or wield the same influence in governance as under a purely weighted model.

2 Likes
[IDEA] Improve the Nakamoto Coefficient
5

We appreciate your thoughtful input and would like to clarify the scope and priorities of our proposal.

Scope of the Proposal

As you noted, our proposal focuses exclusively on governance power without altering voting power itself. Broader changes — such as block production or staking reward distribution — would have significant downstream consequences and must be addressed separately in a step-by-step sequence. We see governance decentralization as the first and most urgent step, ensuring that the decision-making process remains as decentralized as possible.

The Governance Risk

At present, large custodial validators and centralized exchanges rarely cast votes. However, the potential risk is clear: they could decide to exercise this power at any time, potentially altering governance outcomes or vetoing proposals outright. Our aim is to ensure that legitimate, self-custodied token holders remain the primary voice in governance, while diluting the disproportionate influence of custodial entities that do not allow clients to vote directly. This is about being proactive — addressing the problem before it materializes, not after.

Why Not Quadratic Voting

We also want to address the suggestion of quadratic voting power. While well-intentioned, this approach has been tested elsewhere and proved ineffective, as it introduces new vulnerabilities without resolving the core issue. Large stakeholders hold legitimate ownership of their tokens and therefore have a proportional right to influence governance. Our proposal does not challenge this proportionality principle. Instead, it specifically addresses the delegation system, where custodial entities inherit voting power from clients who cannot exercise their rights.

On Validator Access and Obligations

Regarding the idea of closing entry to new validators, we strongly oppose such a measure. A public blockchain must remain open to participation in consensus at all times. Restricting access would fundamentally undermine the principles of the Cosmos Hub.

That said, we recognize the importance of accountability for large validators. Over time, they may need to meet legal or operational obligations, particularly around censorship resistance. For instance, if a validator deliberately blacklists transactions, Cosmos’ mempool propagation would allow others to quickly identify and prove censorship. A governance-backed constitution could then enforce penalties against violators, ensuring accountability while preserving decentralization. There again, the execution of such enforcement mechanism ultimately boils down the capacity of governance to pass these proposal without centralized obstruction.

Conclusion

In summary, our proposal is about fortifying governance today so that, if powerful actors attempt to misbehave tomorrow, they can be held accountable through a decentralized and effective process. We see this as the necessary first step in a longer sequence of reforms. Other mechanisms — such as validator obligations or enforcement rules — can and should be discussed in subsequent stages, once governance itself is safeguarded.

6 
I would emphasize the following key indicators:

voting participation (let's say at least 50%)

validator commission no higher than 20%

number of delegators (at least 500 delegators for every 100,000 Atoms)

If any of the parameters fail to meet the requirements, the validator is removed from the active set.
7

We would like to invite all community members to share their feedback on this proposal in the coming week. Following the standard 14-day governance discussion period on this forum, we intend to move the proposal on-chain.

If no major revisions are suggested, our current timeline would place the on-chain vote around mid-October.

8

With all respect, but there’s more traffic in Tg chats or X. If you want more feedback I’d invite you to tg chats..

9

This is an interesting idea. I have some questions though, from the practical standpoint.

  • All validators would see their governance VP capped to 2% of their actual VP?
    If so, doesn’t it simply displace the issue? 2% of 2M is still wildly superior to 2% of 500K and if all the biggest validators vote with 2% of their VP it will remain more than 2% VP of the rest of the set.
  • We can maybe expect that the votes of the delegators will nudge the outcome a bit, but their participation is traditionally low and it is unclear that this new rule would really drive a significant fraction of them to vote individually.
  • And therefore: what about the quorum? If the number of individual votes does not massively increase, don’t we risk seeing proposals fail because we can’t get 40% of the overall VP to vote?
    Among the last proposals, most just barely reached the quorum, and a few actually did not.

(I read the PR diff in the linked gdoc but it doesn’t look like there is a planned workaround to this, although admittedly i’m not skilled at go and went through it quickly so I might have missed something.)

10

That cap is global, not relative to each validator’s own stake.

So if the Hub has 100 million ATOM bonded, and VotePowerCap = 0.03 (3%), then:

  • capTokensInt = 3,000,000 ATOM.
  • That value is the maximum amount of defaulted voting power that any single validator can wield.
  • It applies equally to every validator, regardless of how large or small their delegation set is.

How it works in practice

For each validator in the tally loop:

  1. Calculate their delegatorDefault (tokens from delegators who didn’t vote).
  2. Compare against the global cap (capTokensInt).
  • If delegatorDefault <= capTokensInt → all of it is counted.
  • If delegatorDefault > capTokensInt → only capTokensInt is counted.

Self-delegations are added on top of this capped value, since they are explicitly excluded from the cap.

We agree with this point. However, we believe the risk may very well materialize at some point, and it is wiser to prepare proactively rather than react afterward. To put this into perspective: the top ten validators, who would be directly affected by the proposal, currently hold a combined 47.39% of the total voting power. With the proposed cap in place, this share would be reduced to around 20% (excluding self-bond). We view this as a healthy balance — these validators would still retain meaningful influence in governance, but without the ability to dramatically alter outcomes on their own.

As highlighted above, the effective reduction would leave the adjusted share closer to 20% under a 2% cap, based on today’s distribution. This ensures that quorum would not be disrupted, especially considering that most of the affected voting power is currently inactive in governance anyway. Our intent is simply to put in place a preemptive safeguard — ensuring that this enormous, untapped concentration of power cannot be exercised unchecked in the future.

We also want to thank you for actively participating in this discussion — your input is valuable in refining and strengthening the proposal.

3 Likes
11

Got it, thanks for clarifying! I had indeed overlooked the “global cap” part.

Sounds good.

3 Likes
12

Imo, this proposal needs a tweak to ensure it does not significantly impact the ability to pass proposals due to a failure of quorum.

Looking at the top 12 validators (the ones who will be impacted by this proposal), 5 are very active voters. Collectively, this proposal would cap their total quorum contribution at 10%, removing 7.34% of total vote power contributing to quorum.

Looking at the last 10 gov proposals on the Hub, only 1 passed by more than this margin, and 4 of them were rejected due to a failure to reach quorum. This proposal could make it such that no future gov proposals are able to pass.

Instead, I’d propose applying the VP cap to proposal results only, and not to quorum requirements.

More broadly, however, I think this proposal is premature. As Mag has mentioned, Cosmos Labs is on the verge of making a number of significant announcements that could impact the course of the Hub’s / ATOM’s future. Without clarity on those announcements, it’s hard to know what might break with this proposal.

Given there’s no real urgency in getting this passed, I’d propose waiting. There are also a number of other ways to solve the problem of governance centralization. One major way would be to revamp the ICF delegation program (which i hear may be in the works as we speak).

3 Likes
13

Thank you for raising these valuable points.

On quorum risks
You are absolutely correct to note that this proposal could potentially affect quorum under certain circumstances. However, it is important to emphasize that the proposal was intentionally designed with adjustable parameters.
A simple way to mitigate this concern would be to increase the initial cap parameter from 2% to 3%. This would ensure that the introduction of the cap does not disturb quorum while allowing us to later reduce it, once we have confirmed that quorum remains stable.

On applying the cap only to results
While this idea may seem appealing at first glance, it would introduce additional complexity in the codebase and create dependencies tied to variable quorum thresholds. Our goal is to keep the mechanism as simple, transparent, and self-contained as possible within the governance module.

On the timing of this proposal
At Govmos, we firmly believe that innovation should not rely solely on foundation-led initiatives. The Cosmos Hub’s strength lies precisely in its decentralized governance — a principle we must continue to embody.
This proposal establishes the foundation for a resilient governance framework, one that protects against the growing risks of delegation-based centralization. This is not only a matter of decentralization ethics but also of regulatory prudence.
With the upcoming Clarity Act in the U.S. — which stipulates that no group of entities should control more than 20% of a network to qualify as a commodity — it becomes clear that we need such safeguards in place. At present, Coinbase alone represents nearly 15% of the Hub’s voting power, which poses a real threat to our long-term eligibility for such recognition.

On whether to wait
We understand the argument for patience, but in this case, waiting is not necessary. The proposed implementation is lightweight, self-contained, and risk-free, introducing only two parameters:
VotePowerCap and VotePowerCapEnabled.
It does not alter staking rewards or block production; it solely targets delegated governance power, while preserving the rights of all legitimate token holders — anyone can still bypass the cap through direct voting.

In conclusion, we acknowledge the quorum concern and are open to adjusting the initial cap to 3% to ensure smooth adoption. This change would have minimal immediate impact on large validators while providing meaningful protection against future concentration of delegated governance power. Our priority remains the same: to safeguard the Cosmos Hub’s decentralization at the governance level, without compromising its consensus security.

4 Likes
14

Thank you for this response but, unfortunately, this proposed solution won’t have meaningful bearing on whether or not the Hub is sufficiently decentralized to qualify for commodity status under the clarity act. Regardless of what happens with on-chain governance, a supermajority of consensus power can alter chain state by forking the chain at any time. This is what will matter for the purposes of the clarity act. Adjusting on-chain vote power doesn’t impact consensus power in a dpos system.

The proposal really changes governance in name only. This is why I’m urging a bit of patience here. At the end of the day, this proposal won’t have immediate positive impact but may have an outsized negative impact. Despite your comments, this is not a minor change. It’s a significant change to the way that Cosmos Hub governance works. The gov module touches nearly every aspect of the chain, and it shouldn’t be trivially messed with, especially when we know that significant announcements are coming that this vote may impact. There’s truly no need to rush something like this until we all have the full picture.

For that reason I’m opposed to the proposal generally.

However, if you’re truly adamant about proceeding with this proposal, there are ways to mitigate the potential negative impact. The biggest one would be to set the initial cap parameter at 5% instead of 3%. This ensures that active voters retain vote power for now, while limiting Coinbase’s potential vote power to ~1/3 of what it is today. Given Coinbase does not vote anyway, the actual impact on quorum and vote outcomes for now will be neutral.

As you’ve said, it’s better to start conservative, ensure gov remains stable, and adjust from there.

1 Like
15

On the relevance of the Clarity Act to this proposal, we must respectfully disagree with your statement. Here is a direct excerpt from the Clarity Act:

“No person or group of persons under common control—
(i) has the unilateral authority, directly or indirectly, through any contract, arrangement, understanding, relationship, or otherwise, to control or materially alter the functionality, operation, or rules of consensus or agreement of the blockchain system or its related digital commodity; or
(ii) has the unilateral authority to direct the voting, in the aggregate, of 20 percent or more of the outstanding voting power of such blockchain system by means of a related digital commodity, nodes or validators, a decentralized governance system, or otherwise, in a blockchain system which can be altered by a voting system.”

Source: Clarity Act — H.R.3633 (119th Congress)

This section clearly refers to outstanding voting power, not to asset ownership. Many in the ecosystem have mistakenly interpreted this as a 20% ownership threshold, whereas the law explicitly concerns the aggregate votepower—regardless of how it is acquired.
In practice, this means that any validator controlling or inheriting 20% of the total voting power—even through delegated stake and irrespective of self-bond—would represent a breach of this rule.

For this reason, we maintain that the proposal is directly relevant to ensuring the Hub’s compliance with the Clarity Act, by introducing an on-chain mechanism that prevents the accumulation of outsized voting power through delegations. This is precisely the safeguard that the Act implies, and one that the Cosmos Hub—as well as every other Cosmos based chain using delegated Proof of Stake—currently lacks.

On the impact of this proposal
Contrary to your assertion, this change does have an immediate and positive effect. It establishes a hard, enforceable limit on delegated voting influence, ensuring no entity can unilaterally exceed a safe threshold. This is not a symbolic gesture — it is a functional protection applied directly at the governance module level. And we believe this function could have meaningful impact outside of the Cosmos Hub but through any chain using the SDK and seeking compliance to these rules.

On the technical implications
We also wish to clarify that the proposed update is surgically minimal. It does not interfere with other chain modules or introduce new dependencies. The only modification occurs within the x/gov/keeper/tally.go file, where the vote count summation now includes a check against the VotePowerCap parameter.
If there are any identified dependencies beyond this scope, we welcome a concrete technical review to address them. Otherwise, based on our analysis, no cross-module impact exists.

In summary, we intend to proceed toward an on-chain vote for this proposal unless compelling technical or legal counterarguments are presented.

1 Like
16

Respectfully the text you’ve quoted proves my point. Particularly the following:

Onchain governance is interpreted quite broadly here, and most people familiar with governance outside of Cosmos (e.g., how Ethereum governance works) know that this is inclusive of node upgradeability to a designated binary. We’re not as used to that in Cosmos, but it’s absolutely applicable here.

Again, I respect your right to put this on chain, but if you intend to do so I would strongly recommend setting a higher initial cap of at least 5%, which has the same effect of preventing a single party’s on-chain vote power from exceeding 20% while being far less likely to have unintended negative impacts on the overall governance of the chain.

1 Like
17

We hope you don’t mind us respectfully challenging your points — after all, that’s precisely the purpose of these discussions: to exchange perspectives and foster constructive debate on complex or contentious topics.

We understand the comparison, but we believe this interpretation cannot be directly applied to Cosmos chains for structural reasons. In the Cosmos framework, a validator failing to upgrade the chain — even with a 20% of VP — would not constitute a governance or consensus failure. With 33% VP entities would only prevent block production.
For any meaningful fork or divergence from the designated binary, the validator (or group of validators) would need to control two-thirds of the consensus. This is a much higher threshold, inherent to the BFT consensus model that underpins Cosmos chains.

Furthermore, each software upgrade in Cosmos is preceded by an on-chain governance proposal explicitly approving the binary to be executed. This mechanism ensures that upgrade decisions are collective and transparent, not unilateral. In other words, the governance process itself designates the binary to be adopted, and validators merely execute the community-approved decision.

For these reasons, we believe the 20% governance rule from the Clarity Act cannot reasonably encompass chain upgradability within Cosmos, or — if it does — its impact would be negligible given the existing safeguards. The requirement for a 66% threshold to enforce a fork already exceeds any realistic concentration of power that the Clarity Act’s 20% governance limit aims to prevent.

1 Like
18

Thank you for this write up, we learnt alot while reading it.

1 Like