Skip to content

feat: add VIP to raise proposal threshold to 1M XVS#726

Open
Debugger022 wants to merge 11 commits into
mainfrom
feat/new-governance-bravo
Open

feat: add VIP to raise proposal threshold to 1M XVS#726
Debugger022 wants to merge 11 commits into
mainfrom
feat/new-governance-bravo

Conversation

@Debugger022

@Debugger022 Debugger022 commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Summary

Raises the proposal threshold for all three governance routes (Normal, Fast-track, Critical) from 300,000 XVS → 1,000,000 XVS, and the governance quorum from 600,000 XVS → 1,500,000 XVS.

Why two actions

The current GovernorBravoDelegate hardcodes MAX_PROPOSAL_THRESHOLD = 300,000 XVS, and setProposalConfigs reverts for any threshold above that cap. So the change requires, in order:

  1. Upgrade the implementation — point GovernorBravo (0x2d56dC077072B53571b8252008C60e945108c75a) to a new GovernorBravoDelegate (0x9975d7064e40D16E1B76B90e56F606D72B385701) that sets MAX_PROPOSAL_THRESHOLD = 1,000,000 XVS and quorumVotes = 1,500,000 XVS. Storage-safe: only two constants changed, layout is unchanged.
  2. Update proposal configs — raise proposalThreshold to 1,000,000 XVS on all three routes, preserving existing voting delays and periods.

Route is REGULAR: both functions are admin-only and admin is the Normal Timelock.

Why 1,500,000 XVS quorum

Set to 1.5× the new 1,000,000 XVS proposal threshold, keeping quorum above what a single proposer can supply so passing a vote still requires multi-voter consensus. Quorum is a constant in the new implementation, raised by Action 1 — no separate call.

What is NOT changed

  • Voting delays (1) and voting periods (192384 / 192384 / 48096) — unchanged on every route.

⚠️ Operational impact — action required after execution

Once this VIP executes, any account with less than 1,000,000 XVS of voting power can no longer create a proposal on any route. The previous bar was 300,000 XVS.

  • The proposing account (or its delegated voting power via the XVS Vault) must hold ≥ 1,000,000 XVS before submitting any future VIP.

Testing

Fork simulation (simulations/vip-636/bscmainnet.ts, fork block 106069390, 18 passing) verifies:

  • Implementation pointer updates to the new delegate.
  • quorumVotes rises 600,000 XVS → 1,500,000 XVS.
  • proposalThreshold becomes 1,000,000 XVS on all three routes; voting delays/periods match captured pre-VIP state.
  • Threshold enforcement (the core security property — only sufficiently-staked accounts can propose):
    • Pre-VIP: a below-300k account is rejected; a ≥300k account can propose.
    • Post-VIP: the same account that cleared the old 300k bar is now rejected (below 1M); a ≥1M account (funded via vault stake + self-delegate) can propose.
    • Simulation framework — updated src/vip-framework/index.ts so that once this VIP executes, testVip auto selects a proposer/supporters meeting the new 1M threshold and 1.5M quorum, keeping future VIP simulations able to propose and pass.

Run:

npx hardhat test simulations/vip-636/bscmainnet.ts --fork bscmainnet

- Upgrade GovernorBravo implementation so MAX_PROPOSAL_THRESHOLD
  allows 1,000,000 XVS, then raise the proposal threshold on all
  three routes (normal, fast-track, critical)
- Preserve existing voting delays and periods; only the threshold
  changes
- Order actions impl-first since the current cap rejects any
  threshold above 300,000 XVS
- Assert a sub threshold proposer is rejected and an at/above
  proposer is accepted, both before (300k) and after (1M) the raise
- Show the same account that cleared the old 300k bar is blocked
  post-VIP, demonstrating the higher cost to submit a proposal
- Fund the 1M-vote case by staking XVS and self-delegating in the
  vault, since no single existing holder has that voting power
@Debugger022 Debugger022 force-pushed the feat/new-governance-bravo branch from 734bea8 to e80d3de Compare June 24, 2026 08:54
- testVip now reads the on-chain proposal threshold and quorum at the
  fork block and picks voters that satisfy them, instead of a fixed
  proposer that breaks once governance raises the bar
- Defaults are returned unchanged whenever they still suffice, so
  simulations at historical fork blocks are unaffected
- Falls back to a high-power voter only when the defaults fall short,
  keeping post-raise simulations able to propose and reach quorum
@Debugger022

Copy link
Copy Markdown
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant