Overview

Valeo Stratum is a clearing and netting layer for x402 AI agent payments. It is not a facilitator. It never touches money. It never settles payments on-chain. It never holds custody of anything.

Stratum solves the problem Stripe identified in their 2025 Annual Letter: current blockchains cannot handle the 1M–1B transactions per second that AI agents will generate. Rather than building a new blockchain, Stratum applies the same clearing/netting model that traditional finance has used for decades (DTCC, CLS Bank, Visa) to compress millions of logical transactions into minimal on-chain settlements.

What Stratum Does

Stratum does exactly three things:

1. Intercepts and defers. When an agent sends a payment, Stratum records a signed receipt — a cryptographic IOU. The money has not moved.
2. Nets. At settlement window close, Stratum computes net positions across all counterparties. 1M bilateral IOUs collapse into a handful of net transfers.
3. Instructs. Stratum sends settlement instructions to the real facilitator (Coinbase, Circle, etc.). The facilitator executes the actual on-chain USDC transfers.

Stratum separately anchors a Merkle root on-chain for auditability — but that is a data hash, not a payment. This is the “INSTRUCTING” model: Stratum instructs facilitators, it never settles.

Architecture

The system flow:

Agent → Stratum (clearing layer) → Facilitator (Coinbase/Circle) → Chain (Solana/Base)

Core Components

Stratum Gateway — A reverse proxy + clearing engine. Service providers register their API, agents hit the proxied endpoint, Stratum handles payment clearing automatically.

Receipt Ledger — An event-sourced double-entry ledger that records every signed receipt within a settlement window. Provides idempotency, position tracking, and window-scoped queries.

Netting Engine — Computes multilateral net positions across all counterparties. Verifies the sum-to-zero invariant and produces a minimal set of settlement instructions.

Merkle Tree — RFC 6962 compliant append-only tree. Every receipt is hashed into a leaf. The root is anchored on-chain for public verifiability.

Write-Ahead Log — Ensures crash recovery. Every mutation is logged before execution. Supports checkpoints and compaction.

Integration Guide

Tier 1: No Code (30 seconds)

1. Sign up at console.stratum.valeo.com
2. Paste your API URL
3. Set pricing per route (e.g., $0.002 per request)
4. Get your Stratum endpoint
5. Share the endpoint with agents — done

Zero code. Zero blockchain knowledge. Stratum handles clearing, netting, and settlement automatically.

Tier 2: One Line (existing x402 services)

If you already use x402, change the facilitator URL to route through Stratum:

// Before
const paywall = createPaywall({
  facilitatorUrl: 'https://x402.coinbase.com'
})

// After
const paywall = createPaywall({
  facilitatorUrl: 'https://stratum.valeo.com/v1/facilitate'
})

Same facilitator settles. Stratum clears the traffic first, reducing on-chain load by orders of magnitude.

Tier 3: Full SDK (self-hosting)

import { StratumGateway } from '@valeo/stratum'

const gateway = new StratumGateway({
  facilitator: 'https://x402.coinbase.com',
  settlementWindow: '5m',
  chain: 'solana',
  asset: 'USDC',
})

app.use('/api', gateway.middleware())

Install packages, run your own clearing node. Full control over settlement windows, netting logic, and facilitator selection.

Receipt Format

A receipt is the core clearing primitive. It records that a payer owes a payee a specific amount for a resource within a settlement window. No money moves when a receipt is created.

Receipt Fields

Signed Receipt

A SignedReceipt wraps a receipt with an Ed25519 signature and the signer's public key. The signature is computed over the canonical encoding of the receipt (sorted keys, deterministic BigInt and Uint8Array serialization).

interface SignedReceipt {
  version: number
  receipt: Receipt
  signature: Uint8Array     // Ed25519 signature
  signer_public_key: Uint8Array  // 32-byte public key
}

Merkle Proofs

Stratum uses an RFC 6962 compliant Merkle tree to provide cryptographic proof that every receipt in a settlement window is included in the on-chain commitment.

Hashing Rules

Leaf hash: SHA-256(0x00 || leaf_data)
Node hash: SHA-256(0x01 || left || right)

The 0x00/0x01 prefix prevents second-preimage attacks by making leaf and internal node hashes distinguishable.

Inclusion Proof

An inclusion proof demonstrates that a specific receipt hash is a leaf of the Merkle tree with a known root. The proof contains the sibling hashes along the path from the leaf to the root. Verification recomputes the root by hashing up the path and comparing.

Consistency Proof

A consistency proof demonstrates that a smaller tree (from an earlier point in the window) is a prefix of the larger tree. This proves the tree is append-only: no receipt can be removed or modified after inclusion.

Settlement Windows

A settlement window is a time-bounded period during which receipts accumulate. At the end of a window, positions are netted, instructions sent, and the Merkle root anchored.

State Machine

OPEN → ACCUMULATING → PRE_CLOSE → NETTING → INSTRUCTING → ANCHORING → FINALIZED
                                                                          ↘ FAILED

The WindowManager provides zero-downtime transitions: when a window closes, a new one opens immediately. Receipts submitted during settlement of the old window go into the new one.

Netting

Multilateral netting compresses bilateral obligations into a minimal set of net transfers.

Worked Example

Consider 5 agents making API calls to 3 services during a window:

Gross bilateral positions:
  Agent A → Service X: $500
  Agent A → Service Y: $200
  Agent B → Service X: $300
  Agent B → Service Z: $400
  Agent C → Service Y: $150

Net positions after aggregation:
  Agent A:    -$700  (owes $700 net)
  Agent B:    -$700  (owes $700 net)
  Agent C:    -$150  (owes $150 net)
  Service X:  +$800  (owed $800 net)
  Service Y:  +$350  (owed $350 net)
  Service Z:  +$400  (owed $400 net)

Sum of all net positions: $0 ✓ (invariant holds)

Settlement instructions (4 transfers instead of 5):
  Agent A → Service X: $700
  Agent B → Service Z: $400
  Agent B → Service X: $100
  Agent B → Service Y: $200
  Agent C → Service Y: $150

In production, 1M bilateral receipts compress to tens of net transfers. The sum-to-zero invariant is always verified before settlement proceeds.

API Reference

The Stratum Gateway exposes the following REST endpoints:

Request Headers

X-PAYMENT: <agent-wallet-address>
Content-Type: application/json

Response Headers

X-STRATUM-RECEIPT: <receipt-id>
X-STRATUM-SEQUENCE: <sequence-number>

402 Payment Required Response

When a request is missing the payment header, Stratum returns:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "price": "200",
  "asset": "USDC",
  "payee": "svc-ai-inference",
  "network": "solana"
}

FAQ