User Stories for RPIP-80: Exit Requests, Triggering Exits, and Minipool Penalties¶

RPIP-80 is the common plumbing beneath the other protocol-triggered exit RPIPs. Where RPIP-44 (forced exit on debt), RPIP-71 (withdrawal liquidity) and RPIP-73 (underperformance) each decide which validators should leave, RPIP-80 defines how an exit is requested, signalled, enforced, and accounted for — uniformly across both legacy minipools and megapools.

The flow it standardises:

A validator is requested to exit, which exposes an "exit requested" signal to the node operator and tracks the expected returning capital.
The operator is given a cooperative exit phase to exit voluntarily.
After that window, for delegates that support EIP-7002 — megapools and any 7002-capable minipool delegate — the exit can be triggered permissionlessly; for legacy minipool delegates that cannot self-trigger, anyone can prove non-exit and apply a penalty.

Exit Request Lifecycle Diagram¶

flowchart TD
    Source[["RPIP-44 / 71 / 73 decide a validator should exit"]] --> Request[Validator requested to exit]
    Request --> Signal["Expose 'exit requested' signal + requested_exit_eth += user capital"]
    Signal --> Coop{"cooperative_exit_phase (72h) elapsed?"}

    Coop -- "No — operator may exit voluntarily" --> Voluntary[Operator exits validator themselves]
    Coop -- "Yes" --> Capable{Delegate supports EIP-7002?}

    Capable -- "Yes (megapool or 7002-capable minipool delegate)" --> Trigger[Anyone triggers EL exit via EIP-7002]
    Capable -- "No (legacy minipool delegate)" --> Prove["Anyone proves exit_epoch == FAR_FUTURE_EPOCH"]
    Prove --> Penalty["Penalty += did_not_exit_penalty (0.1 ETH); repeat after did_not_exit_cooldown"]

    Voluntary --> Settle[notifyFinalBalance / minipool distributed]
    Trigger --> Settle
    Settle --> Reduce["requested_exit_eth -= user capital"]

Actors¶

Exit Requester: The mechanism that calls into RPIP-80 to request an exit — RPIP-44 (debt), RPIP-71 (withdrawal liquidity), or RPIP-73 (underperformance). RPIP-80 itself does not decide who should exit, only how.
Node Operator / Smart Node: Sees the "exit requested" signal and is expected to exit the validator voluntarily within the cooperative exit phase.
Enforcer (any user): After the cooperative phase, may permissionlessly trigger an EIP-7002 exit, or prove non-exit of a legacy minipool to apply the penalty.
pDAO: Tunes the cooperative phase, penalty amount, and cooldown via on-chain governance.

Protocol Parameters¶

Parameter	Type	Initial Value	Constraint	Description
`cooperative_exit_phase`	`Hours`	`72`	—	Window after an exit request during which the operator is expected to exit voluntarily before enforcement is permitted.
`did_not_exit_penalty`	`ETH`	`0.1`	—	Penalty applied to a legacy minipool proven not to have exited after the cooperative phase.
`did_not_exit_cooldown`	`Days`	`28`	`> 7`	Minimum time before the same validator can be re-requested and penalised again.

Epic 1: Requesting an Exit¶

1.1: Request a Validator to Exit¶

As an Exit Requester (RPIP-44 / 71 / 73),
I want to request a specific validator to exit through RPIP-80's common mechanism,
So that all exit sources share one consistent request, signalling, and accounting path.

Acceptance Criteria:
- When a validator is requested to exit, an "exit requested" signal is exposed that is observable to the node operator's smart node.
- requested_exit_eth is increased by the validator's expected user capital, defined as 32 ETH - validator bond.
- Re-requesting a validator that is already requested to exit does not reset its timing windows or double-count requested_exit_eth.
- After did_not_exit_cooldown has elapsed, the validator may receive a new exit request.

1.2: Observe an Exit Request¶

As a Node Operator / Smart Node,
I want to see that one of my validators has been requested to exit,
So that I can exit it voluntarily before any enforcement or penalty applies.

Acceptance Criteria:
- The "exit requested" event is observable per validator to the operator.

Epic 2: Cooperative Exit¶

2.1: Voluntary Exit Within the Cooperative Phase¶

As a Node Operator / Smart Node,
I want to exit my requested validator myself during the cooperative_exit_phase,
So that I avoid permissionless enforcement and any non-exit penalty.

Acceptance Criteria:
- The smart node voluntarily exits on seeing the "exit requested" event.

