# Vault rewards last claim time not always initialized

Uninitialized last-claim timestamp for synths a member never deposited lets harvest compute secondsSinceClaim as full block.timestamp, inflating rewards.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Disclosed: 2021-06-14
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-04-vader-findings/issues/223
- Library page: https://bugbountylibrary.com/r/c4%3A2021-04-vader%3AH-19
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity vuln:accounting-error vuln:business-logic vuln:reward-distribution

**Target:** Vault rewards harvest/calcCurrentReward contract logic
**Root cause:** mapMemberSynth_lastTime[member][synth] is only set on deposit, but harvest allows claiming any synth; for undeposited synths the timestamp is zero, so _secondsSinceClaim = block.timestamp - 0 equals the full block timestamp.
**Steps:**
1. Call harvest for a synth the member never deposited.
2. calcCurrentReward computes `_secondsSinceClaim = block.timestamp - mapMemberSynth_lastTime[member][synth]` where the mapping entry is 0.
3. Resulting _secondsSinceClaim equals current block.timestamp, maximizing accrued rewards.
4. Claim the inflated reward amount.
**How found:** Code reading of calcCurrentReward: noticed the lastTime mapping is only initialized on deposit while harvest permits claiming arbitrary synths, making the subtraction default to block.timestamp.
**Exploitation:** Attacker harvests synths they never deposited, so the last-claim time defaults to zero and secondsSinceClaim becomes the entire block timestamp, yielding a huge reward payout.
**Insight:** When a reward accrual subtracts a per-user-per-asset timestamp, check whether that timestamp is initialized for every asset the claim path accepts, not just the deposit path.