User Stories for RPIP-83: Increase Megapool Bond Requirements¶

RPIP-83 raises the per-validator megapool bond to 6 ETH (base_bond_array = [6, 12], reduced_bond = 6) and uses megapool rewards to replenish underbonded validators until their nodeBond returns to the bond curve. The goal is to accelerate megapool adoption while retaining node operators, rather than risking their permanent removal from the protocol.

The change is motivated by several concerns:

Insufficient rETH demand. Current market conditions don't support operators switching to 4 ETH megapool validators, leaving a large share of the protocol in minipools.
Tokenomics. Minipools don't contribute to voter_share and weigh negatively on RPL tokenomics.
Governance flexibility. UARS (RPIP-46) doesn't apply to minipools, restricting commission adjustments.
RPIP-71 risk. Prioritising minipools for liquidity exits, combined with limited rETH demand, could permanently remove many operators.
Network resilience. A larger, distributed node operator set is strategically valuable.

Upstream status

RPIP-83 is a Draft and is "not recommended for general use or implementation as it is likely to change." These stories track the current draft and will move with it.

Bond Lifecycle Diagram¶

flowchart TD
    Create[Operator creates megapool validator] --> Req["Required user_deposit = min(base_bond_array step or reduced_bond, bond curve per RPIP-42)"]
    Req --> Bonded{"nodeBond >= bond requirement?"}

    Bonded -- "Yes (on the bond curve)" --> Normal[Rewards distributed normally]
    Bonded -- "No (underbonded, e.g. legacy 4 ETH)" --> Replenish["Distributed rewards first top up nodeBond toward requirement"]
    Replenish --> ToRETH["ETH associated with the top-up is sent to rETH"]
    ToRETH --> Bonded

    Bonded -. "Operator may accelerate" .-> TopUp["Operator calls topUpBond to match current bond curve"]
    TopUp --> Bonded

Actors¶

Node Operator: Creates megapool validators at the increased bond, may voluntarily topUpBond to the current curve, and has rewards applied to replenish an underbonded validator.
pDAO: Governs base_bond_array and reduced_bond, and may consider underbonded megapool exit criteria for liquidity management.
rETH Holders: Receive the ETH associated with reward-funded bond replenishment, improving rETH backing.

Protocol Parameters¶

Modified parameters¶

Parameter	Old Value	New Value	Description
`base_bond_array`	(per RPIP-42)	`[6, 12]`	Per-validator bond steps for the first validators in a megapool.
`reduced_bond`	(per RPIP-42)	`6` ETH	Bond required for validators beyond the `base_bond_array`, subject to the bond curve.

Epic 1: Increased Bond Requirements¶

1.1: Create a Validator at the Increased Bond¶

As a Node Operator,
I want to create a megapool validator with the required bond determined by base_bond_array and reduced_bond,
So that new validators meet the higher 6 ETH bond requirement.

Acceptance Criteria:
- base_bond_array is [6, 12] and reduced_bond is 6 ETH.
- When creating a validator with i validators already in the megapool and 0 < i < base_bond_array.length, the required user_deposit is the minimum of (base_bond_array[i] - base_bond_array[i-1]) or the bond curve per RPIP-42.
- When i >= base_bond_array.length, the required user_deposit is the minimum of reduced_bond or the bond curve per RPIP-42.

Epic 2: Bond Top-Up¶

2.1: Top Up Bond to the Current Curve¶

As a Node Operator,
I want to call topUpBond to increase my nodeBond to match the current bond curve,
So that I can return an underbonded validator to the bond curve immediately rather than waiting on rewards.

Acceptance Criteria:
- A topUpBond method allows the node operator to increase nodeBond up to the current bond curve requirement.
- nodeBond cannot be increased beyond the current bond requirement.
- Emits an event.

Epic 3: Reward-Funded Bond Replenishment¶

3.1: Replenish Bond from Rewards¶

As the protocol,
I want to apply distributed megapool rewards to an underbonded validator's nodeBond before any further distribution,
So that validators are steadily brought back onto the bond curve and rETH backing is strengthened.

Acceptance Criteria:
- For a megapool whose nodeBond is below the bond requirement, distributed rewards are first used to increase nodeBond up to the requirement.
- The ETH associated with that increase is sent to rETH.
- Once nodeBond reaches the bond requirement (back on the bond curve), rewards distribute normally.

Epic 4: Governance¶

4.1: Tune Bond Parameters¶

As the pDAO,
I want to update base_bond_array and reduced_bond via on-chain governance,
So that bond requirements can be tuned as rETH demand and market conditions change.

Acceptance Criteria:
- base_bond_array and reduced_bond can only be updated by pDAO proposal.
- The update emits an event.

Epic 5: Monitoring & Tooling¶

5.1: Underbonded Status Visibility¶

As a Rocket Pool Node Operator,
I want to see, per megapool, my current nodeBond versus the bond requirement and the progress of reward-funded replenishment,
So that I can decide whether to topUpBond or let rewards replenish the bond over time.

Acceptance Criteria:
- The dashboard surfaces nodeBond, the bond requirement, and the underbonded shortfall per megapool.

Questions¶

The specification defines the required user_deposit for 0 < i < base_bond_array.length and for i >= base_bond_array.length, but does not state the i = 0 (first validator) case explicitly — is it simply base_bond_array[0] (6 ETH)?
Reward-funded replenishment of a 4 ETH validator to 6 ETH is estimated at "somewhere between 11 and 13 years" at ~3.7125% APR — is reward replenishment intended as the primary path, or is topUpBond the expected route for operators who want to stay on the curve?
Should there be underbonded megapool exit criteria for liquidity management (interaction with RPIP-71), and where would that be specified?
How does an underbonded validator interact with UARS (RPIP-46) commission while rewards are being redirected to bond replenishment?
Does reward-funded replenishment interact with megapool debt/deficit accounting (RPIP-44) when both apply to the same megapool?