Companies and projects covered
Prepared by the Token Metrics Editorial Team using the official sources listed below. Product terms, eligibility, limits, fees, and protocol rules can change; confirm current details before acting.
Choose pooled staking or node operation first
A pooled staker deposits through the protocol and receives rETH. A node operator registers a node, runs Ethereum clients and Rocket Pool software, supplies the required current bond, and performs validator duties. The second path is an operating role, not a higher-effort version of clicking stake.
If you cannot maintain a machine, monitor clients, protect validator material, and respond to network upgrades, do not choose the node path. If you do not understand token and smart-contract risk, do not assume the pooled path is simple merely because it has fewer steps.
rETH pooled-staking workflow
rETH represents a share of pooled staking value under Rocket Pool’s design. Its value relative to ETH is intended to reflect protocol rewards and losses rather than rebasing the wallet balance. Verify the token contract and exchange rate through official protocol surfaces.
Liquidity can come from protocol capacity or a secondary market. A market price can diverge. Before depositing, test how you would exit, what network costs apply, and whether sufficient protocol or market liquidity exists for the intended amount.
Node registration and command-line operations
Rocket Pool’s Smartnode command-line interface is the operator’s primary tool for registering, creating validators, checking status, claiming rewards, and managing the node. Operators also run Ethereum execution and consensus clients. That means software updates and disk, network, and time health are ongoing duties.
Use dedicated hardware or an approved server design. Back up recovery material using the official process. Keep withdrawal and fee-recipient addresses under controlled custody. Practice an update and recovery before placing significant value at risk.
Bond, pooled ETH, and operator economics
Current Rocket Pool documentation describes a megapool design in which an operator bond is combined with ETH from pooled stakers to form validators. Exact bond and reward parameters can change through upgrades. Read the current responsibility and upgrade pages rather than relying on an older minipool figure.
Operator rewards can include validator rewards, commission related to borrowed ETH, and RPL-related incentives under current rules. Costs include hardware, bandwidth, maintenance time, taxes, and the risk that poor validator performance reduces the operator share. No net return is promised.
Uptime, penalties, and slashing controls
A node must attest and may receive block duties. Offline periods reduce rewards and can create penalties. Slashing is more severe and can result from conflicting validator actions, including running the same validator keys in two places.
Do not create an active-active failover with duplicated validator keys. Monitor client sync, peers, disk, time, attestations, and fee recipient. Define who responds to alerts and how a safe restart avoids double signing.
Exit, withdrawals, and RPL timing
A pooled holder exits through available protocol mechanics or a market trade. A node operator has a separate validator-exit and funds-distribution workflow. Rocket Pool documentation also describes timing rules for unstaking node RPL under current protocol design.
Write the exit runbook before starting. It should distinguish validator exit, bond return, reward claim, rETH sale or redemption, RPL unstaking, and tax records. Test commands in a non-production environment when possible.
Governance, contracts, and alternatives
Rocket Pool uses protocol contracts and governance. Node operators interact with more of that control surface than pooled holders. Monitor upgrade notices and contract migrations; an old guide can describe a retired minipool design.
Alternatives include solo staking for direct validator control, Lido for a different liquid-token and operator model, a staking service, or no staking. A user with enough ETH and strong operations may prefer solo staking. A smaller holder may compare rETH with stETH based on token mechanics and exit path.
Decision scenario
Scenario: a technically skilled holder is deciding between rETH and running a node. If the goal is simple liquid exposure and the user accepts protocol risk, start with a small rETH test and an exit check. If the goal is operating validators, budget for hardware and response time, verify current bond rules, and complete a full key, update, monitoring, and exit rehearsal.
Decision checklist
Which path are you taking: rETH holder or node operator? For rETH, did you verify the contract, exchange-rate model, and exit liquidity? For a node, are current bond rules confirmed, clients monitored, keys protected from double signing, and updates assigned? Does the runbook cover validator exit, reward distribution, RPL timing, and recovery from hardware failure?
Frequently asked questions
Are returns, execution, availability, or safety guaranteed? No. This profile describes documented workflows and decision checks, not a guarantee or rating.
Why are no fixed fees or limits quoted? Dynamic terms can vary by route, account, market, or protocol state. Use the official pages and a current test.
What should happen before production use? Verify identity and permissions, run normal and failure cases, document support ownership, and keep an exit or migration plan.
Plain-language test plan
Choose one Rocket Pool path first. A pooled user and a node operator do different work. For rETH, use a small test wallet. Get the token address from current docs. Check the network. Read the rate model. Deposit a small amount. Confirm the token received. Test the planned exit. Check both protocol and market routes. Do not assume the prices match. For a node, read the current bond rule. Do not use an old minipool guide. List the needed hardware. Install both Ethereum clients. Check sync and disk space. Protect validator and wallet keys. Never run the same validator key twice. Add alerts for missed work. Assign a person to each alert. Practice a client update. Practice a safe restart. Read the current reward flow. Record every claim. Write the exit steps before launch. Include validator exit and bond return. Include any RPL wait. Keep a hardware recovery plan. Follow upgrade notices. Compare the node path with solo staking. Compare rETH with stETH. Choose only the work you can keep doing.
Release record
Make two Rocket Pool plans. The rETH plan tracks token, rate, and exit. The node plan tracks machine, keys, clients, bond, and duty. Do not mix the plans. A pooled holder has no server alert. A node owner has many. Test each node alert. Name who will wake up. Name who can update clients. Name who can stop work. Name who can start again. Keep a spare part list. Keep a safe key backup. Never test backup keys on a live second node. Review the plan at each upgrade. Retire old steps. A current plan is part of the staking cost.
Continue your research
Explore Token Metrics research
