Facilitator

Payment escrow for streaming and usage-based jobs.

Facilitator extends the x402 payment protocol with a holding step — making it usable for work where cost adds up over time instead of settling in a single transaction.

The Problem x402 Alone Doesn’t Solve

x402 handles one-shot API calls fine: “I want this response, here’s $0.01.” But CodecFlow jobs are open-ended:

• A Fabric GPU cluster running for an unknown amount of time
• A SimArena cloud simulation streaming frame by frame
• An optr operator processing a continuous video feed for hours

Plain x402 schemes don’t work here:

• Exact — client commits to a fixed amount before work starts. Impossible when you don’t know the final cost.
• Upto — client authorizes a maximum, settled at the end. The provider is exposed the whole time — if the authorization expires or the client disappears, the provider ate the compute cost.

x402 Contribution

Facilitator’s escrow model originated from our work on the x402 specification itself. We proposed and built the first implementation of scheme_upto on Solana — solving the race condition where a client can drain their wallet between authorization and settlement.

The gap in plain upto on Solana: SPL Token delegation doesn’t give you single-use authorization, time-bound expiry, or recipient binding natively. Our fix — lock-then-serve — has the settlement program lock maxAmount into a program PDA atomically at verify time, release actualAmount to the recipient at settle time, and refund the remainder. Same zero-gas signMessage UX for the client, but tokens are locked before any resource is served.

Validated with Phantom, Solflare, and Backpack. Ed25519 precompile accepts all three directly.

→ x402 issue #1642 · → PoC repo

What Facilitator Adds

A holding step — funds lock in a smart contract up front, draw down as usage adds up, and the rest comes back when the session ends.

1. Client authorizes     →  signs payment for a maximum amount
2. Facilitator verifies  →  checks signature and available funds
3. Facilitator holds     →  moves funds into on-chain escrow
4. Provider delivers     →  streams compute, simulation, data
5. Facilitator settles   →  releases funds to provider as usage is reported
6. Session ends          →  any held funds left over go back to the client

Provider gets paid as they work. Client pays only for what was used. Neither side has to trust the other — the contract enforces the rules.

Where It’s Used

• Fabric — agents request compute (GPUs, containers, serverless functions) and pay per second from held funds. No billing accounts needed.
• SimArena — when agents access SimArena through the API/MCP server, per-use payments flow through Facilitator. Credits handle humans; Facilitator handles machines.
• optr — operators pay for Fabric compute through Facilitator. Operators offering services get paid through Facilitator. The holding mechanism keeps streaming jobs funded without having to commit to the full duration up front.

Standalone Product

Facilitator works for any service that charges for ongoing usage — streaming APIs, compute platforms, real-time data feeds, pay-per-minute SaaS.

Ships with:

• Smart contracts on EVM chains and Solana
• Rust backend service (verify → hold → settle)
• TypeScript SDKs for client and server
• Dashboard for monitoring active sessions and settlements