Roadmap
RPP402 v1 is deliberately six primitives: Discovery, Quote, Commerce Session, Payment Intent, Settlement, Receipt. This page tracks what comes after: the one piece of v1 still being implemented, and the RFCs explicitly deferred out of v1 so the core stayed small enough to fully implement and audit.
Near-term: onchain settlement contracts
Not a deferred RFC -this is the one piece of v1 whose reference implementation is still being finished. Settlement (RPP402-005) is specified, and the off-chain facilitator settles the stablecoin (EIP-3009) path today. The onchain settlement contracts -@rpp402/contractsSettlement.sol
The path that matters is the tokenized-stock-denominated settlement locked in the Product Strategy: an agent settling against tokenized real-world-asset capital held in an Agentic Account, not just stablecoins. On Robinhood Chain the stock tokens are standard ERC-20, so the contract settles them via a payer-approved transferFrom, while USDG uses gasless EIP-3009 -both paths are implemented. This is the only scheduled item on the roadmap -everything below is not.
Deferred RFCs (RPP402-010+)
Everything below was explicitly named out of scope for v1. Each entry becomes its own numbered RFC when its time comes -none are speculatively designed here beyond the one paragraph needed to say why it's deferred and what it will need from v1 to build on.
None of these are scheduled. Order in this table is not priority order.
| RFC | Title | Defers because |
|---|---|---|
| RPP402-010 | Subscriptions | Needs a recurring-authorization primitive distinct from the single-use Payment Intent (RPP402-004); premature until real usage shows what recurrence patterns agents actually need. |
| RPP402-011 | Streaming | Needs a metered, sub-second settlement path different from RPP402-005's per-Session settlement; likely composes with MPP's "Session" (voucher) settlement model rather than reinventing it -an argument for sequencing this after Interoperability. |
| RPP402-012 | Escrow | Needs a hold-and-release state beyond RPP402-004/005's authorize-then-settle; matters most for Sessions spanning long-running work (e.g. paying for a multi-day compute job) that v1's Session expires_at isn't designed for. |
| RPP402-013 | Wallet Delegation | Generalizes RPP402-004's agentic_account_delegation beyond Robinhood Agentic Accounts to arbitrary third-party delegated signing (e.g. a fund manager's agent spending on behalf of multiple end-user wallets). |
| RPP402-014 | Marketplace | Ranked/curated service listing beyond the Registry Explorer's plain index -needs a reputation signal (RPP402-015) to rank on before it's meaningful. |
| RPP402-015 | Machine Reputation | Needs a corpus of real Settlements/Receipts to derive any signal from; not designable before v1 has production usage to observe. |
| RPP402-016 | Identity | v1 identifies an agent by wallet address only (see RPP402-000 Terminology). Richer identity (DIDs, attestations, KYC linkage) is real scope, but adding it to v1 would couple the payments protocol to an identity protocol before either is proven. |
| RPP402-017 | Notifications | Push/webhook-style status updates for long-running Sessions; v1 requires polling GET {endpoints.session}/{id} (see RPP402-003 Best Practices). |
| RPP402-018 | Invoices | Human-readable billing documents layered over Receipts (RPP402-006) for mixed agent/human accounting workflows -a presentation concern, not a settlement one, so it doesn't block v1. |
| RPP402-019 | Spend Limits | Cross-service, agent-side aggregate limits (as opposed to the single Agentic Account's own risk limits, already usable via RPP402-004's delegation path today). |
| RPP402-020 | Analytics | Aggregate reporting over many Sessions/Receipts; a consumer of v1's data, not a dependency of it -deliberately sequenced after real Receipt volume exists. |
| RPP402-021 | Webhooks | Server-initiated event delivery (Settlement confirmed, Receipt issued) as an alternative to polling; related to Notifications (RPP402-017) but scoped to service-to-service delivery rather than agent-facing UX. |
| RPP402-022 | Policy Engine | Programmable, declarative spend/approval rules evaluated before a Payment Intent authorizes -a generalization of what Agentic Accounts do today in a Robinhood-specific way (RPP402-004). |
| RPP402-023 | Usage Metering | Fine-grained, sub-Quote usage tracking (e.g. per-token or per-second billing) for capabilities that don't fit RPP402-002's single fixed-price Quote model. |
| RPP402-024 | Enterprise | SSO, org-level wallets, audit export, and related organizational concerns -orthogonal to the core protocol and best designed against real enterprise adopters' requirements, not speculatively. |
| RPP402-025 | Cross-chain | Settlement (RPP402-005) is Robinhood Chain-only in v1 by design (see RPP402-000 §Relationship to Prior Art -RPP402 is deliberately chain-scoped, not a universal multi-chain standard). Cross-chain settlement, if ever added, most likely arrives via the interoperability bridge below rather than RPP402 reimplementing multi-chain support itself. |
| RPP402-026 | Recurring Billing | Distinct from Subscriptions (RPP402-010) in being calendar-scheduled rather than usage-triggered; likely built on the same recurring-authorization primitive once that exists. |
| RPP402-027 | Treasury | Multi-signature and organizational fund-management flows on top of Agentic Account balances; needs Enterprise (RPP402-024) and Wallet Delegation (RPP402-013) first. |
RPP402-028: MPP / x402 Interoperability
Not from the original brief's exclusion list -added per the Product Strategy's decision to keep RPP402 honest about not needing to reinvent payment transport. The idea: let a Settlement (RPP402-005) execute over an existing x402 or MPP payment rail for the stablecoin-denominated case, so a Service that already speaks MPP or x402 doesn't have to run a second, incompatible settlement path just to also accept RPP402 Commerce Sessions. Deferred out of v1 because it requires both other protocols' wire formats to be treated as stable integration targets, which is a larger commitment than v1 should take on before RPP402 itself has any production usage to justify the integration cost. Tracked here so the option stays visible rather than being designed-away by omission.
Previous: RPP402-006 -Receipt