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
- 17
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 17 closed, publicly disclosed Renzo reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Front-running / MEV, Logic error, Oracle manipulation, Reentrancy, 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
- Front-running / MEV findings disclosed against Renzo
- Logic error findings disclosed against Renzo
- Oracle manipulation findings disclosed against Renzo
- Reentrancy 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: Potential arbitrage opportunity in the `xRenzoDeposit` L2 contract
In Renzo's cross-chain architecture, `xRenzoBridge` on Layer 1 fetches the `ezETH` rate via `BalancerRateProvider` and transmits it to Layer 2 deposit contracts (`xRenzoDeposit`) via cross-chain messaging. Due to latency between L1 message initiation and L2 state updates, an observer monitoring L1 mempool calls to `sendPrice()` can front-run the L2 update. An attacker can mint `xezETH` on L2 at the stale rate and subsequently liquidate or swap the position once `updatePrice()` updates `lastPrice`, extracting economic value from the price lag.
Renzo: Pending withdrawals prevent safe removal of collateral assets
A logic defect in Renzo's collateral management permits administrators to remove a collateral token while pending user withdrawals for that token are still held in the WithdrawQueue contract. When a token is removed from the supported collateral list, its remaining balance in the withdrawal queue is omitted from total TVL calculations. Because total ezETH supply accounting is not updated in tandem, excluding these assets creates a disparity between recorded total TVL and actual token supply, artificially inflating ezETH minting and redemption exchange rates.
Renzo: Fixed hearbeat used for price validation is too stale for some tokens
Renzo's L2 oracle contracts enforce a hardcoded 24-hour freshness check (MAX_TIME_WINDOW) when fetching prices from Chainlink aggregators. On secondary chains like Arbitrum, certain price feeds operate with significantly shorter heartbeat periods, such as 6 hours for ezETH/ETH. Because the staleness window does not account for target chain feed configurations, the protocol accepts stale pricing data for up to 18 hours past its designated update threshold, potentially skewing mint rate calculations during volatile market conditions.
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: ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`
The OperatorDelegator contract in the Renzo protocol implements a nonReentrant modifier on its receive function, which inadvertently blocks essential callbacks from EigenLayer. When attempting to finalize ETH withdrawals from EigenLayer, the process requires an inbound transfer of ETH, which triggers the receive function. Because the function is protected, the withdrawal process reverts, rendering ETH assets permanently stuck in the EigenLayer protocol and unredeemable by the Renzo system.
Renzo: stETH/ETH feed being used opens up to 2 way `deposit<->withdrawal` arbitrage
Renzo's ezETH restaking protocol uses a secondary market Chainlink feed (stETH/ETH) to value stETH deposits rather than an underlying exchange rate feed. Because secondary market prices can fluctuate or depeg from pure ETH, discrepancies arise in how much ezETH is minted for stETH versus ETH deposits. Attackers can exploit these price discrepancies by timing stETH or ETH deposits during depeg events to execute profitable deposit and withdrawal arbitrage cycles.
All reports in this group
- Renzo: Withdrawals of rebasing tokens can lead to insolvency and unfair distribution of protocol reservesOracle manipulation$0
- Renzo: Withdrawals can be locked forever if recipient is a contractLogic error$0
- Renzo: Incorrect exchange rate provided to Balancer poolsOracle manipulation$0
- Renzo: `calculateTVL` may run out of gas for modest number of operators and tokens breaking deposits, withdrawals, and tradesOracle manipulation$0
- Renzo: The amount of `xezETH` in circulation will not represent the amount of `ezETH` tokens 1:1Oracle manipulation$0
- Renzo: Deposits will always revert if the amount being deposited is less than the `bufferToFill` valueReentrancy$0
- Renzo: Not handling the failure of cross chain messagingReentrancy$0
- Renzo: Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swapsReentrancy$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: Lack of slippage and deadline during withdraw and depositOracle manipulation$0