# YieldStakingBase::collectFeeToTreasury will attempt to transfer funds that are not available, resulting in repetitive revert and potential DOS

collectFeeToTreasury transfers totalUnstakeFine before fines are actually repaid, causing reverts and potential DOS of fee collection.

- Payout: Contest reward
- Severity: medium
- Program: BendDAO
- Credited: oakcobalt
- Disclosed: 2025-01-22
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-12-benddao-invitational#m-02
- Library page: https://bugbountylibrary.com/r/c4%3A2024-12-benddao-invitational%3AM-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** YieldStakingBase.sol fee collection and unstake/repay accounting
**Root cause:** totalUnstakeFine is incremented during _unstake before the fine is actually available; collectFeeToTreasury transfers totalUnstakeFine - claimedUnstakeFine, which may exceed the contract's available balance.
**Steps:**
1. Bot calls `_unstake` with `unstakeFine`, incrementing `totalUnstakeFine` while funds are not yet claimable.
2. Pool admin calls `collectFeeToTreasury()`, which computes `amountToCollect = totalUnstakeFine - claimedUnstakeFine`.
3. `underlyingAsset.safeTransfer(to, amountToCollect)` reverts because the fine has not been repaid via `_repay`.
4. If user cannot repay, `totalUnstakeFine` is never recovered, permanently DOSing collection.
**How found:** Code reading of the unstake accounting: noticed totalUnstakeFine incremented before funds are available, then traced collectFeeToTreasury's transfer of that unbacked amount.
**Exploitation:** Race a pending collectFeeToTreasury with a bot unstake tx, or rely on unrepayable positions so the fine is never funded, causing repeated reverts.
**Insight:** When accounting variables are incremented at state-change time but the underlying funds only arrive later (repay/claim), check every consumer that treats the counter as a real balance.