RPP402-000: Introduction

Overview

The Robinhood Payments Protocol (RPP402) is an open protocol that lets autonomous AI agents discover services, request pricing, authorize payment, and settle commerce on Robinhood Chain -and receive cryptographic proof that it happened. RPP402 v1 defines exactly six primitives:

1. Discovery -an agent finds a service and its capabilities.
2. Quote -an agent requests pricing for a capability.
3. Commerce Session -an atomic lifecycle container that groups one or more quotes into a single purchase.
4. Payment Intent -an agent authorizes payment for a session.
5. Settlement -the authorized intent executes on Robinhood Chain.
6. Receipt -cryptographic proof the session settled.

Nothing else is in scope for v1. Everything else -subscriptions, streaming, escrow, wallet delegation, marketplace listing, reputation, identity, and more -is deliberately deferred to the Roadmap as future RFCs, so v1 stays small enough to fully implement, fully audit, and fully commit to.

Robinhood Chain
      ↑
  Settlement
      ↑
     RPP402
      ↓
 Discovery → Quote → Commerce Session → Payment Intent → Receipt
      ↓
  AI Agents

Motivation

An autonomous agent's purchase is rarely one resource. An agent provisioning a research pipeline might need a market-data quote from one provider, compute from a second, and a model API from a third -compared against alternatives, held in a consistent state while it decides, and settled together. No primitive in the prior art below represents that multi-step, multi-provider shape; each treats "pay for one HTTP resource" as the whole problem. RPP402 treats that as one primitive (Quote) inside a larger one (Commerce Session) built to hold exactly this kind of state.

RPP402 is also the first agent-commerce protocol that can settle in a tokenized real-world asset, not only a stablecoin, because it is the native protocol of the one chain whose operator is a regulated broker-dealer with an existing tokenized-equity product. See RPP402-004 §Settlement Assets.

Problem

Concretely, before RPP402 an agent that wanted to compare three data providers, buy from the cheapest, and prove the purchase happened had to:

• Hand-roll provider comparison (no standard quote object to diff).
• Track purchase state itself across N independent HTTP 402 cycles with no shared session identity.
• Accept whatever receipt format (if any) each provider invented.
• Have no standard way to pay in anything other than a stablecoin, even when the paying agent's actual spending authority is denominated in tokenized equity via a Robinhood Agentic Account.

RPP402 standardizes all four without inventing a competing payment-transport wire format -see Relationship to Prior Art.

Terminology

Relationship to Prior Art

RPP402 is not the first attempt to standardize machine-to-machine payment. Two efforts predate it, are already in production, and RPP402 does not try to replace either:

Where MPP and x402 answer "how does an agent pay for one thing," RPP402 answers "how does an agent conduct a multi-step purchase that happens to settle on Robinhood Chain, possibly in a tokenized security." These are complementary, not competing, questions -an RPP402 Settlement (RPP402-005) could in principle execute over an x402 or MPP payment rail for the stablecoin-denominated case. That bridge is intentionally not specified in v1; it is tracked as a roadmap item (see Roadmap: MPP/x402 Interoperability) so v1 can ship without taking on a dependency on either protocol's stabilization.

We name both explicitly, here and in every RFC where relevant, because an infrastructure standard that hides well-known prior art from the engineers it's asking to trust it has already lost their trust.

Protocol Versioning

• The wire format version is 1.0.0 (this document). RPP402 follows semver for the wire format: additive, backward-compatible fields are minor bumps; anything requiring a client to change to keep working is a major bump.
• Every RPP402 object carries an rpp402_version field (e.g. "1.0") so a client or server can detect a version mismatch instead of silently misparsing.
• RFC status lifecycle: Draft (this repository, pre-release) → Active (adopted, wire-format frozen for that major version) → Superseded (replaced by a later RFC, kept for historical reference).

Security (Overview)

Each RFC has its own Security section scoped to that primitive. At the protocol level: every primitive is signed or verifiable back to an onchain artifact (a Payment Intent authorization, a Settlement transaction, a Receipt signature) -nothing in RPP402 relies on an unverifiable claim from a single party. See RPP402-004 §Security, RPP402-005 §Security, and RPP402-006 §Security.

Errors

All RPP402 endpoints return errors as application/problem+json (RFC 9457):

{
  "type": "https://rpp402.com/errors/quote-expired",
  "title": "Quote Expired",
  "status": 410,
  "detail": "Quote quote_8f2e... expired at 2026-07-10T18:22:00Z.",
  "instance": "/sessions/sess_1a2b/legs"
}

Each RFC defines its own type values in its Errors section; there is no separate error registry RFC in v1.

Best Practices

• Treat every primitive's identifier (quote_*, sess_*, intent_*, settle_*, rcpt_*) as opaque and globally unique -never parse structure out of it.
• Always check rpp402_version before trusting a response shape.
• Prefer the SDK (@rpp402/sdk) over hand-rolling HTTP calls against these schemas directly; it is generated from the same source (@rpp402/protocol) these RFCs document, so it cannot drift from them.

Reference Implementation

• Schemas: packages/protocol (Phase 4, this phase).
• Client: packages/sdk (Phase 5).
• CLI: packages/cli (Phase 10).

Next: RPP402-001 -Discovery