What Polygon reported
On September 24, Polygon announced agent pay channels for high-frequency, usage-based payments. A payer funds a multi-use channel and binds a session key. As a service delivers work, the agent sends signed cumulative payment updates through a hub; the hub verifies the signature, price, replay identifier, authorization ceiling, and remaining escrow before returning a receipt. The hub later batches state into an epoch Merkle root on Polygon, where providers can prove and claim earnings.
Polygon reports that a live-devnet test of the full x402 path processed 2.4 million payments at roughly 40,000 payments per second with 100% success. An engine-direct test on one 24-core server reached 533,000–536,000 verified updates per second, while 25 independently scaling 16-vCPU hubs exceeded 11 million updates per second. Polygon explicitly says the headline result measures offchain hub processing, not 11 million onchain transactions per second. These are Polygon-reported results; the operational conclusions below are Ineeza analysis.
Payment throughput and settlement throughput are different systems
Ineeza analysis: moving each usage event offchain is the architectural reason the benchmark can scale. It also creates two clocks: rapid service-release decisions based on hub receipts, and slower financial finality based on an onchain root and claim. Product ledgers must record both states explicitly. “Authorized,” “hub accepted,” “root committed,” and “provider claimed” are not interchangeable outcomes.
A production integration should preserve the voucher, session identity, cumulative amount, price version, service unit, hub receipt, epoch, root transaction, and claim result under one idempotency key. Reconciliation then compares at least the service-usage ledger, channel state, hub epoch, and onchain claims. Without that evidence, a fast receipt path can hide value leakage, duplicate service delivery, or stranded provider balances.
The hub is a low-latency trust boundary
Ineeza analysis: the hub verifies a consequential decision before the provider releases work, so its failure semantics matter as much as its benchmark speed. Operators need to define who runs each hub, how payer partitions are assigned, what software and policy version produced a receipt, how keys are protected, and how equivocation or an unavailable hub is detected. A Merkle root makes later claims provable; it does not by itself prove that every valid update was included promptly or that the service response matched what was purchased.
Providers should set bounded exposure between root commitments, verify monotonic cumulative amounts and epoch membership independently, and stop delivery when receipt evidence is stale or inconsistent. Recovery needs a tested path for the last accepted voucher, disputed inclusion, root rollback, hub replacement, and channel closure. Horizontal scale reduces coordination on the hot path but increases the operational inventory that must be observed and upgraded safely.
Session keys need policy beyond a balance cap
Ineeza analysis: a funded channel and session key reduce checkout friction, but available balance is not sufficient authorization for an autonomous agent. The key should be constrained by provider, service, asset, unit price, cumulative and time limits, allowed network, and purpose. Price terms must be bound to the signed update so that a compromised service or confused agent cannot convert permission for one API call into permission for another charge.
Agents also retry. A timeout after payment acceptance but before service delivery can produce either unpaid work or double payment unless payment and service identifiers are idempotent across both sides. For higher-risk tasks, spending policy should remain outside the model loop, with deterministic checks and human escalation thresholds before a session key signs.
Benchmarks need an end-to-end production envelope
Ineeza analysis: the 11 million figure is useful evidence about horizontally partitioned verification capacity, but capacity planning should start with the full-path result and then measure the intended deployment. Network distance, signature mix, policy lookup, persistence, observability, root construction, chain congestion, claim load, and failure recovery can all become the limiting stage.
Teams should publish separate service-level objectives for receipt latency, acceptance correctness, root publication, claim finality, and reconciliation lag. Load tests should include skewed payer partitions, exhausted balances, replay attempts, price changes, key revocation, hub loss, chain reorganization, and repeated claims—not only valid updates distributed evenly across hubs.
Ineeza’s view
Polygon’s design is material because it makes per-call and streaming agent payments plausible without treating every usage event as an onchain transaction. The production lesson is not that settlement constraints disappear; they move into a layered protocol. A durable implementation treats the hub receipt as provisional service authorization, the onchain root as settlement evidence, and reconciliation as the control that proves the two stayed aligned.