Documentation. Your keys never move.

Install the SDK, wrap a route with paymentRequired, and price it in atomic XST units (1 XST = 1,000,000 units; the transparent floor is 10000 = 0.01 XST). An unpaid request gets a 402; the facilitator settles; your handler runs with the receipt on req.x402. Zero dependencies, Node ≥ 18, ESM.

Four parties, four credentials. Only the wallet holds a key that can move funds. There is no “sign up” on the pay side — just Connect, which generates a key on first run (non-custodial, seed shown once) or signs a challenge if a wallet is present. The server stores nothing.

• Wallet · spending key — builds, grinds, and signs the x402 payment. The spending key never leaves the device. Self-custody, standalone or as a Telegram Mini App.
• Sidecar · capped agent credential — each agent calls its own sidecar with a bearer token. The sidecar holds only a capped HD sub-account (model A: the sub-account’s on-chain balance is its hard ceiling), bounded by your caps, rate, and allowlists.
• Console · viewing key + human login — team members sign in by magic link or OAuth; a read-only viewing key decrypts shielded XSS balances and receipts client-side. Read-only by construction.
• Facilitator · no keys — verifies and settles over x402. Holds no spending key and no funds; it never custodies.

Two pieces, zero dependencies: paymentRequired(options) middleware for Express / Connect / plain node:http, and FacilitatorClient, a typed wrapper over the facilitator surface.

On a request with no PAYMENT-SIGNATURE header it mints a challenge and answers 402 with the standard body. With the header it settles (the facilitator resolves the challenge from the payment, so the server stays stateless), sets PAYMENT-RESPONSE (base64 JSON), exposes the receipt as req.x402, and calls next().

The facilitator verifies and settles. It holds no spend keys and no funds at risk. CORS is open (*); only /grind is authenticated. Protocol is x402 v2.

Runs in your infra, bound to 127.0.0.1. Holds only capped agent credentials (model A), enforces caps / rate / allowlists, signs and settles. Every route except /healthz takes the agent’s bearer token (Authorization: Bearer sk_…).

The Console is the viewing-key dashboard — balances, per-agent spend, the live tx feed, receipts, and policy. Its API is read-only and scoped to an organization. Humans authenticate by magic link or OAuth; the viewing key decrypts shielded XSS data client-side, so the Console can see, never spend.

Same exact scheme, privacy carried by the network string. The flow differs in a few real ways:

• payTo is a bech32 shielded address (xss1… / txss1…), minted fresh per challenge at account'/3/index.
• The payload carries a disclosure, not a transaction — a ShieldedDisclosure (cm, recipientAk, value, rho, rho1, memoHex) instead of a raw signed tx.
• No broadcast, no mempool mode — the payment was already gossiped; settle polls until the note commitment cm is included under the latest checkpoint anchor. “Confirmed” = inclusion.
• The receipt id is the note commitment (cm, 32 hex bytes), not a txid.
• Sub-cent pricing — the shielded pool has no dust floor, and pool settlement accumulates many micro-receipts before a bulk exit to Core, lifting the transparent throughput ceiling.

A shielded payment is private, so there is no public receipt. The payer can voluntarily disclose one payment with a self-contained PaymentProof, recovered from their own outgoing notes via the Outgoing Viewing Key. The OVK never leaves the wallet; verification needs no keys.

Verification runs three keyless checks: the opening — H(value‖ak‖ρ₀‖ρ₁) = cm; inclusion — root_from_path(cm, position, path) = anchor_root; and anchor — that anchor_root is a canonical XSS anchor. The stealthPAY extension exports the proof from an XSS transaction; verification happens on StealthMonitor via POST /verify-disclosure (or GET /anchor/{root} against your own node).