On September 24th, Polygon announced the test results of Agent Pay Channels: A cluster composed of 25 independent Hub processed over 11 million verified payment updates per second; a single Hub reached approximately 533,000 to 536,000 updates per second under direct engine connection, and the complete x402 network test resulted in about 40,000 updates. These figures are aimed at the high-frequency, small-amount payments handled by AI proxies. However, it's important to clarify that these statistics refer to off-chain payment channel updates, not the 11 million independent transactions confirmed per second on the Polygon main chain.

When using the proxy purchase model Token, for data queries and tool calls, the billing unit can be as small as a single request or 100 Token. If each such small unit were directly sent to the blockchain, the resulting delays and transaction fees would make the model unusable. The Polygon approach is to first lock the funds in a channel, with the proxy continuously sending cumulative signature credentials. Hub then verifies the amount and signatures, and finally, a batch of transactions is settled onto the blockchain using Merkle. The speed is achieved by separating the payment flow from the final settlement.

11 million represents the parallel verification capability of 25 Hub. The final settlement will still be conducted in batches on the blockchain.

The process begins with pre-stored funds. The payer deposits the funds into a channel contract that is not bound to a single merchant and associates it with a session key. The server expresses the price and payment requirements through x402, and issues cumulative vouchers when acting as an agent for consumption services. Hub checks the signature, price, replay number, authorization limit, and remaining managed balance; upon successful verification, a receipt is returned, and then the service provider releases the next segment of model output, data, or tool results.

Hub will submit the cumulative status in batches to Polygon, where service providers can claim their earnings as proof. Participants can choose the settlement pace based on risk and cost: they can settle after each update, or they can accumulate up to 50,000 updates or more before settling. Frequent small updates mainly occur at the channel and Hub levels, while the main chain is responsible for fund custody and the finality of the batches. Therefore, it is inaccurate to describe the test results as "the Polygon chain TPS has reached 11 million."

Test conditions also need to be preserved. The results of 11 million tests come from 25 Hub clusters, with each cluster consisting of 16 vCPU; Hub are partitioned by payer, and there is no need for coordination between them in the payment process, allowing for horizontal scaling. The 530,000 tests in a single Hub cluster involve direct connections to the engine, while the complete x402 chain includes approximately 40,000 tests, which encompasses proxies, sites, facilitators, and Hub, and is thus closer to a real-end-to-end process.

Polygon claims that the complete system processed a total of 2.4 million payments with a 100% success rate. The test object was an inference system that mimicked OpenRouter, with a payment triggered every 100 Token. The payment process was real, and the inference provider served as a substitute implementation. This experiment proved that the architecture can operate under development network conditions and set loads, but it does not guarantee that it will maintain the same throughput in a production environment facing attacks, network fluctuations, or different merchants.

After micro-payments move away from prepaid accounts, the new point of trust shifts to Hub and settlement rules.

The current API service often requires users to pre-recharge. Funds are locked in multiple merchant accounts in advance, which also limits agents from being able to temporarily choose a more suitable service due to existing balances. The goal of the multi-merchant channel is to allow agents to use the same managed funds to purchase different services as needed, with payments occurring as work progresses, rather than dispersing the funds before the services are used.

Convenience does not eliminate risks; it merely shifts their location. The theft of session keys may lead to the misuse of funds within the allocated limit; Hub verification errors or system downtime can disrupt services; service providers' acceptance rules for receipts, dispute resolution, and settlement delays can also affect the overall experience. Contract hosting provides a balance boundary, but it does not automatically determine whether the quality of a model's output meets standards.

The participants also need to design for replay protection, key rotation, quota revocation, and fault recovery. Accumulated credentials usually only record the latest total amount, which can reduce the number of states, but it requires both parties to properly handle old credentials and concurrent requests. If a proxy calls multiple tools simultaneously, how to avoid exceeding the authorized balance, and how to maintain consistency during Hub switches, are all issues that need to be verified in production deployment.

The cost figures also pertain to the baseline environment. Polygon states that processing 1 billion payment updates consumes approximately 0.15 US dollars, which is mainly based on the calculations of Hub and should not be interpreted as the total cost of 1 billion mainchain transactions. Hardware, network, operations, monitoring, liquidity, and the final fees for on-chain transactions will still be included in the business bill. Large-scale services also require anti-DDoS capabilities and auditable logs.

Polygon indicates that this set of capabilities will be integrated with a broader range of Open Money Stack in the future. The mention of "will be integrated" in the announcement refers to a roadmap plan, and not all OMS customers have automatically obtained this feature yet. Developers can currently contact the team to explore potential integration channels, but the actual scope of availability, service level, and pricing will still need to be confirmed according to the product development stages.

The truly valuable aspect of this test is that it breaks down the issue of the scale of AI proxy payments into two layers: high-frequency signature updates are handled by horizontally scalable infrastructure, while less frequent fund settlements are entrusted to the blockchain. 11 million transactions per second demonstrate the upper limit of off-chain verification, but this is not a myth about the performance of the main chain. In the future, to determine its success, we will need to look at real merchant adoption, end-to-end latency, failure rates, and fund security, rather than just the highest throughput in the laboratory.