# Adversary can lock every deposit forever by making a deposit with _expiration = type(uint256).max

Depositor sets _expiration to type(uint256).max, overflowing depositTime+expiration in getLockedFunds and permanently reverting all refunds.

- Payout: Contest reward
- Severity: high
- Program: Openq
- Credited: GimelSec
- Disclosed: 2023-01-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-openq-judging/issues/362
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-1
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** DepositManagerV1/BountyCore refund logic
**Root cause:** fundBountyToken accepts arbitrary _expiration stored in expiration mapping; getLockedFunds computes depositTime+expiration without overflow protection, so a max value reverts the loop.
**Steps:**
1. Call `DepositManagerV1#fundBountyToken` with `_expiration = type(uint256).max`
2. BountyCore#receiveFunds stores expiration[depositId] = type(uint256).max
3. Any `refundDeposit` call iterates deposits and evaluates `depositTime[dep] + expiration[dep]` in getLockedFunds
4. Addition overflows and reverts, so refundDeposit always reverts
**How found:** Code reading of refund path: noticed user-controlled _expiration flows unchecked into arithmetic in getLockedFunds, hypothesized overflow with max value.
**Exploitation:** Attacker makes a minimal deposit with max expiration; thereafter every refundDeposit call reverts because getLockedFunds loops over all deposits including the poisoned one, trapping all deposited tokens.
**Escalation:** Combined with payout-breaking methods, all deposited tokens become permanently stuck.
**Insight:** When a user-supplied duration/timestamp is stored and later added to block.timestamp in a loop over all entries, one poisoned entry bricks the whole loop—check unbounded time values against uint128/uint64 caps.