x402 Under Load: Concurrent Agent Payments, per Chain

Our settlement benchmark measures one x402 payment at a time. This one asks the opposite question: when a burst of agent payments hits a chain at once, does finality stay fast, does the fee stay flat, and does every payment still settle? That is what decides whether agentic commerce holds up on a rail when traffic spikes.

What this benchmark measures

We submit a burst of N concurrent USDC micropayments to a chain and time every one from submit to true finality, repeating at increasing N (10, 50, 100, 500) to see whether finality, fee, or success rate degrade under load. Identical test per chain, same payment, same finality definition, so the comparison stays fair. Here is what each row reports.

Measured: Algorand burst (concurrent USDC payments)

Here is the part that is actually ours. We fired real USDC payment bursts on Algorand mainnet at four concurrency levels and timed every payment from submit to on-chain finality. The result: Algorand absorbed the burst without breaking a sweat, all 660 payments settled, finality barely moved from the one-at-a-time baseline, and the fee never changed. Run dated 2026-08-09.

Three things stand out, and all three are what an agentic payment rail wants:

• 100% settled, even at 500 at once. Every one of the 660 payments reached finality. Nothing dropped, nothing got stuck.
• Finality held flat under load. Median settlement stayed around 5 seconds at 500 concurrent, essentially unchanged from the 5.20s we measured one-at-a-time on the settlement page. A burst does not slow the chain down.
• The fee never moved. Every payment cost a flat 0.001 ALGO (a fraction of a cent) at every burst size. There is no gas auction to spike the cost exactly when volume does, which is the trap on fee-market chains.

Why there is no "payments per second" number here. You might expect a throughput headline like "X payments/sec." We are deliberately not publishing one, because we cannot measure it cleanly yet. We submit every payment through a single free public RPC endpoint, which rate-limits concurrent submissions (HTTP 429) above roughly ten at once. That cap belongs to the free node, not to Algorand, so any per-second figure would be measuring the endpoint, not the chain. The proof it is the endpoint: even at 500 concurrent, the chain settled each payment in about 5 seconds and never raised the fee, only the time to get payments accepted by the free node stretched out. Algorand itself runs in the tens of thousands of transactions per second (a 14,722 TPS record), and we will publish a real throughput ceiling once we run this through a dedicated node. Until then we report only what we can stand behind: finality, fee, and success under load.

Proof, not trust: every payment came from our benchmark account 4R34...LYPJI on Algorand mainnet. The raw benchmark JSON is published here and mirrored under CC BY 4.0, free to reuse with attribution.

Why concurrent load matters for x402

x402 exists so software can pay per request with no human in the loop, which means demand is bursty and parallel in a way human checkout never is. One agent working a task can fan out into many paid API calls at once; a single popular endpoint can be hit by thousands of agents in the same second. On a chain that clears those in a tight window, the endpoint just works. On one that queues them, latency climbs, some payments fail, and, on a gas-market chain, the fee can spike right when volume does. Per-call latency tells you the calm-day experience; behavior under a burst tells you what happens on the busy one.

How it differs from our settlement benchmark

These are two different questions and we keep them separate on purpose. The x402 settlement benchmark sends payments sequentially, one confirmed before the next, to isolate a single payment's own finality time (Algorand measured at about 5.2s median). This page fires them all at once to test capacity under contention. A chain can look great on the first and still strain on the second, which is exactly why both are worth measuring.

Common questions