[SIGNALING] [DRAFT] Introduce a Validator Governance Vote Power Cap

Hub Proposals Signaling/Text
1

Change log

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:

  1. Produce a complete technical specification.

  2. Develop the feature in the Cosmos SDK governance module or within Gaia, depending on the implementation path selected by maintainers.

  3. Conduct public code review and testing.

  4. Simulate the mechanism against historical Cosmos Hub proposals.

  5. Publish the implementation, tests and simulation results.

  6. Include the feature in a future Gaia release.

  7. Submit a separate software upgrade proposal containing the final code and upgrade details.

  8. 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.

3 Likes
2

image
image435Ă—333 21.6 KB

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%?

image
image930Ă—222 21.4 KB

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%

3 Likes
3

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.

4

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

2 Likes
5

they never voted . For now .

1 Like
6

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.

1 Like
7

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 :sweat_smile:.
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.

3 Likes
8

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.

2 Likes
9

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.

10

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.

11

imo 2 should be great. But historically, we have tended to be overly cautious and have lacked boldness in our decision-making.

1 Like
12

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 reasonable only if the proposal also defines the data and timeline that would determine whether the cap should later be reduced.

Overall, I support continuing the technical analysis, simulations, and public discussion before moving to implementation.

4 Likes
13

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.

2 Likes
14

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?