Architecture

Five layers make up Opus Protocol. Each one owns a single, well-defined job, and you can work with any of them without knowing the others in depth. This page describes each layer and then shows how they fit together.

The five layers

Request flow

Here is what happens the first time an agent requests a paid resource.

Agent
  |
  |  1. GET https://api.example.com/v1/data
  v
Service Provider API
  |
  |  2. 402 Payment Required
  |     X-OpusProtocol-Payment: { plan, amount, token, network, ... }
  v
Agent + Opus Protocol SDK
  |
  |  3. Reads payment terms
  |     Signs delegation or transfer via wallet
  v
Opus Protocol Facilitator
  |
  |  4. Verifies authorization on-chain
  |     Executes or schedules transfer via the Opus Protocol contracts
  |     Returns confirmation header
  v
Service Provider API
  |
  |  5. Validates confirmation
  |     200 OK + requested resource
  v
Agent

Once a subscription is active, steps 2 through 4 are skipped. The service checks the subscription on-chain and returns the resource right away.

Protocol Layer

Payment terms are negotiated over HTTP. Opus Protocol follows the x402 specification: a request without payment gets a 402 Payment Required status, and the response headers carry a structured payment object. The agent answers with a signed authorization for a payment or a subscription.

The schema of the payment header is designed so that MPP-compliant agents can parse it too. MPP points at Stripe/Tempo infrastructure, while Opus Protocol points at Robinhood Chain. The only difference in the payment object is the network field, so an MPP agent can call Opus Protocol endpoints with no code changes.

Settlement Layer

All value settles on Robinhood Chain mainnet and nowhere else. Opus Protocol is built on the standard ERC-20 interface. For the beta, USDG (Global Dollar) serves as the primary payment token; Paxos issues it, and it is native to Robinhood Chain. The chain itself is an Arbitrum Orbit Ethereum L2 that targets ~100ms block times. Sequencer confirmation is near-instant, full finality comes when the batch settles on Ethereum, and a transaction costs well under a cent. Together these properties make frequent per-request payments and small metered charges an ordinary workload.

There is no separate Opus Protocol ledger. Plans, subscriptions, allowances, and payments are contract records on the chain, and anyone can read them. The source of truth is the chain itself.

Contract Layer

The on-chain logic is a group of open-source contracts published by Opus Protocol. They use Solidity 0.8 and OpenZeppelin, and they are deployed to Robinhood Chain. The OpusSubscriptionEngine contract lives at 0xde1e6a7e615c023c014171bc46cc764cedcf1df6; before the beta ends, an external security audit is planned. Beyond subscriptions, the contracts also cover the following:

• Opus Protocol Plan Registry: the catalog of provider pricing plans, kept on-chain. Once a plan is published it cannot change, so a subscriber keeps the original terms no matter what newer plans the provider releases.
• Subscription records: on-chain links between an agent wallet and a plan, holding the authorized amount, the billing cycle, and the status.
• Allowance records: on-chain spending caps that apply to metered and one-time billing; the running totals are public.

Facilitator Layer

Off-chain, the Facilitator handles the mechanics: it checks payment headers and triggers on-chain settlement. For the beta, Opus Protocol runs the Facilitator as a centralized service. That is a stated trade-off, and the roadmap leads to a permissionless Facilitator Network where anyone who stakes collateral can run a node.

The Facilitator also hands out Payment Session tokens to high-frequency agents. A session token authorizes many requests in a burst, drawn from a balance that the agent commits in advance. Settlements underneath are batched on-chain, which pushes per-request latency toward zero without giving up on-chain auditability. Payment sessions arrive with general availability.

SDK Layer

At the SDK layer all of the above is hidden. To send a first payment, an agent developer never deals with x402 headers, with the contracts, or with a facilitator connection. Install @opusprotocol/sdk, create an OpusProtocolAgent from a wallet, then call either agent.pay() or agent.subscribe().

For the complete API, see the Agent SDK and Provider SDK references.

On-chain transparency

Every piece of state is on Robinhood Chain, so anyone can verify a payment or subscription without trusting Opus Protocol. That is a deliberate design choice. Opus Protocol provides an indexed event log and block explorer integration for convenience, but neither one gates access to anything. The chain holds the authority.