# Claiming outstanding utility tokens from vMaia vault DoS on pbHermes<>bHermes conversion rate > 1

vMaia's claimOutstanding() reverts permanently once owner raises pbHermes<>bHermes conversion rate above 1, because vMaia modifiers ignore the rate.

- Payout: Contest reward
- Severity: medium
- Program: Maia DAO Ecosystem
- Credited: 0xTheC0der
- Disclosed: 2023-09-18
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-05-maia-findings/issues/470
- Library page: https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-23
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** vMaia ERC-4626 vault / ERC4626PartnerManager.claimOutstanding()
**Root cause:** vMaia overrides checkWeight/checkGovernance/checkPartnerGovernance modifiers comparing raw balanceOf against amount+claimed, ignoring the conversion rate; the correct rate-aware modifiers exist in ERC4626PartnerManager but are shadowed.
**Steps:**
1. Deploy vMaia with owner able to call increaseConversionRate
2. Deposit Maia via testDepositMaia()
3. Owner calls `vmaia.increaseConversionRate(bHermesRate * 2)`
4. Call `vmaia.claimOutstanding()` -> reverts with InsufficientShares
5. Attempt `vmaia.increaseConversionRate(bHermesRate)` to undo -> reverts InvalidRate (rate only increases)
**How found:** Code reading: noticed vMaia re-declares the check* modifiers without conversion-rate math, while ERC4626PartnerManager already has correct rate-aware versions; hypothesized mismatch once rate >1 and confirmed with Foundry PoC.
**Exploitation:** Owner raising conversion rate >1 bricks claimOutstanding() permanently since rate cannot be decreased and vault is non-upgradeable; users lose unclaimable utility tokens and integrating contracts calling claimOutstanding() break.
**Insight:** When a child contract overrides validation modifiers that a parent already implements correctly, check whether the override drops state (here the conversion rate) that the parent's version accounts for; shadowed/duplicated modifiers are a recurring source of permanent DoS.