rocketpool: the Rocket Pool contracts and the test suite that guards them

Eight ETH plus deposits to make one validator

The core idea of Rocket Pool is a pooling arrangement that splits the capital requirement of Ethereum staking in two. A solo validator needs 32 ETH. A node operator joining Rocket Pool stakes 8 ETH instead, and the protocol pairs that 8 ETH with the ETH deposited by rETH holders to assemble a full validator. The node operator then receives consensus rewards in ETH plus a commission from the rETH side. The economics are why the project calls itself a decentralised alternative to the staking services offered by centralised exchanges: the operator earns more than the same stake would earn solo, and the staker keeps exposure to the rest of the protocol rather than trusting an operator. Node operation is permissionless, with no approval step described for joining the pool.

rETH keeps the staker's ETH liquid

On the depositor side the minimum is 0.01 ETH, deposited into the protocol's smart contracts, and the receipt is rETH. That token is not a claim ticket that needs managing: it accrues staking rewards automatically over time, and it can be traded, used in DeFi, or redeemed for ETH plus rewards. That redeemability is the difference the project draws between its design and plain solo staking, where the staked ETH is locked for the duration of the withdrawal queue. rETH moves that problem from a lock to a price, which is the trade a user is making. The stated advantages list that follows adds prevention of breaking changes and reduced dependence on complex test environments to the benefit of not needing large data fixtures.

Running the test suite locally

The repository ships a runnable test suite, and the documented path is short. Clone it, install the JavaScript dependencies and run the tests:

$ npm install
$ npm test

The repository layout tells you what is being tested. `contracts/` holds the Solidity sources, `scripts/` holds deployment and helper scripts, `test/` holds the Mocha test files, and `images/` holds the project assets. Three Hardhat configuration files sit at the top level, `hardhat.config.js`, `hardhat-common.config.js` and `hardhat-deploy.config.js`, with `remapping.json` sitting alongside them, and `.mocharc.json` configures the test runner. Since the project is described as covering Ethereum 2.0 proof of stake infrastructure for the beacon chain, the deployment scripts are the entry point for a local instance rather than a package published to a registry.

What each npm script actually exercises

The `scripts` block in package.json is where the real test matrix shows, and the variants are more informative than the default run:

"test": "hardhat test --bail",
"test-deploy": "hardhat test --config hardhat-deploy.config.js --bail",
"test-gas": "REPORT_GAS=1 hardhat test --config hardhat-deploy.config.js --bail",

`--bail` means a suite stops at the first failure, which keeps a broken branch from running thousands of lines of follow-on assertions. `test-deploy` swaps in the deploy configuration, so it exercises the deployment path rather than the default network setup, and `test-gas` sets `REPORT_GAS=1` to turn on gas reporting through `hardhat-gas-reporter`. Two further scripts widen the net. `coverage` runs with `SOLIDITY_COVERAGE=true hardhat coverage`, and `slither` runs the static analyser with `node_modules` and `old` filtered out and the Solidity naming conformance check excluded. One inconsistency is worth noticing: `test-fork` points at `hardhat-fork.config.js`, and that filename is not among the listed top-level repository entries.

This repository is the contracts, not the node

The clearest thing to understand before reading the code is what this repository is not. It is the protocol's smart contracts, not the client that talks to the beacon chain, and it is not a deployment target for a live network in the shape it ships here. The README describes the protocol from the user's side, points readers to rocketpool.net for anything beyond that, and then gives the clone-and-test instructions for seeing the contracts in action. The package metadata reflects a Solidity and Hardhat project rather than a library: the runtime dependency list holds only `hardhat-ignore-warnings`, while the heavy lifting sits in devDependencies including `hardhat` at 2.22.12, `ethers` 6.13.3, `mocha` 10, `solidity-coverage` and two OpenZeppelin lines, the `3.4.0` release and a `4.9.2` release aliased under the `@openzeppelin4/contracts` name.

Version drift between the package and the releases

Two version numbers in this repository do not line up, and that is a fact worth carrying into any audit. The tagged releases are v1.4, named Saturn, on 2026-02-11, v1.3.1, named Houston Hotfix 1, on 2025-03-27, and v1.3.0, named Houston, on 2024-06-04. The `package.json` file, meanwhile, declares version 3.0.0 and describes the package as a next generation decentralised Ethereum 2.0 proof of stake protocol. Those are different numbering schemes for different things, so the package version should not be read as a protocol release number, and a diff against a tagged release will show more movement than the tag name suggests. The last push was on 2026-10-14, so the contract code moves more often than the release tags do.

Licence and what a contribution inherits

The code is distributed under GPL-3.0, which is a different choice from the permissive licences most Ethereum tooling uses, and it deserves attention before you build on top of it. Without giving legal advice, the practical points are that a copyleft licence attaches obligations to distributing modified versions of the covered code, and that the repository ships a `LICENSE` file at the top level alongside the `scripts/` and `test/` directories. The project also maintains a Discord community for issues, ideas and research, which is where questions about the protocol itself belong. For auditors and integrators, the licence plus the version drift described above are the two things to settle early, before effort goes into work that has to be redone against a different tag.

Editorial conclusion

Adopt this repository if you are auditing, integrating with or forking the Rocket Pool protocol, because it is where the deposit and node operator mechanics actually live and the test suite gives you a way to exercise them. Do not treat it as a way to run a node or as end-user documentation, since the page it ships covers only the contracts, the test commands and the protocol summary. Verify first that your Solidity and Hardhat toolchain matches the pinned versions in package.json, and that `npm test` passes on your machine before you change anything under `contracts/`.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. rocket-pool/rocketpool on GitHub