Batch Payments for Agents (BPA) 1.0: an open standard for how AI agents pay many recipients at once

#ai #blockchain #opensource #webdev

Agents can now act. They book, they buy, they call tools, they spend. But ask a simple question — how does an autonomous agent pay 500 people in one go? — and there's no clean answer. There's a pile of one-off integrations and a lot of hand-waving.

So we wrote the spec. Batch Payments for Agents (BPA) 1.0 is a framework-neutral, open standard for how an agent disburses funds to many recipients in a single, governed, verifiable batch. It's live and citable here:

👉 docs.spraay.app/bpa/1.0 · source: github.com/plagtech/bpa-spec

This post is the why and the what.

The payments agents actually need are the ones the old rails punish

Card and bank networks are optimized for a human clicking checkout once. Agent payouts are the opposite shape, and they break the cost model in three specific ways:

Micro-amounts. Paying a crowd of data labelers $0.50 a task dies on fixed fees.
Machine-initiated. No human at checkout, no card-present flow, no chargeback dance.
One-to-many, global. Pay 500 contributors at once, many cross-border or unbanked, and settle in seconds.

Stablecoins on fast chains solve the rail. What's missing is the contract — the agreed-upon shape of "an agent safely pays many recipients at once." Without it, every team rebuilds the same fragile logic: how do you make a batch idempotent? what happens when line 347 of 500 fails? how do you prove it settled? how do you stop a misbehaving agent from draining a treasury?

BPA answers those questions once, so nobody has to answer them again.

What BPA 1.0 actually defines

The spec is deliberately boring in the way good infrastructure is boring. It nails down:

A request format — one Disbursement Request object, with a JSON Schema you can validate against.
Idempotency — replay-safe by construction, because batch disbursement is irreversible.
Partial-failure semantics — atomic by default; if a rail can't be atomic, per-recipient results and a retry token scoped to only the failed lines.
Settlement confirmation — verifiable on-chain, per-chain finality rules, no "trust me, it sent."
A governance model — spend caps, recipient allowlists, approval gating, and tamper-evident audit, all evaluated before settlement and failing closed.
Transparent fees, transport bindings (x402 / MPP), and an MCP tool shape.

Here's the core object an agent constructs:

{
  "bpa_version": "1.0",
  "idempotency_key": "payout-2026-06-02-001",
  "chain": "eip155:8453",
  "asset": "USDC",
  "recipients": [
    { "address": "0xAbc...", "amount": "5000000", "ref": "worker-001" },
    { "address": "0xDef...", "amount": "5000000", "ref": "worker-002" }
  ]
}

Amounts are integer base units (no float drift). Validate it against the published JSON Schema before you send.

Three design choices worth calling out

Non-custodial end to end. The facilitator only builds the transaction; the agent's own signature authorizes the spend. The gateway never holds funds. That single property collapses a whole class of security concerns — a forged request just produces an unsigned transaction nobody can submit.

Governed before execution, not after. BPA treats every disbursement as a high-risk action. The goal isn't to ask an agent to behave — it's to make an out-of-policy payout structurally impossible. Caps, allowlists, and approvals are deterministic checks the request must pass before a single token moves. If policy can't be evaluated, the answer is "denied."

Three chains, on purpose. BPA 1.0 is normatively defined for Base, Ethereum, and Solana — where agent payment activity actually concentrates, plus institutional reach. We run the reference contract on more chains, but a spec's credibility is its weakest claim. Everything in the normative body is mainnet and source-verified (the settlement contracts are verified, exact-match, on BaseScan and Etherscan). Breadth that isn't load-bearing is just surface area for doubt.

Try it

Spraay is the reference implementation (full disclosure: it's ours, and writing the spec forced us to make it airtight). You can hit it two ways:

HTTP / x402: POST https://gateway.spraay.app/api/v1/batch/execute — returns an unsigned transaction for your agent to sign.
MCP: the spraay_batch_execute tool, published on Smithery as @plagtech/spraay-x402-mcp, described by intent so your agent matches it at runtime.

The on-chain protocol fee is 0.30%, with a 200-recipient cap per call (chunk larger batches under one idempotency key).

It's an open standard — build on it

BPA is published under CC-BY-4.0. Implementations are unrestricted and need no permission. There's a conformance checklist (§14) and a self-attestation format for any facilitator — not just ours — to claim conformance. If you're building agent infrastructure and you touch payouts, this is meant to be the reference you point your own tooling at.

If the attestation model for task-gated payments (pay-on-approval) is something you have strong opinions about, that's the one piece explicitly scoped for 1.1 — open an issue.