coreum

Prop 45: Proposal: Implement Governance-Configurable Validator Voting Power Cap

Summary

This proposal serves as an official community signaling mechanism to express consensus on incorporating a governance-configurable validator voting power cap into the TX chain for an upcoming network upgrade.

Given recent infrastructure vulnerabilities, validator off-boardings, and extreme stake migration, introducing an on-chain cap will protect network liveness, prevent governance veto exploits, and ensure sustainable decentralization.

Context & Motivation

Infrastructure Centralization & Network Halt Risk

On July 15, the TX network experienced a complete chain halt when over 33.4% of active voting power went offline simultaneously due to a shared node infrastructure provider outage. While the core team addressed this by partnering with alternative providers to diversify hosting options, the incident highlighted the critical danger of voting power concentration. Regardless of whether concentration stems from hosting providers or individual validator stake, exceeding 33.4% offline voting power will halt the network.

Recent Validator Departures & Stake Concentration

In recent weeks, multiple active validators - including 2 of the top 5 - shut down operations. In response, delegators migrated their tokens en masse to the top nodes. As shown in network redelegation flow charts on Mintscan, over 67.9M tokens were redelegated to the #1 validator in a 30-day window, with massive spikes following validator exits.

Current Network Vulnerability

As of today, the active validator set consists of 53 bonded validators, yet voting power is heavily skewed toward the top end.

The top 2 validators combined hold 32.67% of total voting power, less than 1% away from the 33.4% threshold required to stall block production. A targeted DDoS attack or simultaneous outage on just these two entities could halt the entire chain.

In standard Cosmos SDK architecture, a proposal fails if NoWithVeto votes reach 33.4% of participating power, or if total participating power fails to reach the quorum requirement. On TX, if the 40% quorum is not met, the proposal fails and the proposer forfeits their deposit. Currently, the top 3 validators (holding ~40.8%) can unilaterally censor governance or cause proposers to lose their deposit by choosing not to vote.

Proposed Technical Solution

The code required to prevent further concentration has already been built and tested in PR #108 by alagiz.

The implementation introduces a configurable MaxVotingPower parameter within x/customparams StakingParams:

  1. Non-Disruptive Deployment: Deploys disabled by default (1.0 / 100%), causing zero immediate disruption upon binary upgrade.
  2. Preventative Enforcement: Once enabled by governance (e.g., at a 10% or 12% threshold), it restricts new stake additions (MsgDelegate, MsgBeginRedelegate, MsgCancelUnbondingDelegation, MsgCreateValidator) that would push a validator over the cap. It does not forcibly unbond or trim existing stake.
  3. Execution Safety: Enforced directly in the x/wstaking execution layer, guaranteeing that smart contracts, Authz, Interchain Accounts (ICA), and governance proposals cannot bypass the restriction.
  4. Safety Floor: Features a hardcoded 1% parameter floor to guard against accidental or malicious proposals freezing network delegations.

Voting Options

  • YES: Signal consensus for core developers to integrate the governance-configurable validator voting power cap (PR #108) into the next chain upgrade.
  • NO: Reject the integration of an on-chain voting power capping mechanism.
  • ABSTAIN: Participate without taking an explicit stance.
  • NO WITH VETO: Reject the proposal under the belief that it is harmful, malicious, or spam.

Full detailed proposal can be found at https://t.me/TX_gov/139