CS-BOLD-020 Informational 7.18: rETH Address Might Change

[bingen]

The rocket pool protocol stores addresses in a storage contract. The protocol's codebase indicates that addresses should not be used directly but be retrieved on-chain. However, the collateral token address is set once in the AddressesRegistry and cannot be updated.

In practice, it seems unlikely that the rETH token's address will change due to other integrations.
Additionally, it is unspecified how integrators should properly handle such a migration.

[bingen]

This is the response from RocketPool team:

---

When would rETH contract addresses change?
While technically possible, the address RocketStorage maintains shouldn’t change ever.

What would actually happen in case on an address change?
Without wide-ranging changes to the overall protocol (deposit pool contract, minipool contracts where upgrades are opt-in on a per operator basis), rocket pool would break pretty badly. The deposit pool would keep minting the existing ERC20 and ignore the new address. Existing minipools that generate staking rewards would continue to send these rewards to the old token. New minipools would send to the new token (that nobody is able to mint).

Would balances automatically migrate to the new token, or would holders need to excute a migration function?
Without further upgrades, nothing like that would happen.

Are there any upgrade implementations of the token we should know of?
No

Why have a technical reason to change the address then?
The oDAO controls protocol upgrades. They would have to vote for an upgrade that changes the rETH address. I can’t think of a scenario where doing so makes sense for the protocol, because I would assume it would really break things.
Overall, I’d say that rETH comes with the assumption that the rocket pool oDAO isn’t compromised, independent of the risk of rETH address changing. rETH redemptions rely on correct price updates from the oDAO. A malicious upgrade to minipools could still redirect funds belonging to rETH elsewhere. If you are assuming that oDAO is operating correctly, I think you can also assume that rETH address isn’t changed.

In addition to this, the protocol is designed with the assumption that the rETH address does not change. For example:

• the upgrade function blocks direct changing of rETH: https://github.com/rocket-pool/rocketpool/blob/fb53ec9ee9546faea70799ac8903005300eec9d6/contracts/contract/dao/node/RocketDAONodeTrustedUpgrade.sol#L44
• the deposit pool stores the rETH address in the constructor because it is “non-upgradebale” and to “save gas”: https://github.com/rocket-pool/rocketpool/blob/fb53ec9ee9546faea70799ac8903005300eec9d6/contracts/contract/deposit/RocketDepositPool.sol#L56
• minipools also store the rETH address when they are created and never update: https://github.com/rocket-pool/rocketpool/blob/fb53ec9ee9546faea70799ac8903005300eec9d6/contracts/contract/minipool/RocketMinipoolDelegate.sol#L137