# Many cases `stEth::transferFrom` will transfer 1-2 less way, which would result in revert in consequent functions, because of not enough balance

SophonFarming's depositStEth passes user _amount to wstETH.wrap after stETH transferFrom delivers 1-2 wei less due to share rounding, reverting deposits.

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

**Target:** Solidity farming contract depositStEth / stETH transferFrom
**Root cause:** stETH tracks balances via shares; transferFrom of _amount can move 1-2 wei less than requested due to rounding, but the code wraps the original _amount, exceeding actual balance.
**Steps:**
1. Call `depositStEth(_amount, ...)` with an amount where share rounding loses 1-2 wei
2. `IERC20(stETH).safeTransferFrom(msg.sender, address(this), _amount)` credits `_amount - 1/2`
3. `_depositPredefinedAsset(_amount, ...)` calls `_stEthTOwstEth(_amount)` → `IwstETH(wstETH).wrap(_amount)`
4. wrap reverts since contract holds less stETH than `_amount`
**How found:** Known Lido stETH share-rounding behavior (lido-dao issue #442) applied to Sophon's deposit path; traced _amount from transferFrom into wstETH.wrap.
**Insight:** When integrating rebasing/share-based tokens like stETH, never reuse the requested amount downstream—measure actual balance delta or use transferShares, since share rounding silently shortchanges transfers.