跳到内容
xobank.cash
全部文章
Protocol2026-06-30 · 8 分钟阅读

BAPARA: agentic commerce built on x402

How we extended x402 with budget metadata and AP2 compatibility.

xobankai engineeringProtocol team

HTTP has had a status code for payments since 1997. Code 402, "Payment Required", sat reserved and unused for almost thirty years because the web grew up on ads and subscriptions instead. Then AI agents arrived — software that can read documentation, choose a tool, and call an API — and suddenly the missing primitive mattered. An agent cannot fill out a Stripe checkout. It cannot wait three days for an API key to be provisioned. It needs to pay the way it does everything else: in a request header, at machine speed.

x402, introduced by Coinbase, resurrected the status code: a server answers 402 with the price and the asset it accepts, and the client retries with a signed payment attached. BAPARA — the bankai agent payments protocol — is our production extension of that idea.

What BAPARA adds

Raw x402 answers "how does the agent pay?" BAPARA answers the question that actually blocks deployment: "how do I let it pay without giving it my money?" Three extensions:

Budgets. Every BAPARA wallet carries a signed budget envelope — per request, per hour, per day. The facilitator rejects any authorization that would breach it. Overspending is not a bug you catch in a dashboard; it is a signature that never verifies.

Intents. Payments carry an intent field (ap2/paid-inference-v1, for example) that is compatible with Google AP2 mandates, so the same authorization chain works across ecosystems instead of fragmenting per vendor.

Receipts. Every settled payment returns a signed receipt in the X-Payment-Receipt header, mapped to ISO 20022 fields. Finance teams read agent spend the way they read a bank statement, and auditors get cryptographic provenance for free.

The settlement layer

Under the hood the payment is an EIP-3009 transferWithAuthorization: the agent signs a USDC transfer offline, the server forwards it to a facilitator, and the facilitator verifies and settles onchain — Base today at roughly 200 milliseconds and $0.001 median, Solana at 400 milliseconds and a fraction of that fee. The agent never holds gas, never manages nonces, never touches a private RPC. It signs; the facilitator does the plumbing.

server · three lines to charge
import { paymentRequired, verifyPayment } from '@xo/bapara-sdk/server';

const pr = paymentRequired({ amount: '0.002', recipient: WALLET });
if (!req.headers['x-payment']) return res.status(402).json(pr);
const check = await verifyPayment(req.headers['x-payment'], { expect: pr });

Why it matters

Every previous machine-payment scheme failed on the same rock: it required the machine to impersonate a human — a stored card, a scraped session, a shared API key with unlimited blast radius. BAPARA gives the agent its own economic identity with a hard ceiling. That flips the security model: the question stops being "what could it spend?" and becomes "what did we authorize?"

The SDK is TypeScript-first with framework adapters for Express, Fastify, Hono and Next.js route handlers. The whitepaper, reference facilitator, and a sandbox faucet are in the docs. If you are building an agent that consumes paid APIs — or an API that wants agents as customers — we would like to hear what you ship.