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

Quickstart

Install the SDK:

npm install @rpp402/sdk

Walk one purchase through all six primitives. Every call maps one-to-one to an RFC, and every response is validated against @rpp402/protocol before you get it back:

import { createClient } from "@rpp402/sdk";

const rpp = createClient({ agentWallet: "0xYourAgentWalletAddress" });

// 1. Discover a service and its capabilities (RPP402-001)
const service = await rpp.discover("market-data.example");

// 2. Open a Commerce Session (RPP402-003)
const session = await rpp.session.create(service);

// 3. Request a Quote and attach it to the session (RPP402-002)
const asset = service.supported_assets[0];
await session.quote(service, {
  capability: "market-data.quote",
  params: { ticker: "NVDA" },
  settlementAsset: asset,
});

// 4. Authorize payment for the session (RPP402-004). Pass an authorization,
//    or configure `signTypedData` on the client to have the SDK sign an
//    EIP-712 authorization for you.
await session.intent({
  asset,
  authorization: {
    type: "agentic_account_delegation",
    account_id: "aa_...",
    delegation_ref: "del_...",
  },
});

// 5. Settle onchain, then fetch the verifiable Receipt (RPP402-005, RPP402-006)
await session.settle();
const receipt = await session.receipt();

Prefer the terminal? @rpp402/cli scaffolds and runs a service in one command: npx create-rpp402 my-service.

Each primitive is specified in full in the RFC it links to above. Read them in order, or jump straight to the one you need.

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

RPP402 ships a reference implementation on npm under the @rpp402 scope. It is generated from the same schemas this RFC documents, so it cannot drift from the wire format.

• Schemas - @rpp402/protocol: the JSON Schemas and TypeScript types every RFC is defined against.
• Client - @rpp402/sdk: one method per primitive, with every response validated against the schemas at runtime.
• CLI - @rpp402/cli: scaffold, run, inspect, simulate, and verify services and receipts from the terminal.

Next: RPP402-001 -Discovery