# The protocol can't receive rewards because of low gas limits on ETH transfers

Hardcoded 10k gas in Asset.transferETH reverts when RioLRTOperatorDelegator forwards ETH rewards to the distributor, blocking reward claims and stranding funds.

- 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/185
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-rio-network-core-protocol%3AM-5
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos

**Target:** Solidity Asset.transferETH utility / EigenLayer withdrawal claim flow
**Root cause:** Asset.transferETH uses a low-level call with a hardcoded gas: 10_000, insufficient for the nested receive() chain that forwards ETH to treasury, operator reward pool and deposit pool.
**Steps:**
1. Deposit ETH via coordinator.depositETH and rebalance into a validator
2. Simulate rewards by creating a 40 ETH validator and verifyWithdrawalCredentials
3. Call verifyAndProcessWithdrawalsForValidatorIndexes to queue the 8 ETH excess withdrawal
4. Call delayedWithdrawalRouter.claimDelayedWithdrawals(operatorDelegator, 1) -> reverts out-of-gas because transferETH caps gas at 10_000
**How found:** Code reading of Asset.transferETH's hardcoded gas limit, then tracing the EigenLayer claim flow through nested receive() functions to show the 10k budget cannot cover the downstream distributor transfers.
**Exploitation:** Not an attack; the legitimate reward-claim path reverts, permanently blocking reward receipt and stranding ETH in the delegator.
**Insight:** When auditing ETH forwarding helpers, check hardcoded gas stipends against the full downstream receive()/fallback call chain — a stipend sufficient for a plain EOA fails for contracts that fan out funds to multiple recipients.