# Rewards will be locked in LQTYStaking Contract

LQTYStaking.increaseF_Collateral rounds down to zero when totalLQTYStaked is large, so small WBTC redemption fees are never distributed and stay locked.

- Payout: Contest reward
- Severity: high
- Program: Ethos Reserve
- Credited: gjaldon
- Disclosed: 2023-05-02
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-02-ethos-findings/issues/285
- Library page: https://bugbountylibrary.com/r/c4%3A2023-02-ethos%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss vuln:reward-distribution

**Target:** LQTYStaking.sol increaseF_Collateral reward accounting
**Root cause:** collFeePerLQTYStaked = _collFee * 1e18 / totalLQTYStaked truncates to 0 when the fee is small relative to total staked LQTY, and the remainder is never carried forward.
**Steps:**
1. Stake 10,000,000e18 LQTY so totalLQTYStaked = 1e25.
2. Call `increaseF_Collateral(wbtc, 9e6)` (0.09 WBTC fee): (9e6*1e18)/1e25 = 0.9 -> 0, F_Collateral unchanged.
3. Call `increaseF_Collateral(wbtc, 1e7)` (0.1 WBTC): (1e7*1e18)/1e25 = 1 -> F_Collateral increments.
4. Run `npx hardhat test --grep "does not increase F collateral even with large amount of collateral fee"`.
**How found:** Code reading of increaseF_Collateral's fixed-point division; noticed DECIMAL_PRECISION scaling combined with low WBTC decimals and large totalLQTYStaked yields sub-1 results truncated to zero.
**Exploitation:** Not an attacker action; protocol-side accounting bug. RedemptionHelper/ActivePool send collateral fees to LQTYStaking, but increaseF_Collateral records zero, so fees accumulate in the contract and are never claimable by stakers.
**Insight:** In reward-per-share accumulator patterns, check whether the multiply-then-divide can truncate to zero for low-decimal tokens (WBTC/USDC) at realistic total-staked magnitudes; the fix is carrying a remainder error term like _computeLQTYPerUnitStaked's lastLQTYError.