# `accPointsPerShare` can reach a very large value leading to overflows

First depositor with 1 wei inflates accPointsPerShare to 54+ decimals, causing uint256 overflow in pendingPoints when a later user deposits 10,000 tokens.

- Payout: Contest reward
- Severity: medium
- Program: Sophon
- Credited: ZdravkoHr.
- Disclosed: 2024-05-13
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-sophon-judging/issues/36
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-sophon%3AM-1
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:precision-loss

**Target:** SophonFarming staking/rewards contract (Solidity)
**Root cause:** accPointsPerShare accumulates pointReward/lpSupply with 36-decimal precision; when lpSupply is 1 wei the per-share value stays at 36 decimals, and _pendingPoints multiplies it by 1e18 again then by user.amount, exceeding uint256.
**Steps:**
1. Deploy MockERC20 (18 decimals) and add pool via `sophonFarming.add(60000, usdc, "", false)`.
2. Deposit 1 wei of the LP token as first depositor: `sophonFarming.deposit(usdcId, 1, 0)`.
3. Advance one block: `vm.roll(block.number + 1)` and call `massUpdatePools()` so accPointsPerShare = pointReward/1 (36 decimals).
4. Second user deposits 10_000e18 - 1 tokens.
5. Advance block, call `massUpdatePools()`, then `getPendingPoints(users)` — reverts on `user.amount * accPointsPerShare` overflow.
**How found:** Code reading of updatePool/_pendingPoints: noticed pointReward has 36 decimals and is divided by lpSupply; hypothesized small lpSupply (1 wei) preserves full precision, then traced the extra 1e18 scaling and user.amount multiplication to overflow.
**Exploitation:** Attacker is first depositor with 1 wei; after one block accPointsPerShare holds 36-decimal magnitude. Any subsequent sizable deposit makes `user.amount * accPointsPerShare * 1e18` exceed type(uint256).max, reverting getPendingPoints and massUpdatePools-dependent flows.
**Insight:** In reward-per-share accounting, check the decimal scaling of the accumulator against the smallest possible lpSupply (1 wei first depositor); a division by 1 preserves full precision that later multiplications can overflow.