Architecture

Recur is organized into five layers. Each layer has a clear responsibility, and each one can be understood independently before seeing how they compose.

The five layers

Request flow

The following describes what happens when an agent requests a paid resource for the first time.

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

On subsequent requests within an active subscription, step 2 through 4 are skipped — the service verifies the subscription on-chain directly and serves the resource.

Protocol Layer

The Protocol Layer is the HTTP-level negotiation. Recur follows the x402 specification: a service responds to unauthenticated requests with a 402 Payment Required status code and a structured payment object in the response headers. The agent reads those terms and responds with a signed payment or subscription authorization.

Recur’s payment header schema is also designed to be parseable by MPP-compliant agents. Where MPP routes to Stripe/Tempo infrastructure, Recur routes to Solana. An agent needs no code changes to use Recur endpoints — only the network field in the payment object changes.

Settlement Layer

All value moves on Solana mainnet. Recur uses SPL tokens, with USDC as the primary payment token during beta. Solana’s throughput (65,000+ TPS), finality (~400ms), and fee structure (~$0.00025 per transaction) make it practical for both high-frequency per-request payments and low-value metered billing.

Recur does not operate its own ledger. Every plan, subscription, allowance, and payment is a publicly readable Solana account. The chain is the ledger.

Program Layer

The core on-chain logic is built on Solana’s native Subscriptions and Allowances Program (De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44), audited by Cantina and Spearbit. Recur extends it with:

• Recur Plan Registry — an on-chain catalog where service providers publish pricing plans. Plans are immutable once created; subscribers remain on their original terms even when a provider releases a new plan.
• Subscription accounts — on-chain records linking an agent wallet to a plan, including status, billing cycle, and authorized amount.
• Allowance accounts — on-chain spend caps for metered or one-time billing, with accumulated spend tracked transparently.

Facilitator Layer

The Facilitator is the off-chain component that handles the mechanics of verifying payment headers and triggering on-chain settlement. During beta, Recur operates the Facilitator as a centralized service. Centralization during beta is disclosed clearly; the roadmap includes a permissionless Facilitator Network where any operator can run a facilitator node by staking collateral.

The Facilitator also issues Payment Session tokens for high-frequency agents. A session token authorizes a burst of requests against a pre-committed balance. The Facilitator batches the underlying on-chain settlements, reducing per-request latency to near zero while maintaining full on-chain auditability. Payment sessions ship in general availability.

SDK Layer

The SDK abstracts all of the above. Agent developers do not need to understand x402 headers, Solana programs, or facilitator interactions to make their first payment. They install @recur/sdk, initialize a RecurAgent with their wallet, and call agent.pay() or agent.subscribe().

See the Agent SDK and Provider SDK references for the full API.

On-chain transparency

Because all state lives on Solana, any observer can verify any payment or subscription without trusting Recur. This is a core design principle. Recur provides block explorer integration and an indexed event log, but neither is a gatekeeper — the chain is always the authoritative source.