User Stories for RPIP-79: Faster Withdrawal Credentials Check¶

RPIP-79 speeds up megapool validator creation by replacing the mandatory beacon state proof with an optimistic challenge. Today, the second (31 ETH) deposit can only happen after the validator's first (1 ETH) deposit clears the beacon pending_deposits queue and a state proof is submitted — a sequential dependency on the entry queue. RPIP-79 lets the 31 ETH stake proceed without a state proof, and instead opens a short window in which anyone can prove a withdrawal-credential exploit. In the common case — an honest operator with correct credentials — no proof is ever needed.

This matters because RPIP-73 is expected to drive significant validator churn, so minimising the time new validators spend waiting in the beacon queue becomes a priority.

Prestake Challenge Lifecycle Diagram¶

flowchart TD
    Prestake[Operator prestakes 1 ETH] --> Window{"prestake_challenge_period (12h)"}

    Window -- "Fraud proof submitted" --> Verify["Proof: matching pubkey + incorrect withdrawal_credentials"]
    Verify --> Slash["rETH share of 31 ETH returned to deposit pool"]
    Slash --> Reward["Node operator share awarded to challenger (direct or credit)"]

    Window -- "No proof within window" --> Stake["Anyone calls stake_without_state_proof"]
    Stake --> Staked([Remaining 31 ETH staked, validator active])

Actors¶

Node Operator: Prestakes the validator (1 ETH) and, in the honest case, has it staked after the challenge window with no proof required.
Challenger (any user): During the challenge window, may submit a beacon state proof of incorrect withdrawal credentials and claim the node operator's share as a reward.
pDAO: Sets the challenge period and the reduced_bond guardrail via on-chain governance.

Protocol Parameters¶

New parameters¶

Parameter	Type	Initial Value	Guardrail	Description
`prestake_challenge_period`	`Hours`	`12`	`>= 12`	Window after `prestake` during which anyone may submit a withdrawal-credential fraud proof before the validator can be staked.

Modified guardrails¶

Parameter	Old Guardrail	New Guardrail	Reason
`reduced_bond`	`>= 1` and `<= 4`	`>= 1.1` and `<= 4`	Ensures at least a 0.1 ETH node operator share remains in the 31 ETH stake, guaranteeing a minimum challenger reward.

Epic 1: Optimistic Staking¶

1.1: Stake Without a State Proof¶

As a Node Operator with correct withdrawal credentials,
I want to have my validator's remaining 31 ETH staked without generating or submitting a beacon state proof,
So that the common path is cheaper and faster and my validator is not delayed by the beacon chain entry queue.

Acceptance Criteria:
- A stake_without_state_proof method performs the remaining 31 ETH stake without requiring a validator state proof.
- No proof is required from the node operator for staking to proceed.
- Once prestake_challenge_period has elapsed without a valid proof, anyone may call stake_without_state_proof to complete the stake.
- The method cannot be called before the challenge period has elapsed.
- Staking no longer depends on the validator's first deposit clearing the pending_deposits queue.

Epic 2: Fraud Proof Challenge¶

2.1: Challenge via the Validators Set¶

As a Challenger,
I want to submit a beacon state proof that the validators set contains a validator with a matching pubkey and incorrect withdrawal_credentials,
So that a withdrawal-credential exploit on an already-registered validator is stopped before the protocol's 31 ETH is staked to it.

Acceptance Criteria:
- Between prestake and stake/stake_without_state_proof, anyone may submit a beacon state proof that validators contains a validator with a matching pubkey and incorrect withdrawal_credentials.
- Proof verification uses BLS12-381 signature verification via the EIP-2537 precompiles.
- A validator with a valid challenge is not staked.
- On a valid proof, the rETH share of the remaining 31 ETH is returned to the deposit pool.
- The node operator share of the remaining 31 ETH is awarded to the proof provider, either directly or as credit (in which case the full 31 ETH is sent to the deposit pool); the reduced_bond >= 1.1 guardrail ensures this share is at least 0.1 ETH.

2.2: Challenge via Pending Deposits¶

As a Challenger,
I want to submit a beacon state proof that pending_deposits contains a validator with a matching pubkey, incorrect withdrawal_credentials, and a valid signature,
So that a withdrawal-credential exploit can be proven before the validator's deposit has cleared the entry queue.

Acceptance Criteria:
- Between prestake and stake/stake_without_state_proof, anyone may submit a beacon state proof that pending_deposits contains a validator with a matching pubkey, incorrect withdrawal_credentials, and a valid signature.
- A challenge is rejected if the pending_deposits deposit it refers to has an invalid signature, preventing a 1 ETH griefing vector that would otherwise dissolve legitimate Rocket Pool validators.
- A validator with a valid challenge is not staked.
- On a valid proof, the rETH share of the remaining 31 ETH is returned to the deposit pool.
- The node operator share of the remaining 31 ETH is awarded to the proof provider, either directly or as credit (in which case the full 31 ETH is sent to the deposit pool); the reduced_bond >= 1.1 guardrail ensures this share is at least 0.1 ETH.

Epic 3: Governance¶

3.1: Update the Challenge Period¶

As the pDAO,
I want to update prestake_challenge_period via on-chain governance,
So that the safety/latency trade-off of the challenge window can be tuned over time.

Acceptance Criteria:
- prestake_challenge_period can only be updated by pDAO proposal.
- The update proposal executes when setting prestake_challenge_period to any value at or above the 12-hour guardrail, emitting an event.
- The update proposal reverts with a clear error when attempting to set prestake_challenge_period below 12 hours.

3.2: Update the Reduced Bond Guardrail¶

As the pDAO,
I want to update reduced_bond via on-chain governance, bounded to the >= 1.1 and <= 4 ETH guardrail,
So that the minimum bond — and therefore the minimum challenger reward of 0.1 ETH — can be tuned over time while staying within safe bounds.

Acceptance Criteria:
- reduced_bond can only be updated by pDAO proposal.
- The update proposal executes when setting reduced_bond to any value in [1.1, 4] ETH, emitting an event.
- The update proposal reverts with a clear error when attempting to set reduced_bond below 1.1 ETH or above 4 ETH, and a rejected update does not alter the current reduced_bond value.

Epic 4: Monitoring & Tooling¶

4.1: Challenge Window Visibility¶

As a Challenger or monitoring service,
I want to see which prestaked validators are within their challenge window,
So that withdrawal-credential exploits can be detected and proven before staking completes.

Acceptance Criteria:
- A feed surfaces prestaked validators awaiting stake and the time remaining in prestake_challenge_period.

4.2: Operator Staking Status¶

As a Rocket Pool Node Operator,
I want to see when my prestaked validators clear their challenge window and are staked,
So that I can confirm my validators are active without tracking the beacon queue manually.

Acceptance Criteria:
- The dashboard shows each validator's prestake/challenge/staked status.

Questions¶

The split between the rETH share and the node operator share of the 31 ETH is not numerically specified beyond the 0.1 ETH minimum reward — is the challenger reward always exactly the node bond, or capped/floored otherwise?
Who is expected to run challenge monitoring in practice — the oDAO, a public watcher service, or purely market-incentivised challengers? The 0.1 ETH reward may be thin relative to proof gas costs.
Is there any penalty to the node operator beyond losing their bond share, e.g. for a deliberate (vs accidental) wrong-credential attempt?
Does stake_without_state_proof coexist with the existing state-proof stake path, or fully replace it?
How does the 12-hour challenge window interact with RPIP-73 churn and RPIP-71 reentry tickets — does it add latency to redeployed capital?