Renzo requires legacy REZ stakers to claim their tokens before migrating into ezREZ

Legacy Staking and the Role of ezREZ

Legacy REZ staking held governance tokens in an older staking contract; ezREZ represents REZ committed to securing services through EigenLayer. The older arrangement was deprecated, and existing positions require manual release before their tokens can enter the new vault. A staking balance doesn't become ezREZ simply because the replacement product exists.

Operators use the restaked collateral to secure services accepting REZ. Each service determines which assets it accepts; permissionless token support doesn't make every token eligible everywhere. The liquid token represents participation in that arrangement. Its backing supports reward accrual, while REZ retains its governance role.

Although ezETH also represents a restaked position, it concerns different collateral. An ezETH balance can't release an old REZ stake or substitute for the REZ required by this migration.

The Legacy Cooldown and REZ Release

Cooldown Activation

The legacy staking interface provides an Activate Cooldown action for releasing the old position. It requires an Ethereum mainnet transaction from the staking address and enough ETH for gas. A signature request alone doesn't establish that activation succeeded; the successful transaction and resulting unstaking request identify the amount awaiting release. Opening the interface or reconnecting a wallet doesn't start this waiting period.

The Configured Waiting Period

The legacy cooldown was shortened from seven days to one hour for migration. The staking contract exposes its cooldown setting and allows its owner to change it. Claim eligibility therefore follows the active parameter and the recorded request, rather than an assumed permanent interval. Check the remaining wait for the particular request before attempting its claim.

The Claimable Request

The legacy contract records unstaking requests with amounts and timestamps. Once a request satisfies its cooldown, its REZ can be claimed. That claim releases the requested tokens; it doesn't deposit them into ezREZ. If several requests exist, their individual records distinguish the amount being claimed from other tokens still awaiting release.

Deposit Authorization and the Received Token

Permission to Spend REZ

The ezREZ deposit requires spendable REZ and the authorization the deposit contract needs to receive it. An ERC-20 allowance permits a particular spender to use a specified token amount. Approval changes that permission; it doesn't itself create a restaking position. Review the spender and permitted amount before confirming an authorization request. Token approval and deposit are distinct operations, although their presentation and transaction requirements depend on the supported interface. The displayed deposit amount is the intended REZ input. Wallet connection, an allowance, and a pending deposit each describe different states.

Deposit Completion

A successful deposit issues ezREZ representing the restaked REZ. The transaction receipt identifies whether execution succeeded, and the receiving address's token balance shows the issued holding. A submitted transaction hash alone doesn't prove a completed deposit. Compare the REZ input with the ezREZ received, keeping the two token units separate.

The receipt-token quantity reflects the vault's conversion calculation. Don't assume a permanent one-for-one token count merely because both names contain REZ.

Ethereum Mainnet and Transaction Costs

The documented legacy staking contract and ezREZ token are deployed on Ethereum mainnet. A token balance on another network doesn't establish a position in either contract. The connected address must control the old stake, and the deposit must use the asset the target vault accepts.

Ethereum contract interactions require ETH for gas. Cooldown activation, claiming, and depositing involve execution costs, with approvals potentially adding another charge. Gas usage and the network's fee conditions determine those costs. A large REZ balance doesn't replace the ETH needed to pay them, and the migration's shortened cooldown doesn't include transaction inclusion time.

View image file

The wallet's fee estimate concerns its particular transaction. It isn't a fixed protocol-wide migration price.

Reward Accrual and the REZ Exchange Rate

Reward-Bearing Token Accounting

ezREZ reflects auto-compounded rewards in its value relative to REZ. This accounting differs from a token balance increasing with every distribution. An unchanged ezREZ quantity can reflect accumulated rewards as its value relative to the underlying token changes.

Market Value and Service Payments

The exchange rate measures backing in REZ units, while market value also reflects the price of REZ. More underlying tokens don't establish a gain in a cash currency. Rewards depend on the services paying them and any additional allocations in force. A displayed annualized yield shouldn't be treated as the rate every migrated position will earn indefinitely.

Governance Across the Change in Holdings

Legacy staked REZ is automatically self-delegated for governance. ezREZ holdings are automatically self-delegated for Renzo governance. Liquid REZ held in a wallet requires delegation to the holder or another delegate to become eligible for voting. Cooldown activation removes the requested amount from the active legacy stake used to calculate voting power. A migration isn't itself a vote, and holding the new token doesn't cast votes automatically.

Restaking Exposure and Contract Dependencies

Restaked REZ provides economic security through operators and their participating services. Slashing exposure depends on the stake allocated to services with applicable slashing conditions. It shouldn't be assumed identical across every operator or service. Where a slash applies, it can reduce the underlying collateral available to the position.

EigenLayer withdrawals can remain slashable during their protocol withdrawal delay. Requesting an exit therefore doesn't automatically end exposure immediately. This underlying rule is separate from the shortened cooldown for releasing the legacy staking position. The vault and its deposit authorization also introduce contract dependencies beyond holding liquid REZ.

The Separate ezREZ Redemption Process

ezREZ redemption requires initiating a withdrawal and manually claiming REZ once the request becomes available. Its withdrawal cooldown is separate from the shortened legacy staking interval. The amount entering withdrawal stops accruing rewards when withdrawal begins. The withdrawal record's remaining wait and claim availability determine when its assets can be collected. Transferability of ezREZ doesn't make native redemption immediate, and initiating a request doesn't mean the REZ has already reached the wallet.

Holding REZ and Using Market Liquidity

Claiming the old stake leaves a choice between retaining liquid REZ and depositing it into ezREZ. Holding REZ preserves direct token exposure without adding this restaking position. A new deposit adds reward participation and the vault's redemption conditions. Migration into the replacement product makes sense only when those conditions fit the intended holding period and use of the tokens.

A secondary-market swap is a different way to exchange an existing ezREZ holding. An ezREZ/REZ pool on Uniswap V3 was established as an alternative to native withdrawal. Its execution depends on available liquidity and the trade's quoted output. Neither a historical pool allocation nor the vault's backing rate guarantees a particular swap result.

The legacy stake must still be released before its REZ can be used elsewhere. Trading liquid tokens doesn't claim a position held in the old staking contract.

Reward Policies After the Product Change

Additional ezREZ benefits can come from governance-directed allocations, whose terms can change independently of the migration mechanics. During the buyback program reviewed in February 2026, part of purchased REZ was distributed to ezREZ holders. That review also opened a decision on continuing the program or pausing it for reassessment.

Those distributions establish a historical benefit, not a permanent payment rate or entitlement for every later deposit. Revenue sharing depends on the allocation in force and its eligibility conditions. If an allocation ends, its past distributions don't establish an ongoing payment to a newly migrated stake.