# Options can be exercised preemptively due to timing delays

TapiocaOptionBroker checks exercise cooldown by timestamp but accounts rewards by epoch number, letting users exercise early and drain same-epoch rewards.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca DAO
- Credited: carrotsmuggler
- Disclosed: 2024-05-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/119
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-14
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window vuln:business-logic vuln:reward-distribution

**Target:** TapiocaOptionBroker.sol options exercise/reward accounting
**Root cause:** OneEpochCooldown is enforced via block.timestamp while netDepositedForEpoch accounting and reward eligibility use the epoch number, which can lag behind the elapsed week.
**Steps:**
1. Alice calls `participate` at start of epoch 1; netDepositedForEpoch[2] increases by her shares.
2. Wait one week (EPOCH_DURATION) without newEpoch() being called.
3. Call `exerciseOption`; passes `block.timestamp < entry + EPOCH_DURATION` check while epoch is still 1.
4. Rewards computed as `ybShares * gaugeTotalForEpoch / netAmount[1]` using stale netAmount, over-claiming.
5. Other depositors cannot collect rewards due to depleted pool.
**How found:** Noticed cooldown uses block.timestamp while reward accounting uses epoch number, and reasoned the two can desynchronize when exercise happens before newEpoch() is called.
**Exploitation:** Time participation to the start of an epoch, wait exactly one week, and exercise before anyone advances the epoch, claiming rewards from the same epoch at an inflated share of a stale netAmount denominator.
**Insight:** When a protocol mixes wall-clock cooldowns with epoch-indexed accounting, look for windows where the epoch counter lags the timestamp and rewards are computed against a stale denominator.