Renzo

Renzo audit details

• Total Prize Pool: $112,500 in USDC
  • HM awards: $63,500 in USDC
  • QA awards: $3,000 in USDC
  • Judge awards: $11,300 in USDC
  • Validator awards: $5,200 USDC
  • Scout awards: $500 in USDC
  • Mitigation Review: $29,000 in USDC
• Join C4 Discord to register
• Submit findings using the C4 form
• Read our guidelines for more details
• Starts April 30, 2024 20:00 UTC
• Ends May 8, 2024 20:00 UTC

Automated Findings / Publicly Known Issues

The 4naly3er report can be found here.

Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.

Known Risks

• Incorrect configuration being set or admin privileged functions causing invalid configuration
• Administrative centralization (protocol is becoming decentralized over time)
• Node Operator deposit front runs

Overview

Renzo is a Liquid Restaking Token (LRT) and Strategy Manager for EigenLayer. It is the interface to the EigenLayer ecosystem securing Actively Validated Services (AVSs) and offering a higher yield than ETH staking.

The protocol abstracts all complexity from the end-user and enables easy collaboration between users and EigenLayer node operators.

Contracts

contracts
├── Bridge
│   ├── Connext - "Connext Interface Contract and Libraries used in the protocol"
│   ├── L1
│   │   ├── IxRenzoBridge.sol - "Interface of xRenzoBridge used by caller contract"
│   │   ├── xRenzoBridge.sol - "L1 Bridge Contract which sends price feed to supported L2s and receiving ETH from different L2s"
│   │   └── xRenzoBridgeStorage.sol - "Storage contract for xRenzoBridge"
│   ├── L2
│   │   ├── Oracle
│   │   │   ├── IRenzoOracleL2.sol - "Interface of RenzoOracle on L2"
│   │   │   ├── RenzoOracleL2.sol - "Wrapper Oracle contract to fetch ezETH price on L2 from configured price feeds"
│   │   │   └── RenzoOracleL2Storage.sol - "Storage contract for RenzoOracleL2"
│   │   ├── PriceFeed
│   │   │   ├── CCIPReceiver.sol - "CCIP Receiver contract on L2 to receive price feed from L1"
│   │   │   └── ConnextReceiver.sol - "Connext Receiver contract on L2 to receive price feed from L1"
│   │   ├── IxRenzoDeposit.sol - "Interface of xRenzoDeposit user by caller contract"
│   │   ├── xRenzoDeposit.sol - "User facing deposit contract on supported L2s"
│   │   └── xRenzoDepositStorage.sol - "Storage contract for xRenzoDeposit"
│   └── xERC20
│       ├── contracts
│       │   ├── XERC20.sol - "XERC20 token contract"
│       │   ├── XERC20Factory.sol - "XERC20Factory contract responsible to deploy XERC20 and XERC20Lockbox"
│       │   ├── XERC20Lockbox.sol - "XERC20 Lockbox contract"
│       │   └── optimism
│       │       ├── OptimismMintableXERC20.sol - "extended version of XERC20 supported by native optimistic bridge"
│       │       └── OptimismMintableXERC20Factory.sol - "Storage contract for OptimismMintableXERC20"
│       └── interfaces
│           ├── IOptimismMintableERC20.sol - "Interface of OptimismMintableXERC20"
│           ├── IXERC20.sol - "Interface of XERC20"
│           ├── IXERC20Factory.sol - "Interface of IXERC20Factory"
│           └── IXERC20Lockbox.sol - "Interface of IXERC20Lockbox"
├── Delegation
│   ├── IOperatorDelegator.sol - "Interface of OperatorDelegator"
│   ├── OperatorDelegator.sol - "Oprator delegator contract responsible for interacting with EigenLayer"
│   └── OperatorDelegatorStorage.sol - "Storage contract for OperatorDelegator"
├── Deposits
│   ├── DepositQueue.sol - "Deposit Queue contract responsible to deposit native ETH to Beacon chain and fill the withdraw buffer"
│   ├── DepositQueueStorage.sol - "Storage contract for DepositQueue"
│   └── IDepositQueue.sol - "Interface of DepositQueue"
├── EigenLayer - "EigenLayer Interfaces and Libraries used"
├── Errors
│   └── Errors.sol - "Contains all the custom errors"
├── Oracle
│   ├── Binance - "The contracts hard codes the decimals to 18 decimals and returns the conversion rate of 1 wBETH to ETH underlying the token in the wBETH protocol" 
│   │   ├── IStakedTokenV2.sol
│   │   ├── WBETHShim.sol
│   │   └── WBETHShimStorage.sol
│   ├── Mantle - "The contracts hard codes the decimals to 18 decimals and returns the conversion rate of 1 mETH to ETH underlying the token in the mETH protocol"
│   │   ├── IMethStaking.sol
│   │   ├── METHShim.sol
│   │   └── METHShimStorage.sol
│   ├── IRenzoOracle.sol - "Interface of Renzo Oracle"
│   ├── RenzoOracle.sol - "Responsible for getting mint/burn amounts and collateral token value lookup from configured price feeds on L1"
│   └── RenzoOracleStorage.sol - "Storage contract for RenzoOracle on L1"
├── Permissions
│   ├── IRoleManager.sol - "Interface of RoleManager used by caller contracts"
│   ├── RoleManager.sol - "Access Control contract of the protocol"
│   └── RoleManagerStorage.sol - "Storage Contract of RoleManager"
├── RateProvider
│   ├── BalancerRateProvider.sol - "Contract to Provide Mint Rate of LRT(ezETH)"
│   ├── BalancerRateProviderStorage.sol - "Storage contract of BalancerRateProvider"
│   └── IRateProvider.sol - "Interface of BalancerRateProvider used by caller contracts"
├── RestakeManager.sol  - "Users interact with this contract for deposits"
├── RestakeManagerStorage.sol - "Storage contract for RestakeManager"
├── IRestakeManager.sol - "Interface for RestakeManager"
├── Rewards
│   ├── RewardHandler.sol - "Handle the rewards coming from Eigen Layer"
│   └── RewardHandlerStorage.sol - "Storage contract for RewardHandler Contract"
├── Withdraw
│   ├── IWithdrawQueue.sol - "Interface of WithdrawQueue"
│   ├── WithdrawQueue.sol - "Handles ezETH withdraw requests of users"
│   └── WithdrawQueueStorage.sol - "Storage contract for WithdrawQueue"
└── token
    ├── EzEthToken.sol - "Renzo restaked Token"
    ├── EzEthTokenStorage.sol - "Storage contract for EzEthToken"
    └── IEzEthToken.sol - "Interface of EzEthToken"

