# Time calculation issues with exponential decay

OCE_ZVE exponential-decay emissions use stale lastDistribution timestamp, so idle time since deployment unlocks a large reward chunk immediately at first distribution.

- Payout: Contest reward
- Severity: medium
- Program: Zivoe
- Credited: AMOW
- Disclosed: 2024-03-19
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-03-zivoe-judging/issues/282
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-zivoe%3AM-9
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:business-logic vuln:reward-distribution

**Target:** OCE_ZVE.sol reward locker (Solidity/EVM)
**Root cause:** lastDistribution is set at construction and only updated inside forwardEmissions, so block.timestamp - lastDistribution includes idle periods before any distribution, inflating the decayed (unlocked) amount.
**Steps:**
1. Deploy OCE_ZVE; constructor sets `lastDistribution = block.timestamp`.
2. Wait idle period (e.g. `hevm.warp(block.timestamp + 365 days)`).
3. Fund contract with ZVE (`deal(address(ZVE), address(OCE_ZVE_Live), 20000e18)`).
4. Call `OCE_ZVE_Live.forwardEmissions()`; `decay(zveBalance, block.timestamp - lastDistribution)` uses the full idle elapsed time.
5. Observe a large portion forwarded immediately instead of decaying from zero.
**How found:** Code reading of the constructor and forwardEmissions revealed lastDistribution is only reset on distribution, combined with the Figma timeline showing deployment precedes funding by 30+ days.
**Exploitation:** Trigger forwardEmissions after a long idle gap so nearly the whole balance is treated as unlocked and forwarded/distributed at once, defeating the intended gradual decay schedule.
**Insight:** When a decay/vesting formula keys off a timestamp set at deployment, check whether the first real distribution inherits all pre-funding idle time; the reset path may itself require a costly minimum action.