User Stories for RPIP-82: Enable pDAO Spending of ETH and ERC-20¶

RPIP-82 lets the pDAO spend treasury assets — ETH or ERC-20 tokens — through on-chain voting. It builds on RPIP-72's pdao_share (which directs ETH staking rewards to the pDAO) and extends the pDAO voting mechanisms from RPIP-33, so the treasury can be disbursed without an off-chain multisig.

Two spend types are introduced:

One-time spend. A single payment of a fixed amount of ETH or an ERC-20 token to a recipient.
Recurring payments. A payment contract that accrues a fixed amount per period over a number of periods; the recipient claims accrued amounts at any time.

Upstream status

RPIP-82 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.

Spend Lifecycle Diagram¶

flowchart TD
    Vote[pDAO votes on a spend proposal] --> Kind{Spend type?}

    Kind -- One-time --> OneTime["One-time spend: invoice ID, recipient, ETH/ERC-20, token address, amount"]
    OneTime --> Send["Protocol sends amount from treasury to recipient"]

    Kind -- Recurring --> Action{Create or Update?}
    Action -- Create --> Contract["Establish payment contract: period length, start date, number of periods, amount per period"]
    Action -- Update --> Modify["Modify existing payment contract"]
    Contract --> Claim
    Modify --> Claim
    Claim["Recipient claims at any time"] --> Calc["Protocol calculates all unpaid periods to date and transfers from treasury"]

Actors¶

pDAO: Votes to authorise one-time spends and to create or update recurring payment contracts.
Recipient: Receives a one-time payment, or claims accrued amounts from a recurring payment contract.
Protocol / Treasury: Holds the ETH and ERC-20 assets and executes the transfers on execution or claim.

Proposal Data¶

One-time spend¶

Field	Description
Invoice ID	Arbitrary identifier for bookkeeping.
Recipient Address	Ethereum address receiving the payment.
Type	ETH or ERC-20.
Token Address	Required only for ERC-20 transfers.
Amount	Payment quantity.

Recurring payment contract¶

Field	Description
Contract Name	Bookkeeping identifier.
Recipient Address	Payment beneficiary.
Period Length	Duration of a period, in seconds.
Start Date	Unix timestamp at which payments commence.
Number of Periods	Total number of payment cycles.
Type	ETH or ERC-20.
Token Address	Required only for ERC-20 payments.
Amount Per Period	Quantity paid per cycle.

Epic 1: One-Time Spend¶

1.1: Propose and Execute a One-Time Spend¶

As the pDAO,
I want to propose a one-time payment of ETH or an ERC-20 token to a recipient,
So that the treasury can settle one-off costs through on-chain governance.

Acceptance Criteria:
- A one-time spend proposal specifies an invoice ID, recipient address, type (ETH or ERC-20), token address (for ERC-20 only), and amount.
- On successful execution, the protocol sends the provided amount of ETH or token from its treasury to the recipient.
- The proposal can only be executed via the pDAO voting process.

Epic 2: Recurring Payments¶

2.1: Create a Recurring Payment Contract¶

As the pDAO,
I want to create a recurring payment contract that pays a fixed amount per period over a number of periods,
So that ongoing costs (e.g. grants or salaries) can be funded without a separate vote each period.

Acceptance Criteria:
- A create proposal specifies the contract name, recipient address, period length (seconds), start date (Unix timestamp), number of periods, type (ETH or ERC-20), token address (for ERC-20 only), and amount per period.
- On approval, the payment contract is established and begins accruing from its start date.

2.2: Update a Recurring Payment Contract¶

As the pDAO,
I want to update an existing recurring payment contract,
So that the terms of an ongoing payment can be changed as circumstances evolve.

Acceptance Criteria:
- An update proposal modifies an existing recurring payment contract.
- The update can only be executed via the pDAO voting process.

2.3: Claim Recurring Payments¶

As a Recipient,
I want to claim my recurring payment at any time,
So that I receive everything accrued so far without waiting for a fixed payout schedule.

Acceptance Criteria:
- The recipient may execute a claim at any time.
- The protocol calculates all unpaid payments up to that point and transfers the required amount from its treasury.

Epic 3: Monitoring & Tooling¶

3.1: Treasury Spend Visibility¶

As the Rocket Pool community,
I want to see active recurring payment contracts and executed one-time spends from the treasury,
So that pDAO treasury outflows are transparent and auditable.

Acceptance Criteria:
- A feature surfaces one-time spends, active recurring payment contracts, and amounts claimed/remaining per contract.

Questions¶

What happens if the treasury holds insufficient ETH or tokens at execution or claim time — does the transfer revert, partially pay, or queue?
Can a recurring payment contract be cancelled or paused, or is only create/update supported? How is an over-funded or unwanted contract wound down?
What are the semantics of an update — does it apply only to future periods, and can it change the recipient, amount, or number of periods retroactively?
Is the claim permissionless (callable by anyone on the recipient's behalf), or restricted to the recipient address?
Is there any allowlist or guardrail on which ERC-20 tokens or recipients are eligible, or are they fully arbitrary per proposal?
How does treasury funding interact with RPIP-72's pdao_share — is spending bounded by realised pdao_share inflows?