# Attempting to Increase the Performance Fee Rate Will Lock It for Approximately 55 Years

TermMaxVault double-adds block.timestamp when timelocking a performance fee rate increase, locking the rate for ~55 years with no revoke.

- Payout: Contest reward
- Severity: medium
- Program: Term Structure
- Credited: silverologist
- Disclosed: 2025-03-20
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_term_structure_february2025.pdf#3.2.3
- Library page: https://bugbountylibrary.com/r/cantina%3Aterm_structure_february2025%3A3.2.3
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:solidity technique:source-review vuln:business-logic vuln:misconfiguration

**Target:** TermMaxVault::submitPerformanceFeeRate / PendingLib::update (Solidity vault contract)
**Root cause:** submitPerformanceFeeRate passes block.timestamp + _timelock into PendingLib::update, which itself adds block.timestamp to validAt, so validAt = 2*block.timestamp + _timelock. No revoke function exists and resubmission reverts with AlreadyPending.
**Steps:**
1. Call `vault.submitPerformanceFeeRate(newPercentage)` as curator with newPercentage > current rate.
2. Observe performanceFeeRate() unchanged (timelocked).
3. Assert `vault.pendingPerformanceFeeRate().validAt == block.timestamp * 2 + vault.timelock()`, confirming ~55-year lock.
4. Attempt resubmission: reverts with AlreadyPending; no revoke path exists.
**How found:** Code review of the timelock flow: noticed submitPerformanceFeeRate pre-adds block.timestamp while PendingLib::update adds it again, then confirmed via a Foundry test asserting validAt == block.timestamp*2 + timelock.
**Insight:** When a helper library already adds block.timestamp to a timelock, callers passing an absolute deadline double-count it; grep for `block.timestamp +` at call sites of pending/timelock update helpers and check for a revoke/cancel path before assuming recoverability.