# Governor - Quorum could be less than intended

Governor computes quorumVotes at propose time, but tokens minted in the same block still count as past votes, letting quorum fall below intended supply.

- Payout: Contest reward
- Severity: medium
- Program: Nouns Builder
- Credited: Picodes
- Disclosed: 2022-11-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-nouns-builder-findings/issues/195
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-nouns-builder%3AM-19
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:governance

**Target:** Governor governance contract (propose/quorum logic)
**Root cause:** proposal.quorumVotes is snapshotted during propose() from current totalSupply, but getPastVotes counts tokens minted later in the same block, so the effective quorum is lower than the actual supply at vote time.
**Steps:**
1. Call `Governor.propose()` which stores `proposal.quorumVotes` from current totalSupply.
2. In the same block, mint additional tokens to an address.
3. During voting, `token.getPastVotes(account, proposal.timeCreated)` includes those newly minted tokens.
4. Quorum threshold is now lower relative to actual total supply, easing proposal passage.
**How found:** Code reading of propose() quorum snapshot versus getPastVotes checkpoint semantics; noticed minting in the same block is counted as past votes.
**Exploitation:** Attacker mints tokens in the same block as proposal creation so the stored quorumVotes understates the real supply; the extra tokens also vote, lowering the effective threshold needed to pass a malicious proposal.
**Insight:** When a governance contract snapshots a threshold from live totalSupply but reads votes via historical checkpoints, check whether same-block mints/burns are counted by the checkpoint but not the snapshot — that gap shifts the effective quorum.