Hilt Pay API Prime Standard

Hilt Pay API is not considered launch-ready because a page exists or an endpoint works once. It is launch-ready only when the runtime, docs, SDKs, Postman assets, OpenAPI, examples, support paths, operator controls, alerts, rollback evidence, and public claims all describe the same system. Internally, Hilt uses a stricter name for this release bar: the Antimatter Standard. Publicly, this page is the Prime Standard.

What the standard protects

The Prime Standard protects one promise:
A buyer paid directly on-chain, Hilt verified the exact payment, Hilt issued the proof and receipt, the product access state changed for the right customer, the merchant system was notified, and every step is available through API, dashboard, logs, alerts, and audit history.
If that chain is broken or ambiguous, the release is not ready.

Launch scope

The first public Hilt Pay API launch is scoped deliberately:
  • solana_usdc is the first production settlement rail.
  • x402 is the protected-resource protocol shape for agent and API flows.
  • At launch, x402 requirements settle over Solana USDC.
  • Base, EVM, and USDT remain future rail families until they pass the same evidence gates.

Runtime correctness

Every live payment flow must satisfy these conditions:
  • The session or requirement is owner-scoped.
  • The amount, product, customer identity, settlement rail, merchant recipient, and expiry are bound before proof submission.
  • Proofs bind back to a Hilt-authored requirement.
  • Replay protection uses canonical proof fields.
  • Receipt mapping requires owner, product, payment, access-product, and customer binding.
  • Entitlement activation requires verified settlement and a bound receipt.
  • Idempotent retries are deterministic.
  • API keys are scoped to the smallest permission set that can complete the job.

Developer and agent distribution

Before a launch claim, developers and agents must be able to discover and implement Hilt Pay API from these surfaces:
  • Developer docs
  • OpenAPI schema
  • TypeScript SDK
  • Python SDK
  • Postman collection and environment
  • GitHub SDK mirrors
  • GitHub developer-assets mirror
  • llms.txt and llms-full.txt
  • FastAPI protected-resource demo
The hero proof is:
Protect an AI API endpoint with Hilt Pay API in 20 minutes.
The protected-resource flow is:
  1. The agent or app requests a protected resource.
  2. The merchant backend checks Hilt entitlement state.
  3. If unpaid, the backend returns HTTP 402 Payment Required.
  4. The response includes a Hilt-created x402 payment requirement.
  5. The buyer or buyer-agent pays over the settlement rail.
  6. Hilt verifies settlement.
  7. Hilt issues receipt and entitlement state.
  8. The agent retries the resource and receives access.

Human approval boundaries

Hilt Pay API is agent-first, not agent-reckless. Agents can create setup intents, products, payment sessions, webhooks, and entitlement checks when they have the right scoped key. These actions still require explicit owner or staff approval:
  • creating or enabling live API keys
  • selecting a paid Hilt Pay API plan
  • confirming live payout wallets
  • enabling live settlement rails
  • rotating webhook or provider secrets
  • enabling future rail families
  • changing treasury or fee-collection settings

Operational control

Operators must have live controls for:
  • billing plan settings
  • Stripe Price IDs
  • Stripe webhook state
  • Helius RPC
  • canonical USDC mint
  • Hilt fee wallet
  • rail status
  • webhook dead letters
  • billing divergence
  • stale billing rows
  • idempotency stuck claims
  • alert delivery
  • kill switches
  • rollback
Admin is the control room. The API remains the system of record for developer and agent integrations.

Release gates

Before public launch, Hilt must attach evidence for:
  • full API smoke rehearsal
  • migration rehearsal on production-shaped schema
  • Solana one-sign split payment verification
  • x402-over-Solana protected-resource drill
  • Stripe checkout session creation and webhook sync
  • webhook retry or dead-letter drill
  • alert delivery drill
  • rollback rehearsal
  • fresh read-only audit
Evidence must be redacted. Secrets, raw provider keys, private wallet material, and customer PII do not belong in evidence files.

Public claim rules

Safe launch claims:
  • Hilt Pay API lets developers and agents add stablecoin-paid access to APIs, AI tools, datasets, bots, paid software, and private products.
  • Hilt verifies payments and turns them into receipts, entitlements, webhooks, and audit records.
  • Funds settle directly on-chain to the merchant wallet.
  • Solana USDC is the first production settlement rail.
  • x402 is the agent/API payment protocol shape.
Unsafe claims until separately proven:
  • Base is live.
  • EVM is live.
  • USDT is live.
  • Hilt is a custodian, bank, merchant of record, or compliance substitute.
  • Proof submission alone grants access.

Current release posture

Use these labels:
LabelMeaning
Internal rehearsalLocal or controlled machine only
Controlled private alphaKnown internal/trusted users, staff-supervised
External private alphaSelected third-party developers with written support scope
Public betaPublic onboarding allowed with explicit beta limits
Public launchDocs, SDKs, pricing, support, observability, rollback, and evidence gates complete
Current target: Solana USDC public launch with x402 protected-resource protocol support.