# Extraordinary proposals can receive more tokens than eligible

Ajna ExtraordinaryFunding validates token request limit only at proposal time, so concurrent proposals can each request a stale, now-too-large amount and overdraw treasury.

- Payout: Contest reward
- Severity: medium
- Program: Ajna
- Credited: berndartmueller
- Disclosed: 2022-12-21
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-ajna-judging/issues/124
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-ajna%3AM-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:governance

**Target:** ExtraordinaryFunding grant proposal contract
**Root cause:** The treasury-slice limit on tokensRequested is checked only in proposeExtraordinary (L86), not re-validated at execution; the limit shrinks as funded proposals accumulate.
**Steps:**
1. Submit two extraordinary proposals at similar times while funded-proposal count is unchanged, each requesting up to getSliceOfTreasury(WAD - minThreshold).
2. Both pass the L86 check since the limit is identical at proposal time.
3. Let the first proposal pass voting and execute, lowering the treasury slice limit.
4. Execute the second proposal; its stale tokensRequested exceeds the now-lower limit but is not re-checked, overpaying tokens.
**How found:** Code reading of proposeExtraordinary: noticed the limit check uses current funded-proposal count and is never re-applied at execution, making tokensRequested stale across the 1-month voting window.
**Exploitation:** Attacker proposes multiple extraordinary proposals concurrently to lock in the higher token limit, then executes them sequentially after voting so each pays out the stale larger amount.
**Insight:** When a cap depends on mutable global state (funded-proposal count), check whether it is enforced only at creation; execution-time re-validation gaps let concurrent proposals each pass a stale cap.