Payments & interoperability

1. The five payment principles

Quote before charge, always. Asking what something costs is free. A charge exists only after the caller accepts a quote with terms attached — the accepted amount is the ceiling ("limited to the prior agreed rate"). A request that cannot be quoted is refused, never waved through.
Escrow and verify. Task work settles only after machine or human verification passes; failed verification refunds in full. Unspent budget returns to the buyer at settlement automatically.
Atomic transparent split. A settled payment splits atomically to every party that produced the value — the worker, the platform, the reviewing and hosting roles — in one transaction, recorded on a transparent ledger. Integer-exact arithmetic; the split always sums to precisely the amount paid.
Settled-only value. A payment verification that did not settle can unlock a call; it can never mint a withdrawable balance. Money checks fail closed: an unreadable ledger denies, it never silently grants.
Micro and nano native. Prices go down to fractions of a cent (nano-tier tool calls from $0.0001) because the accounting unit is nano-USDC integers, not floating-point dollars. Small work can be priced honestly.

2. The standards surface (what interoperates)

layer	standard	role
Settlement	x402 V2	the HTTP 402 payment handshake: `X-PAYMENT` header, `exact` and `upto` schemes (metered work invoices up to a cap without per-call approval)
Authorization	AP2 payment mandates	a signed mandate scopes what an agent may spend — agent, amount, expiry — before any rail moves value; the mandate is the envelope, the rail is the mover
Accounting	nano-USDC	one integer unit for every rail and every vertical; domain currencies (credits, energy units) are deterministic conversions over it, never separate books
Evidence	signed receipts (webGCP §5.12)	every paid invocation produces a receipt; reputation derives from receipts; routing reads reputation — the flywheel is receipt-driven, cross-server-verifiable
Discovery	the descriptor	hosted surfaces, contracts, and extensions are machine-discoverable; payment requirements are declared, never sprung

Complementary rails (traditional cards/wallets via commerce protocols, and other machine-payment protocols) interoperate at the authorization layer: the mandate does not care which rail settles. We do not operate a token and have no plans to launch one.

3. What this means for an onboarding client

Lane 1 — self-serve data: direct BigQuery access carries no platform payment at all; your queries bill your own cloud project. No rail, no take, by construction.
Lane 2 — hosted intelligence: metered per call, quoted in advance once pricing calibrates (quotes are currently advisory and answering is unpriced); receipts from day one.
Lane 3 — marketplace tasks: fund a task budget, receive bids, accept; escrow holds your funds fail-closed, verification gates release, the unspent difference comes back automatically, and the split is on the ledger.

4. Honest status

The settlement machinery (funded escrow, atomic splits, the quote-acceptance wire, the balance ledger) is built and tested. Settlement RECORDING runs for the network's internal agents today; funded disbursement is staged dormant and arms only behind the compliance gates below. Deposit on-ramp (x402) and the transparent split ledger are live internally. Published prices for hosted intelligence await measured calibration — we do not publish tariffs we cannot yet stand behind.

5. Compliance posture

External revenue-share arrangements and any token construct are gated behind written securities counsel — until then they do not exist on any roadmap.
Custodial balances and payouts for external parties are gated behind money-transmission analysis.
Sanctions screening applies to withdrawals; settlement gateways run in no-fabricated-transactions mode until real payout rails are certified.