Rocket Pool is a decentralized liquid-staking protocol on Ethereum, governed by RPL holders and a set of trusted oracle nodes. It issues rETH, a reward-bearing token that appreciates against ETH as staking rewards accrue. Where the largest staking protocols run a curated, DAO-approved set of professional node operators, Rocket Pool's defining choice is a permissionless operator set: anyone can run a node by posting an ETH bond and RPL collateral, with no allowlist. That decision shapes both the product and the governance, which Rocket Pool splits across two distinct DAOs. Sources throughout link to Rocket Pool's own documentation and its RPIP improvement-proposal register.

rETH and the permissionless node-operator model

Solo staking on Ethereum requires 32 ETH and continuous uptime. Rocket Pool lets ordinary users deposit any amount of ETH for rETH — a token whose exchange rate rises as the underlying validators earn rewards — while a separate class of participants, node operators, actually run the validators. An operator spins up a minipool, posting a personal ETH bond (Saturn I lowers the bond toward 4 ETH via megapools) plus RPL collateral that is slashed if they underperform. Because operators are permissionless, Rocket Pool's node set is far more numerous and geographically diffuse than a curated one — the Lido centralization critique is the exact problem Rocket Pool designs against. The tradeoff is that permissionless operators can't be trusted with protocol admin, which is precisely why governance is split in two. See the protocol docs for the full minipool and rETH mechanics.

Two DAOs: the pDAO and the oDAO

Rocket Pool separates who sets policy from who reports trusted facts:

• Protocol DAO (pDAO) — the RPL-holder governance body that shapes protocol direction: parameters, treasury/inflation, upgrades. Voting power is a function of effective RPL stake held by node operators (see the next section).
• Oracle DAO (oDAO) — a small set of well-regarded staking-ecosystem members running special nodes that supply data the smart contracts cannot compute for themselves (validator balances, the rETH exchange rate, reward Merkle trees) and execute mandated administrative steps. Its remit, membership, and slashing rules are fixed by RPIP-24, the oDAO Charter.

This is a deliberate answer to a hard problem: a permissionless validator set needs some trusted party to attest to off-chain reality, but that trusted party should not also control policy. The oDAO is intentionally narrow — an oracle and executor, not a legislature — while the pDAO holds the political power. Rocket Pool has openly worked to reduce the residual centralization in how the two interact.

On-chain pDAO governance: square-root weight and layered votes

The Houston upgrade moved the pDAO fully on-chain (RPIP-33), replacing pure Snapshot signalling with binding contract execution. Two features stand out:

• Square-root voting weight. A node operator's pDAO power is scored on the square root of their effective RPL stake — so the larger the stake, the less voting power per RPL. The explicit goal, per Rocket Pool's design notes, is to temper large operators and let blocs of smaller operators actually move a vote. This is a rare on-chain anti-whale weight, distinct from the linear token-weighted voting most protocols use.
• Snapshot-and-override voting. Eligibility, delegation state, and power are frozen at a snapshot when a proposal is created. There are two voting periods: first delegates (and direct voters) cast votes, then members who had delegated their power get a window to override their delegate's choice. A veto quorum lets the community instantly defeat a proposal — and the proposer forfeits their bond — to deter spam and proposals that skipped off-chain signalling.

Proposal creation and challenges are bonded throughout, so putting a bad proposal on-chain has a real cost. The full rules live in RPIP-4 and the governance guides.

The security council and upgrade guardrails

A fully on-chain, permissionless governance layer needs a circuit breaker. Rocket Pool elects a security council whose members can pause the protocol quickly if something goes wrong and can make certain parameter changes without waiting out the normal delay. The council is itself controlled by the pDAO, which sets the required quorum and can replace members. RPIP-60 formalizes these protocol upgrade guardrails: upgrades authorized by a pDAO vote pass through a mandatory delay during which the security council can veto, and are then executed on-chain by the oDAO. The current Saturn I upgrade — halving the operator bond, introducing megapools, express/standard deposit queues, and adjustable commission — was authorized by pDAO vote and scheduled for oDAO execution after the mandated delay, a live demonstration of the whole two-DAO-plus-council pipeline.

How Caper approaches this

Rocket Pool's answer to plutocracy is a concave function of capital: square-root the RPL stake so whales get less power per token, add a trusted oracle set for facts, and elect a council to catch emergencies. It is clever, and it needs no participation history — power is still bought with RPL, just at a diminishing rate. Caper makes a different bet. A caper's vote weight is (t·v)/(V·T) — held tokens t times the member's earned soulbound votes v, over supply — computed by the contract's compute_vote_weight helper and reused verbatim by exit() to size a member's treasury share. The vote token is DIVISIBILITY_NONE, minted one per vote, and non-transferable (its depositor role is locked to the DAO itself), so the participation factor cannot be bought, rented, or delegated away. This is not a bagless system — t is a genuine multiplier, so stake still counts — but the decisive factor a well-funded buyer cannot acquire is the earned soulbound record, not a curve applied to their capital. And there is no separate oracle DAO or elected council to trust: typed PAYOUT/INVEST/VOTE proposals execute directly against a protocol-controlled treasury vault. Honestly, that means a caper forgoes exactly the professional operator layer and emergency council Rocket Pool provides; the wager is that earned, un-buyable weight plus a minimal on-chain surface beats a trusted set you have to keep honest.

References

• Rocket Pool — protocol site and rETH overview.
• Rocket Pool documentation — minipools, node operation, and Houston governance guides.
• RPIP-33 — implementation of an on-chain pDAO; RPIP-4 — community resolutions and voting.
• RPIP-24 — the Oracle DAO Charter; RPIP-60 — protocol upgrade guardrails.
• Saturn I — the current upgrade (megapools, 4 ETH bond, queues).
• Rocket Pool governance forum — live pDAO discussion and proposals.