[SIGNALING] [DRAFT] Introduce a Validator Governance Vote Power Cap
Change log • 2025-09-21 Created initial post [ LAST CALL] CHIPs signaling phase : Validator Vote Power Cap Summary Building on the work discussed at [ LAST CALL] CHIPs signaling phase : Validator Vote Power Cap , I am bringing this topic back with the modifications proposed in the initial post. This signaling proposal seeks Hub Unit and community approval to develop and integrate a validator governance vote power cap into the Cosmos Hub governance module. The proposed mechanism would limit the amount of voting power that a validator may inherit from delegators who do not vote directly. The initial cap would be set at 5% of the Cosmos Hub’s total bonded voting power per validator . The mechanism would apply only when calculating governance proposal outcomes. It would not reduce the voting power counted toward quorum . The proposal therefore introduces two separate governance calculations: • Uncapped voting power to determine whether quorum has been reached. • Capped voting power to determine the final Yes, No, Abstain and NoWithVeto results. Direct delegator votes and validator self-delegation would remain fully counted and would not be subject to…
Excerpt (1197 of 15588 characters). Read the whole post on the forum ↗
Guinch_Roze:The initial cap would be set at 5% of the Cosmos Hub’s total bonded voting power per validator.
Do you realize that only 3 validators are above this 5% cap and only those 3 would be affected by this proposal? So this proposal is to limit the governance VP of coinbase, upbit and kiln to 5%?
However, coinbase and upbit never vote, so no change whether things stay as now or you limit their governance VP at 5%. This whole proposal all it would do will be do reduce kiln governance voting power from 5.42% to 5%
but if you intend to do so I would strongly recommend setting a higher initial cap of at least 5%
Yeah, I realized that only three validators are currently above the proposed threshold. However, a Hub Unit team member suggested starting with an initial 5% cap and then evaluating its impact before considering any further reductions, based on a thorough analysis of how the network behaves.
From those 3, coinbase and upbit never vote so whether you limit their govenance voting to 5%, 3% or anything doesn’t make any different because they don’t vote. And the third Kiln is already around 5% governance VP
they never voted . For now .
Just keep digging into the validator delegation program (where there is already a delegation restriction to non-voting validators) and the problem will go away on its own.
I think the point of this proposed change isn’t to encourage validators to vote, rather to curb the ability of the bigger ones to steer governance one way or another based on their own interests and not necessarily in the Hub’s itself.
Note that these validators could just as well block a proposal aiming at limiting their weight in governance, so there’s that 
.
In its current form, as pointed out it wouldn’t have any sizable effect and it may not be the optimal way of doing this – also probably best to postpone this to after the result of the tokenomics research so that we don’t end up with conflicting mechanisms–, but it’s a healthy discussion to have regardless.
I think the distinction between quorum and effective governance power is probably the strongest part of this proposal. It avoids accidentally making governance participation harder while still addressing concentration of inherited voting power.
My main concern is less about the exact percentage and more about how the cap interacts with validator behavior over time. A 5% starting point seems reasonable if it’s accompanied by historical simulations and clear metrics for evaluating whether the mechanism actually improves governance decentralization rather than simply redistributing influence.
It does address a real problem, though I wonder if capping per-validator actually reduces the concentration you’re worried about or just reshapes it. Hard to say whether the cumulative effect changes meaningfully.
Personally I think the 5% should start at 3.25% give or take. We all know the 5% won’t impact much, besides one validator. And even they won’t be affected much. 3.25% is a good in between of all super validators and all smaller ones. And you can adjust from there.
imo 2 should be great. But historically, we have tended to be overly cautious and have lacked boldness in our decision-making.
I support the general objective of limiting excessive inherited governance influence, and I think separating uncapped quorum participation from capped result voting power is the strongest part of the design. My concern is that a 5% starting cap appears to have very limited practical effect under the current validator distribution. If only a small number of validators are above the threshold and some of those validators do not normally vote the mechanism may add complexity without materially changing governance outcomes. Before selecting the final parameter, I would recommend publishing historical simulations using at least 5%, 3.25%, and 2%. The comparison should show: • how many past proposal outcomes would have changed; • how much effective voting power would have been removed; • the effect on Yes, No, Abstain, and NoWithVeto results; • whether influence becomes meaningfully less concentrated; • whether operators could bypass the intended effect by splitting stake across multiple validator addresses. A configurable parameter is sensible, but the initial value should be based on measurable governance outcomes rather than caution alone. Starting conservatively is…
Excerpt (1196 of 1449 characters). Read the whole post on the forum ↗
I think so too, sadly though I think this year is a big boom or bust. We’ve seen big supporters leave. The ones still here are the ogs that have the most faith, I think they gotta go big and adjust from there. Every single person involved in cosmos knows 5% is gonna do absolutely minimal.
From a wallet UX and support perspective, the distinction between uncapped quorum participation and capped voting power used for the result will need to be communicated very clearly.
I work in BD and Support at Gem Wallet, and governance figures can easily confuse users when the number displayed in a wallet or explorer does not appear to match the final tally. Ideally, interfaces should show both values and explain that direct delegator votes remain fully counted.
Is there a plan to define a standard query or display format that wallets and explorers can follow if this mechanism is implemented?