Links

• Previous Audits - Halborn.
• Renzo Website
• Documentation
• Twitter
• Discord
• Mirror
• Telegram

Deposit Collateral Flow

To deposit collateral, you must choose which ERC20 collateral token you want to deposit and how much. You can deposit multiple times with different tokens.

To deposit collateral:

1. Approve the RestakeManager to spend your token
2. Call deposit() on the RestakeManager with the token address and amount of collateral you want to deposit

You can do this by interacting with the contracts directly on Etherscan. Ensure you go to the address, then Contract -> Write as Proxy tabs since all these contracts are proxies.

Note that all amounts are in wei so you will need to convert to base units (1 ETH = 10^18 wei). You can use a tool like https://eth-converter.com/ to do this.

When you call deposit(), it will:

• Move your collateral into the RestakeManager
• Deposit your collateral into EigenLayer
• Mint ezETH to your address corresponding to the amount of collateral you deposited

Note: all the assets are priced in ETH denominations. i.e stETH/ETH, wbETH/ETH, ezETH/ETH.

Withdraw Flow

The withdraw flow is a 2 step process. First you will need to sumbit your withdraw request, then wait the timeout period (7 days on mainnet), and finally complete the withdraw.

When you submit your withdraw request, it will:

• Move your ezETH into the RestakeManager that will be burned
• Calculate how much of the staked tokens you are withdrawing for your collateral value
• Start a withdraw on EigenLayer

When you complete your withdraw, it will:

• Complete the withdraw on EigenLayer
• Burn your ezETH
• Send the collateral back to your wallet

To submit a withdraw request:

