Cross-Contract Reentrancy and Composability Attacks

Rocket Pool's critical contracts, including the minipool delegate and RPL staking logic, were hardened by strictly enforcing the checks-effects-interactions pattern. All state changes—such as updating a node operator's RPL stake or marking a minipool as finalized—now occur before any external call to transfer ETH or tokens. This prevents an attacker's receiving contract from re-entering and operating on stale state. Auditors and integrators should verify this pattern in any new Rocket Pool delegate upgrades or third-party contracts that call distributeBalance or stakeRPL.

Following the composability exploits, OpenZeppelin's ReentrancyGuard modifier was systematically applied to all external and public functions in Rocket Pool's network contracts that perform ETH or RPL transfers. This includes RocketTokenRETH.burn, RocketMinipool.distributeBalance, and RocketNodeStaking.stakeRPL. The non-reentrant lock provides a protocol-level safety net even if a future upgrade introduces a subtle interaction path. Integrators building on Rocket Pool should assume that any state-modifying function they call is guarded and design their own callback logic to handle a revert without breaking atomicity.

To eliminate reentrancy risks during reward distribution, Rocket Pool migrated from a push model—where the protocol sends ETH to node operators—to a pull model. Operators must now explicitly call withdrawRPL or withdrawETH to claim their rewards. This architectural shift means the protocol never initiates an external call during a state-modifying operation, breaking the composability attack chain entirely. Wallets and staking-as-a-service providers integrating Rocket Pool must implement the claim-and-withdraw user flow and monitor for unclaimed balances as a liveness signal.

Rocket Pool commissioned formal verification of the minipool lifecycle state machine to mathematically prove the absence of reentrancy paths between states like Staking, Withdrawable, and Dissolved. The verification models the exact call graph from stake through distributeBalanceAndFinalize, ensuring no external call can trigger an unexpected state transition. Protocol developers and security auditors should request the formal verification artifacts when reviewing any proposed changes to the minipool delegate or when building cross-contract integrations that depend on minipool state.

Chainscore Labs recommends deploying real-time invariant monitoring across Rocket Pool's core contracts to detect composability attacks before they are exploited. Key invariants include: the sum of all minipool ETH balances must equal the deposit pool balance plus rETH total supply; a node operator's effective RPL stake must never exceed their actual staked balance; and the rETH exchange rate must only increase. Any violation of these invariants signals a potential reentrancy or composability exploit in progress, allowing the pDAO or emergency multisig to pause the protocol. Risk teams should integrate these monitors into their security operations.

For DeFi protocols integrating rETH as collateral or building on Rocket Pool's minipool contracts, the standard remediation is a dedicated integration test suite that includes reentrancy fuzzing. Using tools like Foundry's invariant tests or Echidna, integrators should model a malicious receiver contract that attempts to re-enter every external function during deposit, burn, stake, and withdraw operations. Chainscore Labs can perform a structured integration review that maps all external call points in your protocol against Rocket Pool's guarded functions, identifying composability risks before deployment.

Use the Rocket Pool contract repository as the primary source for tracing cross-contract call paths across minipools, rETH accounting, RPL staking, network balances, and upgradeable storage contracts. Security teams should review the active branch, deployed contract tags, modifiers, external callbacks, and any changes to withdrawal, deposit, reward-claim, or finalization flows. For reentrancy analysis, build a call graph that includes indirect protocol calls rather than checking each contract in isolation.

The official documentation is the baseline for understanding intended protocol behavior before classifying a composability issue as a bug, integration risk, or expected permissioned flow. Review the docs for minipool lifecycle assumptions, rETH mechanics, node operator responsibilities, and protocol contract roles. Integrators should compare documented invariants against on-chain behavior, especially where external DeFi positions, token transfers, oracle reads, or node-operator actions can occur in the same transaction path.

RPIPs are useful for identifying whether a mitigation, parameter change, or architecture adjustment was specified through Rocket Pool governance rather than introduced only as an implementation patch. When reviewing a reentrancy or composability-risk fix, check whether related changes affect minipool creation, rETH minting and burning, RPL collateral requirements, oracle duties, or pDAO-controlled parameters. Teams should verify the current proposal status against the repository and governance venues before relying on a proposed mitigation.

The DAO forum is a practical source for incident discussion, mitigation rationale, operator impact, and community review around protocol changes. For cross-contract reentrancy analysis, search for threads discussing contract upgrades, emergency responses, audit findings, oracle behavior, minipool edge cases, and integration concerns raised by node operators or protocol contributors. Risk teams should treat forum posts as governance and implementation context, then confirm final outcomes against deployed contracts and canonical proposal records.

The Immunefi bounty page is the appropriate starting point for responsible disclosure scope, severity framing, and in-scope assets when a cross-contract reentrancy issue may affect Rocket Pool funds, rETH accounting, RPL staking, or minipool operations. Security researchers should use the bounty scope before testing against live systems, and integration teams should monitor public disclosure outcomes for issues that may change their own risk assumptions around composability with rETH or Rocket Pool contracts.

Solidity’s official security guidance provides the baseline control model for reentrancy review: checks-effects-interactions, avoiding unsafe external calls, and understanding how callbacks can re-enter before state is finalized. Apply the guidance at the Rocket Pool system level, not only per contract. A minipool, token, oracle, or staking contract may appear locally safe while still enabling an unsafe cross-contract sequence when composed with DeFi routers, vaults, liquid staking integrations, or custom operator tooling.