Roadmap -Future RFCs (RPP402-010+)
RPP402 v1 is deliberately six primitives: Discovery, Quote, Commerce Session, Payment Intent, Settlement, Receipt. Everything below was explicitly named out of scope for v1 so the core stayed small enough to fully implement and audit. 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