PubFi billing accounts group API keys and product usage. Runtime admission protects provider execution from becoming a free-form public data proxy.

​
Concepts

​
Public Claims

Safe:
  • PubFi uses API-key auth for registered-account gateway and MCP execution.
  • Clients cannot request or inspect per-key scopes. Only a human Owner or Admin can manage keys.
  • The runtime assigns each key to its own environment and accepts only matching keys.
  • An API key can read its existing execution principal and billing-account binding from /v1/auth/context. This private, no-store read creates no account or billing state.
  • PubFi reserves a bounded amount from a fresh active allocation before provider execution, records actual raw-unit usage, and releases the unused remainder.
  • PubFi records immutable usage evidence. The account-scoped /billing route is the detailed authoritative billing read, /credit-balance returns the authoritative available whole-Credit balance, and /free-quotas returns non-financial server-authoritative limiter state.
  • Registered human users can inspect available purchase offers and create an idempotent purchase with the advertised offer key, catalog release hash, amount, and exact accepted terms identity.
  • The current checked-in pricing target sets one Credit and 0.001 USDC for each priced Subscan and DeGov operation. Its registered-purchase base is $1 for 1,000 Credits. The installed catalog, Runtime OpenAPI, and current offer response remain the execution and availability authorities.
  • A verified purchase can create purchase-origin Credits. A browser redirect alone cannot.
  • Auto Top-Up is off by default. Human account members can read its state. Only an Owner or Admin can add or change the shared payment method, enable or replace the policy, or turn it off.
  • Enabling Auto Top-Up requires a current eligible offer, an active shared payment method, exact accepted Service Credit Terms, a positive whole-Credit threshold and purchase quantity, and a finite UTC monthly limit that covers one full automatic purchase.
  • The dashboard can isolate a temporarily unavailable Auto Top-Up panel while it keeps other valid account data. This state does not prove that manual Credit purchases are unavailable.
  • An eligible x402 request does not create, add, or consume account Credits.
  • Usage, allowance, and billing data are separate from source-selection pages.
Unsafe:
  • exposing raw API keys;
  • exposing private account balances or usage rows outside an authorized account response;
  • treating Credits as pricing, money, a stored-value wallet, or a PubFi-owned financial ledger;
  • inferring billing truth from PubFi usage facts;
  • implying that a purchase route means a production offer is currently available;
  • treating an Auto Top-Up route or saved payment method as proof that the policy is enabled or that an automatic purchase succeeded;
  • implying that PubFi automatically procures or pays an upstream supplier; and
  • implying that x402 has an anonymous Credits balance or account billing dashboard.

​
Agent Guidance

Agents should never receive raw keys inside natural-language prompts. They should call PubFi tools through a runtime that injects credentials from a secret store. Accountless x402 is available over the HTTP gateway and MCP pubfi.route.execute on the explicit /x402 endpoint. The authenticated MCP root instead accepts a PubFi API key or OAuth access token. x402 does not create or consume account Credits. See Payment And Execution Modes.