You're building an agent that pays for things. It pulls market data, hits an inference endpoint, fans out USDC to 50 freelancers, and writes a row to your database. Four steps.
Three of those steps are one HTTP call each. The fourth — paying 50 people — is 50 transactions, 50 nonces to track, 50 places where something can fail halfway. Your "agent" spends 90% of its runtime managing payment loops.
This is the part of the agent stack that nobody talks about. The x402 marketplace today is full of read-side services: Anthropic, OpenAI, CoinGecko, Exa, Perplexity. They give your agent inputs. None of them help your agent fan money outward.
That's the gap I've been building into for the last few months. This post is a quick tour of why batch settlement matters, why it's the right primitive for the agent economy, and how to actually use it in your code right now.
The cost of doing it wrong
Let's get specific. Say your agent needs to pay 50 USDC recipients on Base. Doing it the obvious way — one ERC-20 transfer per recipient — looks like this:
| Approach | Transactions | Total Gas | Wall-Clock Time | Failure Modes |
|---|---|---|---|---|
| 50 sequential transfers | 50 | ~3,300,000 | 60-120 seconds | Per-tx revert, nonce gaps, RPC drops |
| 50 parallel transfers | 50 | ~3,300,000 | 5-15 seconds | Nonce conflicts, replacement underpriced |
| 1 batch call | 1 | ~280,000 | 2-3 seconds | Atomic — all or none |
The batch path saves ~92% of the gas and roughly an order of magnitude on wall-clock time. More importantly, it's atomic: either all 50 transfers land in the same block, or none do. Your agent never has to reconcile partial state.
If you've ever built a payroll system, an airdrop tool, a marketplace payout, or an AI agent that distributes rewards, you know exactly why this matters. Partial state is where bugs live.
Why x402 needs this primitive
The x402 protocol is beautifully simple: a server responds with 402 Payment Required, the client attaches a payment proof, the server returns the resource. It works because each request is a single payment unit.
But the agent economy isn't single-recipient. Real workflows look like this:
- A research agent buys 10 different data sources for one report, then pays the user a share back.
- A trading agent settles fees to multiple liquidity providers in a single decision cycle.
- A supply chain agent pays a supplier, the carrier, and the inspector when an invoice clears.
- A DAO treasury agent distributes monthly payments to 200 contributors.
Each of those workflows works through x402, but the payment leg currently has to fall back to a non-x402 path — ethers, viem, custom batch contracts, or a centralized service. That's friction. And friction is where adoption dies.
So I built the missing piece: an x402 endpoint that takes a list of recipients and amounts, and settles all of them in a single on-chain transaction.
The endpoint
The Spraay gateway exposes batch settlement as a paid x402 resource. One call in, one transaction out, atomic across all recipients.
POST https://gateway.spraay.app/api/v1/batch/execute
Request shape:
{
"token": "USDC",
"sender": "0xYourAgentWallet",
"recipients": [
"0xRecipient1",
"0xRecipient2",
"0xRecipient3"
],
"amounts": [
"1000000",
"2500000",
"750000"
]
}
Amounts are in token-base units (USDC has 6 decimals, so 1000000 = 1 USDC). The cost is $0.02 in USDC paid via x402, regardless of recipient count — economics get better the more recipients you have.
The endpoint hits a batch contract on Base (0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC), which loops the transfers in a single transaction. Either every recipient gets paid in the same block, or the whole call reverts.
Calling it from an agent
Any HTTP client that speaks x402 can hit this endpoint. The simplest path is the official x402-fetch wrapper — it handles the 402 challenge automatically:
import { wrapFetchWithPayment } from "x402-fetch";
import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";
const account = privateKeyToAccount(process.env.AGENT_PRIVATE_KEY!);
const wallet = createWalletClient({
account,
chain: base,
transport: http(),
});
const fetchWithPayment = wrapFetchWithPayment(fetch, wallet);
const response = await fetchWithPayment(
"https://gateway.spraay.app/api/v1/batch/execute",
{
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
token: "USDC",
sender: account.address,
recipients: [
"0xRecipient1...",
"0xRecipient2...",
"0xRecipient3...",
],
amounts: ["1000000", "2500000", "750000"],
}),
}
);
const result = await response.json();
console.log("Batch tx hash:", result.txHash);
That's the whole integration. Three recipients, fifty recipients, two hundred recipients — same code shape, same gas profile per call.
If you're not using x402-fetch, the manual flow is:
-
POSTto the endpoint with no payment header. You get back402 Payment Requiredwith a JSON body describing the price and the facilitator. - Sign a USDC transfer authorization for the price ($0.02) to the
payToaddress from the response. - Re-
POSTwith the signature in theX-PAYMENTheader. - Get back your batch result with the on-chain tx hash.
Where this fits in a larger agent
Batch settlement is most useful as a primitive that other things compose on top of. A few patterns I've seen agents use:
Periodic distribution. A cron-driven agent that pulls revenue, splits it across stakeholders, and pays them out weekly. One batch call per cycle.
Marketplace payouts. A listing platform agent that resolves orders end-of-day and pays sellers atomically.
Multi-hop settlement. An agent that pays an LLM provider, a search provider, and a vector DB provider all from the same workflow's budget — batched so the user is charged once, atomically.
Agent-to-agent commerce. When agents subcontract work to other agents, the paying agent can settle the entire delegation tree in one call rather than chaining individual payments.
The Spraay gateway has 90+ other x402 endpoints — agent wallet provisioning, on-chain DeFi positions, contract reads/writes, multi-chain RPC, AI inference (including a Bittensor drop-in at /bittensor/v1), oracle data, and more — but batch settlement is the one that nothing else on the x402 marketplace currently offers. Everything else is competitive; this one is structurally unique.
Try it
The simplest sanity test: hit the endpoint without payment and watch the 402 challenge come back.
curl -i -X POST https://gateway.spraay.app/api/v1/batch/execute \
-H "Content-Type: application/json" \
-d '{"token":"USDC","sender":"0x...","recipients":["0x..."],"amounts":["1000000"]}'
You'll get a 402 Payment Required response with the payment requirements. That confirms the endpoint is live and gated. From there, drop in x402-fetch (or your favorite x402 client) and you're paying batch in five minutes.
The endpoint works on Base mainnet today. If you're building anything that fans money outward — payroll, airdrops, multi-recipient agent workflows, marketplace payouts — give it a try and let me know what breaks. I read every reply.
Discovery doc with the full endpoint catalog: https://gateway.spraay.app/.well-known/x402.json
Build something. Pay everyone. In one call.
Top comments (0)