# Incorrect Reward Distribution Calculation in ProtocolRewardsPool

ProtocolRewardsPool.getReward compares eUSD share count to reward amount, overpaying users when share price exceeds 1 eUSD.

- Payout: Contest reward
- Severity: medium
- Program: Lybra Finance
- Credited: No12Samurai
- Disclosed: 2023-08-21
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-06-lybra-findings/issues/604
- Library page: https://bugbountylibrary.com/r/c4%3A2023-06-lybra%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution vuln:share-inflation

**Target:** ProtocolRewardsPool.getReward() reward distribution
**Root cause:** getReward() compares EUSD.sharesOf(address(this)) (share count) directly against reward (eUSD amount) instead of converting shares to eUSD via getMintedEUSDByShares, so the balance check and eUSDShare computation mix units.
**Steps:**
1. Set rewards[msg.sender] = 10e18 (10 eUSD).
2. Contract holds 9 eUSD shares, each worth 10 eUSD (90 eUSD value).
3. Call `getReward()`; balance(9) < reward(10), so eUSDShare = reward - balance = 1.
4. Contract transfers 1 share (~10 eUSD) via transferShares, then since reward > eUSDShare, sends reward - eUSDShare = 9 eUSD in peUSD/stableToken.
5. User receives ~19 eUSD value for a 10 eUSD reward.
**How found:** Code review of getReward() noticing sharesOf() returns shares while reward is denominated in eUSD, and the ternary compares the two directly.
**Exploitation:** Any user with accrued rewards calls getReward(); when eUSD share price > 1, the share-vs-amount mismatch causes overpayment in eUSD shares plus peUSD/stableToken, draining pool value over repeated claims.
**Insight:** In rebasing/share-based tokens (eUSD), audit every comparison and subtraction between a sharesOf() balance and an amount-denominated variable; unit mismatch silently overpays when share price != 1.