# Accumulated rewards per share can round to zero

RewardsTracker's accQuoteRewardsPerShare rounds to zero when pendingQuoteRewards*1e12 < totalShares, so USDC rewards get stuck in Distributor and users lose payouts.

- Payout: Contest reward
- Severity: medium
- Program: GTE
- Credited: hgrano
- Disclosed: 2026-02-05
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-08-gte-perps-and-launchpad#m-16
- Library page: https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-16
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss vuln:reward-distribution

**Target:** RewardsTracker.sol / Distributor claim accounting
**Root cause:** accQuoteRewardsPerShare += (pendingQuoteRewards * PRECISION_FACTOR) / totalShares with PRECISION_FACTOR=1e12; when totalShares exceeds pendingQuoteRewards*1e12 the integer division truncates to zero.
**Steps:**
1. Set quote token to USDC (6 decimals); pendingQuoteRewards = 1000e6.
2. totalShares ~ hundreds of millions of ether (BONDING_SUPPLY = 800_000_000 ether).
3. Call Distributor::claim; line RewardsTracker.sol:225 computes (1000e6 * 1e12) / totalShares.
4. With totalShares > 1000e18 the division yields 0, adding nothing to accQuoteRewardsPerShare.
5. Rewards remain unclaimable, stuck in Distributor.
**How found:** Code reading of the reward-per-share accumulation formula; noticed PRECISION_FACTOR is only 1e12 and reasoned about USDC's 6 decimals combined with the hardcoded 800M ether BONDING_SUPPLY making totalShares large relative to small per-swap USDC rewards.
**Exploitation:** Not an attack; a user calling claim triggers the truncation and their accrued rewards are silently lost/stuck in the Distributor contract.
**Insight:** When auditing reward-per-share accumulators, check the precision factor against the smallest-decimal quote token and the largest plausible totalShares; truncation to zero silently strands funds rather than reverting.