• Calculate how much ezETH you want to burn in base units (e.g. 5000000000000000 for 0.005 ezETH)
• Call approve() on the ezETH contract to approve the RestakeManager to move your ezETH
• Call startWithdraw() on the RestakeManager with the amount of ezETH you want to burn and which collateral token you would like to get back

When this transaction is complete you will see:

• Your ezETH has been moved into the RestakeManager
• On Etherscan you will see events from EigenLayer that show a bunch of details
  • Look at transaction -> Logs on Etherscan
  • The 2 logs you will want to use in the next step are:
    • ShareWithdrawalQueued
    • WithdrawalQueued

After the delay has passed, you can complete your withdraw:

• Call completeWithdraw() on the RestakeManager
  • The parameters can be found in the event logs from the previous step
  • Note that some of the parameters require putting into an array using the "[" and "]" characters
  • Note that withdrawalStartBlock is the block number from the tx in the previous step
  • middlewareTimesIndex is 0

Note on withdrawing

Note that the protocol must have at least the collateral you are requesting to be delegated to a single Operator in order to withdraw that amount. For example if the protocol has 100 stETH delegated to Operator 1 and 50 stETH delegated to Operator 2, the maximum stETH you can request to withdraw is 100. If you request 110 stETH, the tx will fail. Instead you can perform 2 withdrawals, one for 100 stETH and one for 10 stETH.

---

Scope

See scope.txt

Files in scope

Files out of scope

See out_of_scope.txt

Scoping Q & A

General questions

External integrations (e.g., Uniswap) behavior in scope:

EIP compliance checklist

N/A

Additional context

Main invariants

• ezETH should be minted or redeemed based on current supply and TVL.
• Any rewards earned by the protocol should be redeposited (minus a protocol fee).
• Non-privileged accounts should not be able to modify configuration.

Attack ideas (where to focus for bugs)

Integrity of TVL calculations (ezETH Pricing) - a user should not be able to manipulate the protocol to mint or withdraw at invalid prices

All trusted roles in the protocol

Describe any novel or unique curve logic or mathematical models implemented in the contracts:

N/A

Compiling

git clone --recurse-submodules https://github.com/code-423n4/2024-04-renzo.git
cd 2024-04-renzo
npm install
npm run compile

Other Features

Deposit Caps

The protocol has the ability to set a cap on deposits. A value in RestakeManager maxDepositTVL can be set by the restake admin. If this value is set, the contract will revert on any deposits if that would push it above the max TVL.

ezETH Transfer Restrictions

When the protocol launches, it is intended to not have ezETH be transferrable. A user will deposit and get ezETH minted to their account, but they will not be able to transfer it out of their account until the protocol is ready to allow it. If the withdrawal flow is enabled, they can still withdraw from the protocol (token can be minted and burned by RestakeManager, even if transfers are restricted).

Native ETH Deposit

The protocol allows users to deposit native ETH to be staked by a validator.

• The user will deposit ETH into the RestakeManager
• The RestakeManager will deposit the ETH into the DepositQueue
• The user will be minted ezETH proportional to their contribution to the total TVL

Once the deposit queue reaches 32 ETH

• A validator will be commissioned outside the protocol with the withdrawal credentials set to a specific EigenPod and the Execution Rewards address set to the DepositQueue
• The OperatorDelegator associated with the EigenPod will call stake() on the EigenPod Manager and send the 32 ETH to the deposit contract
• Once the deposit is confirmed, the OD will call verifyWithdrawalCredentials() on the EigenPod and shares will be allocated to the OD

Protocol Fees

Fees accumulated in the protocol should be sent to the DepositQueue contract. The configuration in the DepositQueue contract will determine whether fees are configured or not. This includes the destination where all fees are sent and the percentage in basis points. 100 basis points = 1%.

Native ETH earned from outside EigenLayer (such as Execution Layer Rewards or MEV) will be sent to the DepositQueue receive() function. The protocol will then forward a configured fee percentage to an external address.

ERC20 rewards earned in EigenLayer will be sent to the DepositQueue address. The protocol can then sweep the ERC20 fee percentage to the target address and deposit the remaining ERC20 tokens into the protocol through an Operator Delegator.

Miscellaneous

Employees of Renzo and employees' family members are ineligible to participate in this audit.