How Spoolis routes a payment

Verification produces the routing input

Spoolis starts by checking the delivered work against the plan you agreed to. When receipt signing is configured and the result is determinate, it signs an Outcome Receipt. That receipt records the agreement and plan versions, condition results, evidence digests, overall result, and amount earned.

For unitized work, meaning work counted in units, like records in a batch, the checks run at their declared unit or batch scope. The receipt can show what passed, what failed, why it failed, and the rule for earnings per unit. It can also show pro-rata earned value, meaning the share earned by the units that passed. If 98 units pass at $1 each, the receipt records $98 earned. An uncertain unitized run doesn't issue a receipt.

The receipt is the portable verification artifact. A third party can verify it with @spoolis/receipt-verifier and a pinned trust set, without treating it as payment authorization.

The referee returns a compatible path or a refusal

Payment routing comes next, as a separate deterministic step. The referee, software that applies fixed routing rules, doesn't ask a model to choose a rail or authorize money movement. If a path fits, the referee picks it and tells you why. If nothing fits, it refuses the request and tells you why.

Before it considers a path, the referee requires amount_cents to be a non-negative safe integer and the currency to be a three-letter uppercase code. If the money input is invalid, it refuses the request.

The referee weighs compatibility, authority, and readiness

• Actor type: the referee distinguishes a human from an agent. A human path has to support human payment methods. An agent path has to support agents and match a declared machine capability.
• Amount and currency: the referee checks both before routing. An adapter, the connector that carries out a payment path, can impose narrower limits after selection.
• Configured adapters: outside demo mode, only adapters you supplied as available choices can qualify.
• Readiness: general routing requires a production-ready adapter. If the only match is a Labs adapter, the referee refuses the request instead of presenting that path as available.
• Demo mode: demo mode selects simulation, where no money moves. Simulation isn't a fallback for a live request.
• Declared machine capabilities: the general agent referee matches mpp or x402 declarations to registered machine rails.

The referee doesn't switch actor types, custody models, meaning who holds or controls the funds, or environments just to manufacture a route. If no path qualifies, it refuses the request.

The receipt stays independent of the path

Choosing another compatible adapter doesn't rewrite what verification found. The Outcome Receipt stays a signed record of the outcome and amount earned. The adapter still defines authorization, hold, and execution behavior.

Settlement is the step where the payment is completed. Today, automatic settlement acts only on an overall pass. A partial unitized receipt can record pro-rata earned value, but the built-in flow holds that partial result instead of automatically paying it.

Implemented paths still keep strict boundaries

Stripe Connect: when configured, the production adapter supports human payment methods through manual authorization and capture.

Base spend permission (mainnet): the production wallet-authority lane settles the exact earned amount in USDC on Base mainnet under a capped, expiring, revocable spend permission the buyer grants. The quoted fee is collected separately on settlement.

Tempo keychain pilot: the rail is marked production-ready in the registry, but adapter selection reaches it only through separate fail-closed gates: the exact adapter flag, an allowlisted API key, and the $5 hard cap. The adapter uses Tempo Moderato testnet and testnet pathUSD, so it isn't production money.

MPP and x402: the Tempo MPP sessions rail and x402 batch rail remain Labs entries in general routing. The MPP testnet adapter exists behind its own flag and outside general selection. x402 has no execution adapter.

Demo and sandbox: simulated settlement moves no money. The wallet-authority implementation is an in-memory sandbox.

What to read next

Read when Spoolis decides and when you decide for control boundaries, the MPP and x402 guide for protocol integration, and the settlement-path comparison for adapter lifecycles. For the compact technical reference, use payment paths.