Rio Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Rio Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 20
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 20 closed, publicly disclosed Rio Network reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Front-running / MEV, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Rio Network
- Front-running / MEV findings disclosed against Rio Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Rio Network: Heap is incorrectly stores the removed operator ID which can lead to division by zero in deposit/withdrawal flow
Rio Network's operator utilization heap fails to clear the trailing operator slot when an operator is removed, leaving a stale operator ID behind at the old heap boundary. When an admin resets an operator's strategy cap to zero (the intended workflow for unwinding an operator), the removal path stores the old element instead of zeroing it, so a later heap rebuild during deposit/rebalance reads that stale entry and divides its allocation by the now-zero cap. This triggers an unconditional DivWadFailed revert that permanently blocks deposits and withdrawals for that strategy, freezing user funds. The Sherlock escalation process confirmed the finding as High severity with duplicates, and the protocol patched it by zeroing operator slots above the last heap index.
Rio Network: Depositing to EigenLayer can revert due to round downs in converting shares<->assets
Rio Network's restaking deposit path converts underlying stETH to EigenLayer strategy shares and back to token amounts during operator allocation. Because both conversions round down by the shared 1e3 virtual offset, the token amount derived from shares can be one unit short of the original deposit, so the strict equality check at the end of depositTokenToOperators reverts the entire rebalance. This means a routine deposit-pool rebalance can fail permanently unless the deposit size happens to divide exactly, leaving the owner to manually airdrop funds to realign the token/share ratio. The developer removed the strict share-count equality check and added a sync function to reconcile Rio's internal operator share allocation with EigenLayer's recorded allocation.
Rio Network: swapValidatorDetails incorrectly writes keys to memory, resulting in permanently locked beacon chain deposits
In the Rio Network LRT core protocol, the assembly routine in ValidatorDetails.swapValidatorDetails reconstructs 48-byte BLS public keys in memory using two mstore calls, but the second call shifts _part2 right by 128 bits and writes at an offset that overwrites the middle 16 bytes of _part1 with zeros. The resulting malformed keys are then loaded by allocateETHDeposits and forwarded to stakeETH, which deposits 32 ETH per allocation to the beacon chain DepositContract using a public key whose associated private key is unknown, permanently locking the funds. The finding was confirmed by the protocol team, fixed by reordering the two mstore operations for both keys so _part1 overwrites the zeroed middle bytes, and signed off by the Lead Senior Watson.
Rio Network: The current idea of creating reETH and accepting several different assets in it exposes RIO users to losses
Rio Network's planned liquid restaking tokens pool multiple underlying assets into a single share token, and because the protocol's share price only reflects a wrapped staking token's market rate once the price feed actually updates, an outside attacker can exploit the lag. By depositing wrapped tokens (e.g. cbETH/wstETH) immediately before a predictable price drop — such as an unfolding slashing event or a large monitored unstake — and withdrawing a mixed basket after the drop, the attacker converts what would have been their own loss into a loss shared by all existing reETH depositors. The illustrative scenario shows a 50% drop letting an attacker extract value while a realistic 8–10% drop remains bounded and cannot be amplified with flash loans. The Sherlock lead judge upheld it as a valid medium, noting the economic exposure should have been declared an accepted risk in the contest brief, and the fix is non-trivial with several proposed mitigations.
Rio Network: The protocol can't receive rewards because of low gas limits on ETH transfers
Rio Network's Asset::transferETH() forwards every native ETH payment with a hardcoded 10_000 gas limit. When EigenLayer rewards are claimed through DelayedWithdrawalRouter, the ETH is pushed into RioLRTOperatorDelegator receive(), which forwards to RioLRTRewardDistributor receive(), which forwards onward to the treasury, operator reward pool and deposit pool. The accumulated cost of this chained internal forwarding exceeds 10_000 gas, so the whole claim reverts out-of-gas, permanently blocking reward distribution and leaving the ETH trapped in the delayed withdrawal queue. The team fixed it by removing the hardcoded gas limit and the lead judge signed off.
Rio Network: Slashing penalty is unfairly paid by a subset of users if a deficit is accumulated.
Rio's withdraw queue, in settleEpochFromEigenLayer(), computes assetsReceived from the raw ETH returned by EigenLayer's completeQueuedWithdrawal, without accounting for a possible negative share deficit in the EigenPodManager. If validators are slashed on the consensus layer while their ETH is queued for withdrawal, that deficit is silently absorbed by the first cohort that settles, while later cohorts settle at full value. The result is an unfair wealth transfer: the PoC shows cohort 0 receiving 0 ETH (paying the entire 8 ETH penalty) while cohort 1 receives its full 31.99 ETH. The finding was upheld as Medium/Unique after an escalation argued slashing was out of scope.
All reports in this group
- Rio Network: A part of ETH rewards can be stolen by sandwiching `claimDelayedWithdrawals()`Logic error$0
- Rio Network: Ether can stuck when an operators validators are removed due to an user front-runningLogic error$0
- Rio Network: `requestWithdrawal` doesn't estimate accurately the available shares for withdrawalsLogic error$0
- Rio Network: Requested withdrawal can be impossible to settle due to EigenLayer shares value appreciate when there are idle funds in deposit poolLogic error$0
- Rio Network: `reportOutOfOrderValidatorExits` does not updates the heap orderLogic error$0
- Rio Network: Setting the strategy cap to "0" does not update the total shares held or the withdrawal queueLogic error$0
- Rio Network: All operators can have ETH deposits regardless of the cap setted for them leading to miscalculated TVLLogic error$0
- Rio Network: Deposits may be front-run by malicious operator to steal ETHFront-running / MEV$0
- Rio Network: RioLRTIssuer::issueLRT reverts if deposit asset's approve method doesn't return a boolLogic error$0
- Rio Network: ETH withdrawers do not earn yield while waiting for a withdrawalLogic error$0
- Rio Network: Creating new withdrawal requests in conjunction with `settleEpochFromEigenLayer` will render system unusableLogic error$0
- Rio Network: Execution Layer rewards are lostLogic error$0
- Rio Network: Stakers can avoid validator penaltiesFront-running / MEV$0
- Rio Network: Malicious operators can `undelegate` theirselves to manipulate the LRT exchange rateLogic error$0