Field note

Under a second is the right answer to the wrong question

At an AWS Bedrock AgentCore Payments session the question was what happens at a thousand transactions a second, and the answer was settlement in under a second. Both are true and they answer different questions. The right frame for one payment crossing a trust boundary is the wrong frame for a million events a day inside one agent fleet, where the chain fee stacks up before anything else does.

May 20, 2026 · Navin Agrawal · Payments · 3 min read

Under a second is the right answer to the wrong question

Visual brief

Visual brief

Under a second is the right answer to the wrong question

As of May 2026

At the AWS Bedrock AgentCore Payments session, the question I would have asked got asked: what happens at a thousand transactions a second? The x402 answer was settlement in under a second. Both are true. They are answering different questions.

Under a second is the right answer for one payment crossing a trust boundary. It is the wrong answer for a million events a day inside one company’s agent fleet, where the cost stops being a latency number and becomes a volume number.

The preview

AgentCore

AWS, Coinbase, and Stripe shipped an x402 payments preview on 7 May 2026 - USDC on Base in about 200ms.

One payment

Sub-second

a single x402 transfer clears well under a second, the right frame for one payment crossing a trust boundary.

A fleet

86.4M/day

a thousand payments a second is 86.4 million a day, where the per-transaction chain fee stacks up.

The infrastructure is real

AWS, Coinbase, and Stripe put real infrastructure behind the AgentCore Payments preview, launched on 7 May 2026 and built on Coinbase’s x402 protocol. The launch settles in USDC on Base in roughly 200 milliseconds, with Solana among the supported chains. This is not a demo that evaporates. It is a production-track payment surface for AI agents, and that is exactly why the cost question matters now rather than later.

The math at the thousandth payment

A thousand transactions a second is 86.4 million a day. On Solana the base fee is 5,000 lamports, about four hundredths of a cent at the SOL price in May 2026, so the chain fee alone runs into the tens of thousands of dollars a day and the low eight figures a year. That is before RPC, AWS markup, retries, observability, and the on-chain refund paths that do not exist the way card refunds do.

Under a second is the right answer to the wrong question (as of May 2026): AWS, Coinbase, and Stripe shipped an AgentCore Payments x402 preview on 7 May 2026 settling USDC on Base in about 200 milliseconds with Solana supported; a single x402 transfer clears in well under a second, which is the right frame for one payment crossing a trust boundary; a thousand payments a second is 86.4 million a day where the chain fee stacks up before anything else does; and on Solana the base fee alone runs into tens of thousands of dollars a day and a large share of a sub-cent agent API call.
The demo answers one payment. The fleet answers 86.4 million a day, and the chain fee is the first line item.
If an agent API call is worth a tenth of a cent, the chain fee underneath it is a large gross drag on the payment before RPC, retries, or observability are even counted.

Why the framing trap is expensive

The session answer was not wrong. It was scoped to a single payment, and a single payment is genuinely fast and cheap. The trap is carrying that number into a fleet design, where the same per-transaction fee that is invisible on one payment becomes the dominant cost across a million of them a day. A payment that is a rounding error in isolation is a budget line at scale, and the architecture decision, which chain and which settlement model, has to be made against the volume number, not the demo number.

Was this useful?

Choose once.

Filed under

Payments
Share
Back to Field Notes

Related Posts

View All Posts »
Spend limits are not delegated payment authority

Spend limits are not delegated payment authority

An invoice agent hits a transient timeout, retries, and two payments clear to the same vendor. The model calls it success. Ops calls it a week of cleanup. Spend limits and roles are a speed bump. Real delegated authority is a delegation object, policy on every attempt, ledger-bound idempotency, and an instant kill switch.

The hard part of payments is access, not the API

The hard part of payments is access, not the API

A payroll rollout taught me the friction is never the integration. It is funding caps, routing permissions, and what can clear directly versus what has to detour through a sponsor bank. That is why the Fed's new payment-account RFI matters - access is becoming a design decision, not just a policy one.

Sanctions screening as code: one policy, a different actuator per rail

Sanctions screening as code: one policy, a different actuator per rail

The payment is final in under a second and your sanctions analyst is still opening the alert. On an instant rail there is no review window, so the screen has to clear or stop the payment in code, inside the latency budget. The policy model can be common across rails. The action on a hit cannot, because RTP, the card networks, and SEPA Instant each demand a different commit semantic.

Payment modernization stalls at security review, not architecture

Payment modernization stalls at security review, not architecture

Payment modernization projects do not stall at the architecture layer. They stall at the security review layer - threat models built for monoliths, questionnaires written for general software, cycles tuned for annual releases. The teams that ship on time put security in the room before design, not after.