# Nobody can cast for any proposal

GovernorBravoDelegate.castVoteInternal calls gOHM.getPriorVotes with block.number, which always reverts, bricking all voting in Olympus governance.

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

**Target:** GovernorBravoDelegate governance contract / gOHM token getPriorVotes
**Root cause:** castVoteInternal passes block.number to gOHM.getPriorVotes, but gOHM requires blockNumber < block.number, so the call always reverts.
**Steps:**
1. Read GovernorBravoDelegate.castVoteInternal L446: `gohm.getPriorVotes(voter, block.number)`
2. Check gOHM mainnet getPriorVotes: `require(blockNumber < block.number, "gOHM::getPriorVotes: not yet determined")`
3. Fork mainnet in Foundry and call `IGOHM(gOHM).getPriorVotes(addr, block.number)` -> reverts
4. Call with `block.number - 1` -> succeeds, confirming off-by-one
**How found:** Code-reading of the voting path against the deployed gOHM getPriorVotes implementation revealed the strict `< block.number` requirement conflicting with the passed block.number.
**Insight:** When integrating external vote-escrow/governance tokens, verify the exact block-number boundary semantics of getPriorVotes (strict less-than vs less-or-equal) against the deployed implementation, not just the interface.
