Eleven million verified payment updates in a single second sounds like marketing until you sit with the number. That is not a theoretical whiteboard claim. It is a measured path through software that is supposed to let an AI agent buy a slice of compute, a window of tokens, or a data lookup the moment it needs it. I have watched throughput announcements come and go. This one is interesting because it does not pretend the base chain itself just became a firehose.
What The 11 Million Figure Actually Measures
Polygon Labs ran an agent pay channel benchmark across 25 independently scaling hubs. The headline result was more than 11 million verified payment updates per second. Final settlement stayed anchored to Polygon Chain. That last sentence matters more than the first. Individual payments never had to fight for a block. They moved through channels. The chain recorded accumulated state later.
The design target is software that pays as it works. Inference. Data. API calls. Small units, repeated often. If every unit became its own onchain transfer, fees and congestion would eat the product before it shipped. So the team split the job. Fast confirmation lives offchain. Money still starts and ends onchain.
A Session Starts With Escrow, Not A Checkout Page
An agent pay channel begins when a payer deposits funds into a vendor-agnostic channel contract on Polygon and binds a session key. The deposit sets the spend ceiling for that session. No prepaid account at every vendor. One locked pot. Many possible providers.
When a service wants money, it uses x402. That protocol turns HTTP’s old 402 “Payment Required” status into a machine-readable price request. The agent answers with signed cumulative vouchers through a hub. The hub checks the signature, the price, a replay ID, the authorization ceiling, and remaining escrow. If the math holds, it returns a receipt. The provider can then release the next unit of work.
A valid receipt is the green light. The next token window, data result, or API response only moves after the payment engine says the voucher is good.
I like that split. x402 handles the “how much and why now” conversation over the web. The channel handles the grind of repeated micro-updates and the later batch. Two jobs. Two tools. Less confusion about what belongs on a public ledger in real time.
How The Test Was Built, Layer By Layer
The architecture was tested against an OpenRouter-style inference API on a live devnet. A signed payment fired for every 100-token window. Polygon said the payment path was real. The inference provider itself was a stand-in. Fair enough. You can still learn a lot from a honest stand-in if the signatures, receipts, and hub logic are not fake.
Results changed with how much of the stack sat in the loop.
| Test path | What sat in the loop | Observed rate |
| Full x402 path | Agent, site, facilitator, and hub | About 40,000 payments per second |
| Full path volume check | Same stack, counted receipts | 2.4 million payments, 100% success |
| Engine on one box | One 24-core server, engine only | 533,000 to 536,000 verified payments per second |
| Distributed hubs | 25 hubs, 16 vCPUs each | More than 11 million updates per second |
Each engine confirmation landed in about 20 microseconds, not counting network latency between the user and the hub. That is the kind of number operators quote when they want you to stare at silicon instead of mempools. Fine. Just keep the latency caveat in view. The internet still exists.
Why Hubs Do Not Need A Group Chat
Polygon said hubs partition payers. They do not coordinate with each other while payments are flying. That is the scaling trick. Add a hub, add capacity. Based on the 25-hub run, the company estimates a larger fleet could clear more than 100 million payment updates per second.
Is that estimate a straight line? Maybe too straight. Hardware, geography, key management, and messy real users will bend the curve. Still, the core claim is not wild: if hubs do not wait on each other during the hot path, horizontal growth is at least plausible.
- Payers get assigned so one hub owns a slice of live traffic.
- Verification stays local to that hub during the session.
- Coordination waits for settlement, not for every voucher.
- Capacity is a fleet problem more than a consensus problem.
Participants also choose when accumulated payments settle. After one payment. After 50,000 updates. After 100 million. The service configuration decides. That flexibility is the quiet part of the story. High frequency does not force high onchain noise if the operator is willing to wait for an epoch.
Settlement Is A Merkle Root, Not A Parade Of Transfers
Instead of posting every payment to Polygon, a hub batches accumulated state and publishes an epoch Merkle root. Providers prove what they earned against that root and claim funds. Deposited money never left the chain’s security model. Only the chatter left the chain.
People will still tweet that “Polygon did 11 million TPS.” They will be wrong. The chain did not process 11 million onchain transactions per second. Offchain channels did the updates. Batches hit the ledger later. If you care about honest metrics, say it that way every time.
In my experience, that distinction is where reader trust lives. Inflated TPS headlines age badly. Precise wording ages well.
The Cost Line That Will Get Screenshotted
The benchmark configuration put processing cost for one billion payment updates at about $0.15. That figure will travel. It should travel with context. It is a processing cost under the tested setup, not a promise that mainnet chaos, fiat ramps, and legal work cost fifteen cents at planetary scale.
Even so, the direction is the point. Agent workloads are chatty. If the meter for a billion tiny confirmations is not catastrophic, product teams can design around usage instead of around fear of the fee ticker.
x402 Is Spreading Faster Than One Chain
Polygon’s test lands in a season when x402 is showing up across ecosystems. Stablecoins have carried most of the measured volume in some datasets. One large issuer reported that USDC made up 99.3% of the x402 payment volume it tracked in the second quarter. That slice was their window, not the entire agent-payments universe. Still, it tells you where liquidity currently sits.
Other networks are not sitting still. Cardano added x402 to its software stack so developers can wire agents that pay with ADA and native tokens. Early TypeScript work ran on a preproduction environment. Commercial mainnet scale was not the claim. Block joined the x402 Foundation and contributed Lightning support, which gives builders a Bitcoin-side option next to the stablecoins that have dominated activity. The foundation cited 75.41 million transactions and $24.24 million in volume over a recent 30-day window. Ripple’s side of the map showed AI agents generating more than 1.4 million transactions on its ledger by July, with work on rails for XRP and a dollar-linked token.
Perhaps the most interesting aspect is not who “wins x402.” It is that the request format is becoming a shared dialect. Agents can shop. Services can price. Wallets and hubs can settle in different venues without inventing a new handshake every week.
Where This Fits Polygon’s Payments Push
Agent pay channels are meant to plug into Polygon’s Open Money Stack: the kit for moving funds into apps, holding them, applying spend rules, and settling leftover value. Through 2026 the network has leaned hard into stablecoins and institutional settlement. PayPal USD became native on Polygon in July through that stack, sitting next to wallets, fiat ramps, and compliance tools. The network had already settled more than $2.6 trillion in stablecoin transactions by that point, according to the lab’s own tally.
Block times were cut to an average of 1.75 seconds in May. Theoretical onchain throughput was pegged around 3,260 transactions per second. That is a serious payments chain by yesterday’s standards. It is still not 11 million anything. Channels exist because those two worlds should not be forced into the same queue.
Channel model in plain language: Lock funds onchain Stream signed updates offchain Publish a root Let providers prove and claim
The product pitch is simple enough. Charge per API call, per token, per lookup, per finished task. Let an agent hop providers without opening a fresh prepaid tab everywhere. I have found that prepaid tabs are where experiments go to die. Nobody wants eighteen tiny balances and a reconciliation spreadsheet.
What An Agent Actually Buys In This World
Think less “shopping cart” and more “meter.” A model asks for the next hundred tokens. A data shop meters a query. A tool vendor meters a function call. The human never sees a checkout modal if the software is doing its job. That is the whole mood.
- Service states a price over HTTP with x402.
- Agent signs a cumulative voucher against remaining escrow.
- Hub verifies and issues a receipt in microseconds.
- Work is released. State accumulates.
- An epoch root lands on Polygon. Claims follow.
Does that feel like finance or like infrastructure? Both. The money is real. The rhythm looks like systems engineering. If you only think in candles and narratives, this will feel dry. If you build products that burn tokens by the minute, it will feel overdue.
The Honest Limits Nobody Should Soft-Pedal
Devnet is not mainnet traffic. A stand-in inference provider is not a hostile vendor. Partitioned hubs assume operational discipline. Session keys can be stolen. Replay protection has to stay boring and correct. Batch settlement introduces delay between work done and cash in hand. Some providers will hate that delay. Some payers will love it.
There is also the human layer. Autonomous software that spends money will attract the same problems autonomous software always attracts: bad prompts, runaway loops, vendors who overcharge by a fraction that adds up, and regulators who ask who is the customer when the customer is a script.
I would not bet the company on a single benchmark week. I would watch whether real providers accept receipts as enough to keep the lights on. Receipts are easy. Collections are the adult part.
Why Offchain Updates Still Need A Serious Chain
Critics sometimes shrug at payment channels as “not blockchain.” That shrug misses the custody and dispute surface. Funds are locked in a contract. Settlement roots are public. Claims are provable. If a hub vanishes, the design still has to answer who can recover what. That answer is why the base chain is not optional window dressing.
Polygon’s payments story over the past year has been about making that base layer feel closer to card rails: faster blocks, stablecoin depth, business tooling. Channels then sit on top like an express lane for chatty agents. The express lane is useless if the garage underneath cannot hold the cars.
Millions of updates do not have to compete for the same onchain slots. They only need a trustworthy place to start and a trustworthy place to finish.
A Few Practical Questions For Builders
If you are shipping an agent product, the interesting questions are operational, not poetic.
- How large should a session deposit be before top-ups become annoying?
- How often should a vendor demand settlement so cash flow does not stall?
- Who runs the hub, and what happens if that operator goes dark?
- Which asset does the agent hold when prices and refunds get messy?
- How do you pause a runaway spender without killing a live task?
Those are unglamorous. They are also the difference between a demo and a bill people will pay. Throughput without answers here is just a lab photograph.
What I Think Comes Next
More hubs will be the easy forecast. The harder forecast is marketplace behavior. Agents will comparison-shop latency and price. Vendors will start quoting in smaller units because the rails can meter them. Some will over-fragment and confuse users. Some will land on clean packages: a dollar of inference, a dime of search, a cent of storage write.
Stablecoins will likely keep dominating the first wave because agents need boring units of account. Lightning-style options and native chain tokens will show up where communities already live. That mix is healthy. A single rail for every robot on earth is a fantasy, and not a pretty one.
Will 100 million updates per second appear in a public fleet tomorrow? I doubt it. Could a production cluster beat today’s 11 million with more of the same architecture? That is the bet Polygon is telegraphing. Watch the first non-stand-in providers, not the next press number.
A Ground-Level Read For People Who Just Want The Plot
Polygon showed that agent-style micropayments can be verified at machine speed if you stop putting every sip of value on a block. Twenty-five hubs carried more than eleven million updates a second. The chain kept the money and the final score. x402 asked for payment. Channels did the repetition. Roots closed the books.
If that sounds modest compared with the headline, good. Modest systems that settle real dollars tend to outlast loud systems that settle narratives. The next test is not another core count. It is whether an agent can finish a messy multi-vendor job, pay as it goes, and leave every party able to prove who owes whom when the dust settles.
That is the part I want to see in the wild. The lab already made its noise. Now the receipts have to mean something when nobody is watching the benchmark clock.
