DEV Community

Cover image for How to pay 100 agents in a single x402 call
Mr Hamlin
Mr Hamlin

Posted on

How to pay 100 agents in a single x402 call

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
Enter fullscreen mode Exit fullscreen mode

Request shape:

{
  "token": "USDC",
  "sender": "0xYourAgentWallet",
  "recipients": [
    "0xRecipient1",
    "0xRecipient2",
    "0xRecipient3"
  ],
  "amounts": [
    "1000000",
    "2500000",
    "750000"
  ]
}
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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:

  1. POST to the endpoint with no payment header. You get back 402 Payment Required with a JSON body describing the price and the facilitator.
  2. Sign a USDC transfer authorization for the price ($0.02) to the payTo address from the response.
  3. Re-POST with the signature in the X-PAYMENT header.
  4. 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"]}'
Enter fullscreen mode Exit fullscreen mode

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.

@mr_hamlin

Top comments (0)