Epic 3: Triggering Exits Permissionlessly¶

3.1: Trigger an EL Exit of a Megapool Validator¶

As an Enforcer,
I want to trigger an execution-layer exit of a requested megapool validator once the cooperative phase has passed,
So that megapool exits do not depend on a cooperative or responsive operator.

Acceptance Criteria:
- For a megapool validator, anyone may trigger an exit once the validator has been requested to exit for at least cooperative_exit_phase.
- The exit is triggered via the EIP-7002 execution-layer mechanism.
- No permissionless trigger or penalty is allowed against the validator until cooperative_exit_phase has elapsed since the request.

3.2: Trigger an EL Exit of a 7002-Capable Minipool Validator¶

As an Enforcer,
I want to trigger an execution-layer exit of a requested minipool validator whose delegate supports EIP-7002, once the cooperative phase has passed,
So that 7002-capable minipool exits do not depend on a cooperative or responsive operator and avoid the non-exit penalty path.

Acceptance Criteria:
- For a minipool delegate that supports EL-triggered exits, anyone may trigger an exit once the validator has been requested to exit for at least cooperative_exit_phase.
- The exit is triggered via the EIP-7002 execution-layer mechanism.
- No permissionless trigger or penalty is allowed against the validator until cooperative_exit_phase has elapsed since the request.

Epic 4: Minipool Non-Exit Penalties¶

4.1: Prove a Legacy Minipool Has Not Exited¶

As an Enforcer,
I want to prove that a requested legacy minipool validator has not exited after the cooperative phase,
So that an operator who ignores an exit request is penalised even though their delegate cannot be force-exited.

Acceptance Criteria:
- Applies to delegates that do not support EL-triggered exits, after cooperative_exit_phase has elapsed.
- Anyone may submit a beacon state proof demonstrating the validator has not exited (exit_epoch == FAR_FUTURE_EPOCH).
- On successful verification, the minipool's penalty increases by did_not_exit_penalty (0.1 ETH) and requested_exit_eth is decreased by the validator's expected user capital.

4.2: Repeat Penalty After Cooldown¶

As the protocol,
I want to require a fresh exit request and a did_not_exit_cooldown gap before penalising the same validator again,
So that a single ignored request cannot be used to stack penalties unfairly.

Acceptance Criteria:
- A further penalty requires the validator to be re-requested to exit.
- Re-requesting is only possible after did_not_exit_cooldown (28 days) has elapsed.

Epic 5: Exit Accounting¶

5.1: Track Requested and Voluntary Exit ETH¶

As the protocol,
I want to maintain requested_exit_eth and voluntary_exit_eth accurately across the exit lifecycle,
So that other RPIPs (e.g. RPIP-71's shortfall calculation) can rely on a correct view of expected returning capital.

Acceptance Criteria:
- requested_exit_eth tracks ETH expected to exit under this specification; voluntary_exit_eth tracks ETH from megapool validators exiting voluntarily.
- For megapools, voluntary_exit_eth is incremented when notifyExit is called for a validator that was not requested to exit.
- notifyFinalBalance decrements voluntary_exit_eth or requested_exit_eth as appropriate.
- After a minipool is distributed or a megapool validator finalises, requested_exit_ethis reduced by the expected user capital.

Epic 6: Governance¶

6.1: Tune Exit Enforcement Parameters¶

As the pDAO,
I want to update cooperative_exit_phase, did_not_exit_penalty, and did_not_exit_cooldown via on-chain governance,
So that enforcement timing and penalties can be tuned as the protocol matures.

Acceptance Criteria:
- Each parameter can only be updated by pDAO proposal.
- did_not_exit_cooldown cannot be set to 7 days or below.

Epic 7: Monitoring & Tooling¶

7.1: Operator Exit-Request Alerting¶

As a Rocket Pool Node Operator,
I want to be alerted on my dashboard when one of my validators is requested to exit and how long remains in the cooperative phase,
So that I can exit voluntarily before enforcement or a penalty applies.

Acceptance Criteria:
- The Grafana dashboard surfaces the "exit requested" signal per validator and the time remaining in cooperative_exit_phase.

7.2: Community Exit Monitoring¶

As the Rocket Pool community,
I want to see the current requested_exit_eth and validators awaiting exit,
So that we can observe enforcement and the protocol's pending exit pipeline.

Acceptance Criteria:
- A website feature displays requested_exit_eth, validators under request, and any applied non-exit penalties.