# Not enough TAP tokens to exercise if a user participates and exercises in the same epoch

TapiocaOptionBroker computes eligible TAP from live totalPoolDeposited, so same-epoch participate+exercise inflates denominator and later users' exercises revert.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: KIntern\_NA
- Disclosed: 2023-11-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/1101
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-26
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error vuln:business-logic

**Target:** TapiocaOptionBroker participate/exerciseOption gauge accounting
**Root cause:** eligibleTapAmount uses the current totalPoolDeposited at exercise time rather than a snapshot, so a new participant joining mid-epoch changes the denominator for everyone and total minted can exceed gaugeTotalForEpoch.
**Steps:**
1. Alice and Bob participate with position.amount=1 each; gaugeTotalForEpoch=60, totalPoolDeposited=2.
2. Alice calls `exerciseOption()`: eligible = 1*60/2 = 30 TAPs minted.
3. Candice participates (amount=1) and immediately calls `exerciseOption()`: eligible = 1*60/3 = 20 TAPs minted.
4. Bob calls `exerciseOption()`: eligible = 1*60/3 = 20, but 30+20+20=70 > 60, so mint reverts and Bob cannot exercise.
**How found:** Reasoned about the eligibleTapAmount formula and noticed totalPoolDeposited is read live, so mid-epoch participation changes the denominator for prior participants.
**Exploitation:** A user participates and exercises in the same epoch, diluting the denominator for existing participants and causing their exerciseOption calls to revert once cumulative mint exceeds gaugeTotalForEpoch.
**Insight:** When a reward/eligibility formula divides by a live pool total, check whether joining and claiming in the same accounting period lets a new entrant shift the denominator and push cumulative claims past the epoch cap.