# Post-proposal vote quorum/threshold checks use a stale total supply value

Olympus Governor Bravo stores quorum/threshold from proposal-creation total supply, so gOHM supply changes can make passing proposals impossible or trivially quorate.

- Payout: Contest reward
- Severity: medium
- Program: Olympus On Chain Governance
- Credited: IllIllI
- Disclosed: 2024-01-19
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-01-olympus-on-chain-governance-judging/issues/102
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-01-olympus-on-chain-governance%3AM-3
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:governance vuln:precision-loss

**Target:** GovernorBravoDelegate.sol governance contract
**Root cause:** propose() snapshots quorumVotes and proposalThreshold from gohm.totalSupply() at creation, but getVoteOutcome() compares against that stored raw value even though gOHM supply is elastic and changes over the voting period.
**Steps:**
1. Read `propose()`: stores `quorumVotes = getQuorumVotes()` and `proposalThreshold` from current `gohm.totalSupply()`.
2. Observe `getVoteOutcome()` compares `proposal.forVotes < proposal.quorumVotes` using the stale stored value.
3. If supply drops (burn) after creation, the stored quorum exceeds what remaining holders can reach, so proposal can never pass.
4. If supply drops below 5 (quorum) or 4 (high-risk), integer division yields zero quorum, letting any holder pass/steal.
5. Conversely supply inflation makes passing easier than intended.
**How found:** Code reading of the pessimistic vote-casting design: noticed quorum is computed from live totalSupply at propose() but compared as a stored constant at outcome time, inconsistent with OZ's GovernorVotesQuorumFraction which recomputes from current supply.
**Exploitation:** Not directly weaponized; requires an external supply-changing event (runaway burn bug or mint/burn module) to shift totalSupply between proposal creation and execution, after which the stale quorum either blocks emergency fixes or lets a tiny remaining holder pass treasury-draining proposals.
**Escalation:** Death-spiral burn scenario: no proposal can reach stale quorum to disable the burning module, and at very low supply precision loss zeroes quorum, enabling treasury theft by remaining holders.
**Insight:** When a governance token has elastic supply, any threshold stored as an absolute raw amount at proposal time drifts from the ratio it represents; check whether quorum/threshold is snapshotted vs recomputed, and whether integer division can zero it at low supply.
