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 the cap.
This proposal does not directly modify the Cosmos Hub. A Yes vote signals support for developing the required code and submitting it through a future Gaia software upgrade proposal.
Background
Cosmos Hub governance currently allows validators to inherit the voting power of delegators who do not vote directly.
This means that a validator with a large amount of delegated ATOM may exercise substantial governance influence even when most of that voting power belongs economically to independent delegators or custody clients.
Delegators retain the ability to override their validator by voting directly. However, direct delegator participation remains limited, leaving a significant amount of governance power under the effective control of a relatively small number of validators.
This creates several risks:
-
Excessive concentration of governance influence.
-
Dependence on the voting decisions of a small number of large validators.
-
Custodial validators exercising governance power on behalf of clients who may be unable to vote directly.
-
Governance outcomes that do not accurately represent the preferences of individual ATOM holders.
-
The possibility that a validator could rapidly activate a large amount of previously inactive voting power.
The purpose of this proposal is not to weaken stake-based governance or reduce the ownership rights of ATOM holders.
Its purpose is to limit the amount of passively inherited voting power that one validator can exercise on behalf of delegators who have not expressed their own governance preference.
Proposed mechanism
1. Validator delegated vote power cap
The amount of defaulted delegator voting power that may be exercised by any single validator would be capped at:
5% of total bonded ATOM
The cap would be calculated at tally time using the total amount of bonded ATOM.
For example, if 300 million ATOM are bonded:
300 million Ă— 5% = 15 million ATOM
A validator could therefore exercise a maximum of 15 million ATOM of defaulted delegator voting power.
The cap would apply equally to every validator.
2. Only inherited delegator voting power is capped
The cap would apply only to voting power inherited from delegators who did not vote directly.
The following voting power would remain fully counted:
-
ATOM used by a delegator to vote directly.
-
Validator self-delegation.
-
Voting power held by validators whose inherited delegated voting power is below the cap.
Direct delegator votes would continue to override the validator vote under the existing Cosmos governance model.
When a delegator votes directly, their voting power would be deducted from the power inherited by their validator and counted fully according to the delegator’s own selected voting option.
3. Quorum remains uncapped
The vote power cap would not apply to the calculation of quorum.
Quorum measures participation in a governance proposal. It should therefore reflect the full amount of bonded stake that participated, regardless of whether part of that stake is subsequently capped when determining the proposal’s outcome.
The governance module would calculate:
Quorum participation =
Uncapped participating voting power Ă· Total bonded voting power
The existing quorum parameter would remain unchanged.
This prevents the validator vote power cap from making it more difficult for governance proposals to reach quorum.
4. Proposal results use capped voting power
After quorum has been checked using uncapped voting power, the proposal outcome would be calculated using capped voting power.
The effective voting power of a validator would be:
Validator self-delegation
Minimum(
defaulted delegator voting power,
5% of total bonded voting power
)
Direct delegator voting power would then be added separately and counted in full.
The resulting effective voting power would be distributed across Yes, No, Abstain and NoWithVeto according to each voter’s selected option or weighted vote.
The existing governance rules would then apply to the capped result:
-
The Yes threshold would be calculated using effective non-abstaining voting power.
-
The veto threshold would be calculated using effective result voting power.
-
Expedited proposal thresholds would continue to operate according to existing governance parameters.
This proposal does not seek to modify the existing quorum, approval, veto or expedited proposal thresholds.
Example
Assume that:
-
Total bonded stake is approximately 300 million ATOM.
-
The validator vote power cap is 5% (which corresponds to 15 million ATOM).
-
One validator has 10 million ATOM of defaulted delegator voting power (which is below the cap).
-
The validator has 200,000 ATOM of self-delegation.
-
The validator votes Yes.
The cap would be:
300 million Ă— 5% = 15 million ATOM
For the quorum calculation, the validator would contribute its full participating voting power:
10 million delegated ATOM
200,000 self-delegated ATOM
=
10.2 million ATOM toward quorum
For the proposal result, the validator would contribute:
10 million delegated ATOM (below cap, fully counted)
200,000 self-delegated ATOM
=
10.2 million effective Yes voting power
Since the validator’s delegated voting power is below the cap, no reduction is applied.
However, the affected delegators would retain the ability to vote directly, in which case their voting power would be counted fully.
Initial parameters
The proposed implementation should introduce the following governance parameters:
VotePowerCapEnabled = true
VotePowerCap = 0.05
VotePowerCapEnabled
This parameter enables or disables the validator governance vote power cap.
Setting it to false would restore the standard governance tallying mechanism without requiring another software upgrade.
VotePowerCap
This parameter defines the maximum fraction of total bonded voting power that one validator may inherit from passive delegators when calculating proposal results.
The initial value would be:
0.05 = 5%
The cap should not affect quorum as a matter of protocol design. This separation does not need to be independently adjustable through governance.
Once the feature has been introduced through a software upgrade, governance would be able to adjust the cap or disable the mechanism through a future parameter-change proposal.
Why begin with a 5% cap?
A 5% initial cap provides a conservative introduction of the mechanism.
It would substantially reduce the maximum governance influence that one validator may inherit while minimizing disruption to existing governance behavior.
Beginning with 5% would allow the community to:
-
Observe the effect on real governance proposals.
-
Verify that voting interfaces and tally results remain understandable.
-
Measure direct delegator participation.
-
Identify unexpected technical or economic consequences.
-
Gather data before considering a lower cap such as 3% or 2%.
Any future reduction should be based on observed governance data rather than being introduced automatically.
Scope
This proposal applies exclusively to Cosmos Hub governance.
It would not modify:
-
Consensus voting power.
-
Block production.
-
Validator ranking.
-
Staking rewards.
-
Validator commission.
-
Slashing conditions.
-
Delegation balances.
-
Unbonding periods.
-
The active validator set.
-
The ability of ATOM holders to vote directly.
The cap would affect only the governance power inherited by validators from delegators who did not vote directly.
Technical implementation
A future implementation should include at least the following components:
Governance parameters
Add the following fields to the governance module parameters:
VotePowerCapEnabled
VotePowerCap
The implementation should include appropriate parameter validation.
VotePowerCap should:
-
Be greater than zero when enabled.
-
Not exceed one.
-
Use the decimal format already used by Cosmos SDK governance parameters.
Separate tally values
The governance tally should maintain at least two distinct values:
RawParticipationVotingPower
EffectiveResultVotingPower
RawParticipationVotingPower would be used only for quorum.
EffectiveResultVotingPower would be used for Yes, No, Abstain and NoWithVeto calculations.
This separation is a required part of the approved design.
Delegator deductions
Direct delegator votes must continue to be deducted from the voting power inherited by their validator.
The cap must be applied only after direct delegator deductions have been calculated.
Self-delegation
Validator self-delegation must be identified and counted separately from defaulted delegator voting power.
Self-delegation would remain uncapped.
Weighted votes
The mechanism must support weighted votes.
After calculating a voter’s effective voting power, that power should be distributed proportionally across the selected vote options.
Migration
The software upgrade must include a migration introducing the new parameters.
The Cosmos Hub migration should initialize them as:
VotePowerCapEnabled = true
VotePowerCap = 0.05
Tests
The implementation should include unit and integration tests covering at least:
-
A validator below the cap.
-
A validator above the cap.
-
A validator with self-delegation.
-
A delegator voting directly.
-
Multiple direct delegators.
-
Weighted validator votes.
-
Weighted delegator votes.
-
Abstain votes.
-
NoWithVeto calculations.
-
Expedited proposals.
-
Quorum calculated without the cap.
-
Proposal results calculated with the cap.
-
The mechanism being disabled.
-
Parameter changes after the upgrade.
Interfaces and transparency
Wallets, explorers and governance interfaces should be encouraged to display:
-
Raw voting power participating in quorum.
-
Effective voting power used for the result.
-
The amount of voting power removed by the cap.
-
The validator vote power cap active for the proposal.
The on-chain tally result must remain deterministic even when an interface does not display this additional information.
Limitations
This mechanism caps voting power per validator address. It does not automatically identify several validators operated by the same legal or economic entity.
A validator operator could theoretically attempt to bypass the cap by operating multiple validators.
Custodial entities could also potentially vote through multiple client or custody accounts.
These behaviors cannot necessarily be identified reliably through the governance module alone.
This proposal therefore does not claim to establish a complete entity-level governance cap or guarantee legal or regulatory compliance.
Possible entity-level rules, disclosure requirements or enforcement mechanisms should be addressed separately and should not delay the introduction of a technically enforceable per-validator cap.
This proposal does not introduce new slashing or tombstoning conditions.
Risks and mitigations
Risk: Reduced influence of large validators
Large validators would exercise less inherited governance influence.
Mitigation: Their self-delegation remains fully counted, their consensus power remains unchanged, and their delegators may vote directly.
Risk: Validator splitting
An operator could divide stake across multiple validators.
Mitigation: Monitor validator ownership and delegation movements. Any future entity-level restrictions should be proposed separately with clear evidence and enforcement standards.
Risk: Implementation errors
Governance tallying is critical chain functionality.
Mitigation: Require public technical review, complete testing, historical simulations and inclusion through a standard Gaia software upgrade process.
Risk: Confusing governance results
Users may see a difference between participation counted toward quorum and effective votes counted toward the result.
Mitigation: Clearly expose both values through APIs, explorers, wallets and governance documentation.
Risk: An inappropriate initial cap
A 5% cap may eventually prove too high or too low.
Mitigation: The cap would remain adjustable through governance and could be disabled without another software upgrade.
Implementation process
Approval of this signaling proposal would authorize the following process:
-
Produce a complete technical specification.
-
Develop the feature in the Cosmos SDK governance module or within Gaia, depending on the implementation path selected by maintainers.
-
Conduct public code review and testing.
-
Simulate the mechanism against historical Cosmos Hub proposals.
-
Publish the implementation, tests and simulation results.
-
Include the feature in a future Gaia release.
-
Submit a separate software upgrade proposal containing the final code and upgrade details.
-
Activate the feature with a 5% initial cap if the software upgrade proposal passes.
This signaling proposal does not commit community-pool funds.
Any funding request related to implementation, auditing or interface development must be submitted separately.
Governance signal
A Yes vote signals support for:
-
Introducing a validator governance vote power cap.
-
Setting the initial cap at 5% of total bonded voting power.
-
Applying the cap only to proposal results.
-
Preserving uncapped voting power for quorum.
-
Preserving full direct delegator voting power.
-
Preserving full validator self-delegation.
-
Developing and testing the feature.
-
Presenting the final implementation through a future Gaia software upgrade proposal.
Voting options
YES
Support the proposed design and request that contributors and maintainers prepare the required implementation for a future software upgrade proposal.
NO
Do not support the proposed validator governance vote power cap or its current design.
NO WITH VETO
The proposal is considered harmful, abusive or inappropriate for governance and its deposit should be burned.
ABSTAIN
Participate in quorum without expressing support or opposition.
