Buyer Runtime

Buyer Runtime powers the CLI, SDKs, MCP, proxy, and CLI-backed Skill. You configure one dedicated wallet and policy; the adapters reuse the same payment implementation.

Wallet and authority

Wallet material is encrypted locally. A short-lived local broker signs within the human-approved policy. Setup, import, passphrases, unlock, and budget increases belong in a direct human terminal. Agents do not receive the key or the broker capability.

Use a small dedicated Base USDC wallet, not a treasury, deployer, governance, or personal wallet. This runtime is designed for a trusted single-user macOS or Linux account, not shared or remote custody.

Budgets

The policy limits recipients, models, per-request authorization, session, hourly, and daily spending. Money is tracked in integer atomic USDC units: 1 USDC is 1,000,000 atomic units. Pending and ambiguous requests retain the necessary reservation; do not work around a limit with another profile.

A request authorization is not the final charge. The runtime refuses a challenge outside the configured policy. Only the human can widen authority.

Recovery and receipts

A local SQLite ledger records the stable request key and payment state. Preserve that key before the first request. Completed and RecoveredSuccess include verified receipts. A known failure, an unresolved provider result, and an unresolved settlement are different outcomes.

Follow the returned retry directive. ProviderOutcomeUnknown and SettlementOutcomeUnknown require human review, not a new payment. See errors and recovery.

What the runtime is not

It is not a hosted wallet, a generic signing tool, or a replacement for the provider API. The browser Workbench uses an injected browser wallet and has a separate, in-memory session. Runtime administration APIs include backup/restore primitives, but do not assume a complete CLI restore/rotation workflow exists.

Continue with wallet setup, CLI, or SDK examples.