# Penrose::_depositFeesToTwTap can unexpectedly revert due to amount rounded down

Penrose._depositFeesToTwTap recomputes withdrawn fee amount from shares after withdrawal, so rounding drift makes the transfer revert and DoS fee deposits.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca
- Credited: cergyk
- Disclosed: 2024-02-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-tapioca-judging/issues/43
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AM-7
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:dos vuln:precision-loss

**Target:** Penrose.sol _depositFeesToTwTap fee withdrawal logic
**Root cause:** The amount actually withdrawn is computed from shares before withdrawal, but the code recomputes the amount from shares again after withdrawal; rounding direction differs between the two computations, so the recomputed amount can exceed what was withdrawn.
**Steps:**
1. Call _depositFeesToTwTap which withdraws fees via the fee token's withdraw at Penrose.sol#L573.
2. Observe the withdrawn amount is recomputed from shares at Penrose.sol#L576 instead of using the returned amount.
3. With base=7, elastic=13, share=2: pre-withdrawal amount = 13*2/7 = 3 (rounded down), shares deducted = 2.
4. Post-withdrawal state base=5, elastic=10, share=2: recomputed amount = 10*2/5 = 4.
5. Transfer of 4 reverts because only 3 was actually withdrawn, DoSing fee withdrawal.
**How found:** Code reading of the fee withdrawal path: noticed the withdrawn amount is recomputed from shares after withdrawal rather than using the actual withdrawn amount, then constructed a rounding example where pre- and post-withdrawal share math diverge.
**Insight:** When a contract recomputes a value from shares after mutating state, check whether rounding direction can flip between the two computations; a pre-withdrawal floor and post-withdrawal ceil (or vice versa) creates a mismatch that reverts transfers.