# MerkleReserveMinter minting methodology is incompatible with current governance structure and can lead to migrated DAOs being hijacked immediately

MerkleReserveMinter lets a user mint many reserved tokens in one tx, then create a proposal snapshotting pre-mint supply, letting them pass a treasury-draining proposal with low quorum.

- Payout: Contest reward
- Severity: medium
- Program: Nounsbuilder
- Credited: 0x52
- Disclosed: 2023-09-14
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-09-nounsbuilder-judging/issues/249
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-09-nounsbuilder%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:chained vuln:accounting-error vuln:business-logic vuln:governance

**Target:** MerkleReserveMinter / Governor governance contracts
**Root cause:** Governor.quorum() snapshots totalSupply at proposal creation, but MerkleReserveMinter allows minting an arbitrary number of reserved tokens in a single transaction, so votes acquired after the snapshot vastly exceed the quorum computed from the pre-mint supply.
**Steps:**
1. Attacker is in the reserve merkle tree with a large share of reserved tokens.
2. In one transaction: call Governor.propose() to create a malicious proposal (snapshots current totalSupply and quorum).
3. Call MerkleReserveMinter.mintFromReserve() with all claim proofs to mint many tokens to self.
4. Call Governor.castVote() on the proposal with the freshly minted tokens, exceeding the low quorum.
5. Proposal passes and executes treasury drain; later proposals cannot outvote since only tokens at snapshot count.
**How found:** Code review of MerkleReserveMinter's unbounded loop minting vs Governor.quorum() using current totalSupply at proposal creation; noticed snapshot-before-mint vs votes-after-mint mismatch.
**Exploitation:** Attacker mints all reserved tokens in the same block as proposal creation, so quorum is computed from the small pre-mint supply while their voting power reflects the post-mint supply, giving them a majority to pass a proposal draining the DAO treasury or mint fees.
**Escalation:** Chained with DAO migration: treasury transferred to L2 before reserve mint ends lets attacker drain full L1 treasury; also can steal accumulated mint fees.
**Insight:** When a governance quorum is derived from live totalSupply but votes are counted at a later snapshot, look for any mint path (reserve/airdrop/claim) that lets one actor inflate supply between propose() and castVote() in a single transaction.