Renzo — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Renzo, 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 Renzo 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 Oracle manipulation, Reentrancy, Logic error, Front-running / MEV, across EVM-Solidity, Move. 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
- Oracle manipulation findings disclosed against Renzo
- Reentrancy findings disclosed against Renzo
- Logic error findings disclosed against Renzo
- Front-running / MEV findings disclosed against Renzo
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Renzo: Lack of slippage and deadline during withdraw and deposit
Renzo Protocol's RestakeManager and WithdrawQueue contracts fail to incorporate user-defined slippage limits or execution deadlines in their primary deposit and withdrawal entry points. When users deposit collateral assets or burn ezETH, token minting and redemption rates are evaluated using dynamic TVL calculations and external oracle feeds. Because users cannot set minimum output thresholds or transaction expiration timestamps, pending transactions subject to market volatility or mempool delays can execute at unfavorable exchange rates. This missing protection exposes users to value loss from unmitigated price slippage and potential front-running during transaction settlement.
Renzo: Incorrect exchange rate provided to Balancer pools
The xRenzoDeposit contract, serving as an L2 rate provider for Balancer pools, erroneously returned a static, internal state variable instead of current market data for exchange rate calculations. This led to price divergence where pool operations were executed using stale valuations while the rest of the protocol used accurate oracle rates. This mismatch created economic opportunities for arbitrageurs to exploit the stale pricing in Balancer pools and caused systemic inaccuracies in the calculation of pool fees.
Renzo: Fetched price from the oracle is not stored in `xRenzoDeposit`
Renzo's xRenzoDeposit contract fetches prices from an external oracle inside a view function but fails to store those prices on-chain. This creates a state divergence where the contract internal record (lastPrice) remains significantly behind the actual market price. This desynchronization breaks the 10% price divergence check used for incoming price updates, causing valid updates to revert, and leads to stale pricing if the protocol ever falls back to internal storage.
Renzo: `calculateTVL` may run out of gas for modest number of operators and tokens breaking deposits, withdrawals, and trades
A Denial of Service vulnerability exists in Renzo's `RestakeManager` contract due to high gas consumption in `calculateTVLs`. The function iterates through nested loops for every operator delegator and supported token, querying strategy share balances and oracle price feeds on each iteration. As the number of operator delegators and tokens increases, the execution gas cost scales quadratically and can exceed the Ethereum block gas limit. Because `calculateTVLs` is called in core protocol operations—including deposits, withdrawals, and rate provider queries—gas limit exhaustion causes these primary protocol functions to revert and freeze operations.
Renzo: Not handling the failure of cross chain messaging
The xRenzoBridge contract fails to implement error handling in its Connext xReceive callback, leading to permanently stranded funds. When a cross-chain deposit triggers a revert in the L1 RestakeManager—due to TVL limits, contract pauses, or exchange rate slippage—the entire transaction fails. This lack of resilience allows attackers to use flash loans to artificially exhaust TVL capacity, intentionally causing bridging transactions to fail and trapping liquidity in the cross-chain messaging system.
Renzo: Withdrawals and Claims are meant to be pausable, but it is not possible in practice
Renzo's WithdrawQueue contract inherited OpenZeppelin's PausableUpgradeable and exposes an admin-gated pause()/unpause(), but did not apply the whenNotPaused modifier to withdraw() and claim(). As a result, once an emergency pause is triggered, users can still create new withdrawal requests and claim pending assets, defeating the intended circuit-breaker. This undermines the protocol's ability to freeze withdrawals during emergencies or maintenance, exposing funds to risk at exactly the moment the pause was meant to protect them. The finding affects the withdrawal queue's core user entry points.
All reports in this group
- Renzo: Pending withdrawals prevent safe removal of collateral assetsLogic error$0
- Renzo: Potential arbitrage opportunity in the `xRenzoDeposit` L2 contractFront-running / MEV$0
- Renzo: Fixed hearbeat used for price validation is too stale for some tokensOracle manipulation$0
- Renzo: DOS of `completeQueuedWithdrawal` when ERC20 buffer is filledLogic error$0
- Renzo: `L1::xRenzoBridge` and `L2::xRenzoBridge` uses the `block.timestamp` as dependency, which can cause issuesLogic error$0
- Renzo: ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`Reentrancy$0
- Renzo: Withdrawals can fail due to deposits reverting in `completeQueuedWithdrawal()`Logic error$0
- Renzo: Incorrect calculation of queued withdrawals can deflate TVL and increase ezETH mint rateOracle manipulation$0
- Renzo: The amount of `xezETH` in circulation will not represent the amount of `ezETH` tokens 1:1Oracle manipulation$0
- Renzo: stETH/ETH feed being used opens up to 2 way `deposit<->withdrawal` arbitrageOracle manipulation$0
- Renzo: Deposits will always revert if the amount being deposited is less than the `bufferToFill` valueReentrancy$0
- Renzo: Withdrawals can be locked forever if recipient is a contractLogic error$0
- Renzo: Withdrawals of rebasing tokens can lead to insolvency and unfair distribution of protocol reservesOracle manipulation$0
- Renzo: Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swapsReentrancy$0