rocketpool.net
Summary
Rocket Pool is a decentralized Ethereum liquid staking protocol with roughly $900M TVL and ~1,500 node operators, live since November 2021. It has not suffered a confirmed on-chain exploit that cost rETH holders principal, and it carries an unusually deep audit history (18 engagements) plus a $500K Immunefi bounty. On-chain reality diverges from documentation in important ways: 11 core contracts—including the rETH token and Saturn One megapool manager—remain unverified on Etherscan, the protocol guardian is a single EOA rather than the documented multisig, and the Security Council has only one on-chain member. The rETH exchange rate depends entirely on a 10-member Oracle DAO with no Chainlink fallback, atop unavoidable Ethereum Beacon Chain risk. Overall risk is moderate at 4.8/10, with dependency risk (6.2) and governance/tokenomics (5.5 each) as the main drags.
Trust Assumptions
Users must trust that Ethereum consensus and the Beacon Chain deposit contract remain sound, since all ~$900M of staked ETH flows through them with no protocol fallback. They must trust that at least six of ten oDAO members will submit honest balance and price updates on schedule—collusion or prolonged outage would stall rETH mint/burn pricing. They must trust that deployed bytecode matches audited source despite 11 unverified contracts, including the rETH token users actually hold. They must trust that the EOA protocol guardian (0x0ccf…fa21e) and single-member Security Council will not abuse fast-path powers, and that Saturn One megapool code deployed in February 2026 matches the final audited commit despite post-audit change uncertainty flagged by Bailsec.
What Could Go Wrong
A coalition of six or more oDAO members could manipulate or censor exchange-rate submissions, distorting rETH mint/burn pricing within the 2%-per-day cap and creating arbitrage windows against DEX prices. Compromise of the guardian EOA or Security Council sole member could enable rapid guardianship transfer or emergency setting changes without the 7-day pDAO timelock that protects ordinary governance. A bug in the newly deployed Saturn One megapool stack—where distribute() sends ETH via external calls without reentrancy guards and the manager contract is unverified—could drain protocol funds before the $500K bounty or community response contains it. L2 rETH on Arbitrum and Optimism depends on canonical rollup bridge security, and the Arbitrum price oracle has no staleness heartbeat, so stale rates could persist in DeFi integrations if cross-chain submissions stop.
Recommendation
Rocket Pool is reasonable for moderate ETH liquid-staking exposure given ~4.5 years of operation without rETH holder losses, strong audit discipline, and functional on-chain pDAO governance—but size positions with awareness that verification and governance centralization gaps are material, not cosmetic. Prefer mainnet rETH over L2 bridged positions where oracle and bridge dependencies add layers. Monitor oDAO member health and exchange-rate update cadence, Etherscan verification of the 11 outstanding contracts (especially rETH and RocketMegapoolManager), guardian and Security Council composition, and any post-Saturn One governance or audit disclosures. Reduce or pause new deposits if bytecode verification lags further upgrades, if oDAO consensus stalls, or if Bailsec-style deployment uncertainty resurfaces without independent confirmation that mainnet matches audited code.
Key Findings (30)
Analysis Sections
Rocket Pool operates a functional dual-DAO model (RPL-weighted pDAO + 10-member oDAO) with on-chain governance enabled since Houston (block 21226405) and bootstrap mode disabled. However, the RocketStorage guardian is an EOA deployer address—not the documented 8/14 oDAO multisig—and the Security Council has only one on-chain member, concentrating fast-response powers. oDAO retains significant oracle and upgrade influence; there is no protocol-wide pause switch.
Findings (8)
On-chain getGuardian() on RocketStorage (0x1d8f8f00cfa6758d7bE78336684788Fb0ee0Fa46) returns 0x0ccf14983364a7735d369879603930afe10df21e, classified as the RocketStorage Deployer. Verified as an EOA (no contract code, getOwners/getThreshold revert empty). This contradicts RPIP-14's documented 8/14 oDAO multisig guardian. While bootstrap mode is disabled (limiting unilateral setting changes), the guardian retains setGuardian()/confirmGuardian() power to transfer guardianship in a two-step process without timelock.
RocketDAOSecurity (0x84ae6d61df5c6ba7196b5c76bcb112b8a689ad37) reports getMemberCount()=1 with sole member 0x6c565af34f15de064b56afedf7b0f59c15bb20fe. Houston design intended a multisig-style council for rapid incident response with member quorum. A single-member council effectively grants one address fast-path authority to propose and execute security setting changes, undermining the intended distributed emergency control.
The Oracle DAO (10 members, min 3, internal quorum 5.1 RPL-weighted) exclusively submits network balances and RPL prices via onlyTrustedNode gating. Oracle updates commit at 51% node consensus (network.consensus.threshold). oDAO members can scrub minipools during the scrub period (withdrawal-credentials defense) and apply penalties. RPIP-14 notes oDAO already had equivalent technical capabilities to the guardian via contract upgrades. Compromise of a 51% oDAO coalition could manipulate exchange-rate inputs affecting rETH minting/redemption pricing.
Protocol DAO proposals require 15% RPL quorum, face 20% veto quorum, 7-day vote delay, 28-day execution window, and 30-minute challenge period with 100 RPL proposal bond. These provide meaningful delays for standard governance. However, guardian transfers and Security Council fast-path proposals are not subject to equivalent timelocks, creating an asymmetric trust model.
RocketArbitrumPriceOracle on Arbitrum (0x7EcCBbd05830EdF593d30005B8F69E965AF4D59f) has a single owner() set to RocketArbitrumPriceMessenger (0x312FcFB03eC9B1Ea38CB7BFCd26ee7bC3b505aB1). L2 rate updates only accept calls from the L1-to-L2 aliased messenger address. While submitRate() on the messenger is permissionless (anyone can pay gas), setOwner() is a simple single-owner pattern with no timelock. The messenger is not registered in RocketStorage (registry returns 0x0), indicating weaker integration with mainnet governance.
Most network contracts are upgradeable by registering new implementations in RocketStorage (hub-and-spoke). pDAO settings changes route through rocketDAOProtocolProposals with onlyDAOProtocolProposal gating. RocketVault is explicitly documented as non-upgradeable. Megapool/minipool delegates use upgradeDelegate() with 120-day deprecation buffer. Historical upgrades (Saturn One v1.4) were governance-approved. oDAO historically held parallel upgrade authority per RPIP-14, creating overlapping upgrade paths.
No global pause/kill switch exists across core staking contracts. Emergency controls are domain-specific: oDAO challenge/decide for offline members, minipool scrubbing, Security Council fast setting changes, and per-contract pause on Arbitrum retryable ticket creation. RocketDepositPool and rETH minting cannot be halted by a single emergency flag.
RocketDAONodeTrusted (oDAO core), RocketDAOProtocolVerifier, and RocketSwapRouter source are not verified on Etherscan in this pipeline snapshot, limiting independent audit of membership proposal and Merkle-vote challenge logic. Related interfaces are available in verified sibling contracts (RocketDAONodeTrustedActions, RocketDAOProtocolProposals).
Governance Checklist
pDAO vs oDAO Power Separation
| Domain | pDAO (Protocol DAO) | oDAO (Oracle DAO) | Overlap Risk |
|---|---|---|---|
| Protocol economic settings | RPL-weighted proposals (fees, bonds, inflation split) | No direct control | Low |
| Treasury & RPL spending | pDAO treasury proposals | No direct control | Low |
| Security Council membership | Invite/kick/replace members | No direct control | Low |
| Oracle price/balance updates | Can adjust consensus threshold via settings | Exclusive submitters; 51% consensus commits | Medium |
| Minipool scrubbing & penalties | Sets scrub/penalty parameters | Executes scrub/penalty actions | Medium |
| Contract upgrades | Settings-only via proposals | Historical upgrade authority per RPIP-14 | Medium-High |
| Guardian role | Nominally superseded by pDAO | Held 8/14 multisig per RPIP-14 (not current on-chain state) | High |