# Depositing to EigenLayer can revert due to round downs in converting shares<->assets

Round-down in EigenLayer shares<->assets conversion makes depositTokenToOperators' sharesReceived check revert, blocking rebalance deposits of stETH.

- Payout: Contest reward
- Severity: medium
- Program: Rio Network Core Protocol
- Credited: 0xkaden
- Disclosed: 2024-02-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-rio-network-core-protocol-judging/issues/9
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-rio-network-core-protocol%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:** RioLRTDepositPool / OperatorOperations deposit path into EigenLayer StrategyBase
**Root cause:** convertToSharesFromAsset rounds down when computing sharesToAllocate, then sharesToUnderlyingView rounds down again for token allocation; re-staking those tokens mints one fewer share than sharesAllocated, so the strict equality check reverts.
**Steps:**
1. Deposit pool holds 111e18 stETH; EigenLayer strategy has 3333e18 tokens, 3232e18 shares, offsets 1e3.
2. rebalance() -> depositBalanceIntoEigenLayer -> convertToSharesFromAsset yields sharesToAllocate = 107636363636363636364.
3. allocateStrategyShares calls sharesToUnderlyingView(newShareAllocation) -> newTokenAllocation = 110999999999999999999 (rounds down).
4. stakeERC20 stakes 110999999999999999999 tokens, minting 107636363636363636363 shares.
5. sharesReceived (…363) != sharesAllocated (…364) -> revert INCORRECT_NUMBER_OF_SHARES_RECEIVED.
**How found:** Traced the deposit flow into EigenLayer and noticed two sequential round-down conversions (underlying->shares then shares->underlying) feeding a strict equality check; constructed numeric example with virtual share/balance offsets to show off-by-one share mismatch.
**Insight:** When a protocol converts value through a third-party share-based vault and then re-verifies the result with strict equality, check whether the two conversions round in opposite directions; virtual share/balance offsets make off-by-one mismatches common even at large amounts.