# Owner can collect management fees with a new increased fee for previous time period.

Popcorn Vault owner can raise management fee and retroactively charge the higher rate over the entire prior period since feesUpdatedAt isn't reset on fee change.

- Payout: Contest reward
- Severity: medium
- Program: Popcorn
- Credited: GreedyGoblin
- Disclosed: 2023-09-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-popcorn-findings/issues/466
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-popcorn%3AM-19
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Vault.sol management fee accounting
**Root cause:** feesUpdatedAt is only updated inside takeFees() when managementFee>0, and changeFees()/proposeFees() never checkpoint accrued fees, so accruedManagementFee() applies the new rate to the whole elapsed period.
**Steps:**
1. Create vault with management fee = 0
2. Wait x days without collecting fees
3. Call proposeFees() then changeFees() after rage quit period to set a higher management fee
4. Call takeManagementAndPerformanceFees(); accruedManagementFee() computes newRate * (block.timestamp - feesUpdatedAt) covering the entire period since last collection
**How found:** Code reading of takeFees() modifier and accruedManagementFee(): noticed feesUpdatedAt only advances when managementFee>0 and is untouched by changeFees(), implying retroactive application.
**Exploitation:** Vault owner sets fee to 0, lets time accrue, then raises fee and collects, minting fee shares computed at the new rate over the full elapsed window, diluting depositors.
**Insight:** In fee-accrual vaults, check whether the accrual checkpoint is updated on parameter changes (fee rate, recipient); any rate change without a prior checkpoint lets the new rate apply to the whole elapsed interval.