#Sui创4060万TPS纪录 The first thing I checked was “what exactly is being counted?” In its official announcement on October 7, Sui reported 40,614,180 TPS, measured at Basecamp in Singapore. But this throughput came from off-chain activity in Sui tunnels, with the results settled on the mainnet. Treating it directly as the number of transactions confirmed one by one per second by the mainnet consensus layer would give readers a different understanding of its performance.
As of 12:38 p.m. Beijing time on October 8, the original timeline I could verify for this round is: the experiment reached 6,086,766 TPS on July 4, and an introduction was published on July 17; on October 7, the 40.61 million result was announced. Both measurements were taken within channels, so they can be used to describe improvements in this testing framework, but not to rank Sui directly against another chain by mainnet transaction counts.
I. Separate interactions, execution, and settlement
The process described by the project is as follows: open a channel on-chain, complete multiple state or payment interactions within the channel, then submit a settlement when closing it. The mainnet anchors the final state and proof; each action within the channel does not need to be written individually to global consensus. It is like submitting the final ledger for a series of transactions to a settlement layer: the number of interactions and the number of final submissions are naturally different metrics.
This kind of design has value: high-frequency machine interactions do not have to incur the same on-chain write costs for every step. But both “happens off-chain” and “can ultimately be verified on-chain” should be made clear; we should not report only the larger number. A peak figure also does not, by itself, answer questions about duration, failure rates, or congestion when channels are closed.
II. Do not conflate verification progress with a final conclusion
The October 7 announcement named CertiK as the independent auditor and said it would review materials such as proofs and execution logs, with a report to be published in the coming days. I have not yet been able to verify a complete public report for this test. So I am citing the results announced by the project; I am not portraying on-site verification as an independent recalculation by me, or describing a planned report as already completed.
The most important things to look for next are the measurement window, counting rules, how successes and failures are handled, and the settlement evidence after channels are closed. If any of these criteria change, the same TPS figure could mean something different.
III. How can performance capacity translate into real demand?
Sui’s September 2 article on machine payments also emphasized atomic settlement and constrained authorization: a multi-step process either completes as a whole or is not submitted, and an agent’s spending amount, time, and recipient also need limits. I think this explains why real-world applications cannot focus only on the number of actions. A large volume of automated interactions may be no more useful simply because they are faster if permissions are not controllable and settlements cannot be verified.
For the SUI asset, demonstrated throughput cannot be converted proportionally into revenue, token purchases, or a price target. Next, I will look at whether sustained usage, actual payments, and settlement demand keep pace before judging whether the technical results generate economic value. My conclusion today is that the measurement scope has been explained, while commercial adoption and the complete test report still need further verification.
As of 12:38 p.m. Beijing time on October 8, the original timeline I could verify for this round is: the experiment reached 6,086,766 TPS on July 4, and an introduction was published on July 17; on October 7, the 40.61 million result was announced. Both measurements were taken within channels, so they can be used to describe improvements in this testing framework, but not to rank Sui directly against another chain by mainnet transaction counts.
I. Separate interactions, execution, and settlement
The process described by the project is as follows: open a channel on-chain, complete multiple state or payment interactions within the channel, then submit a settlement when closing it. The mainnet anchors the final state and proof; each action within the channel does not need to be written individually to global consensus. It is like submitting the final ledger for a series of transactions to a settlement layer: the number of interactions and the number of final submissions are naturally different metrics.
This kind of design has value: high-frequency machine interactions do not have to incur the same on-chain write costs for every step. But both “happens off-chain” and “can ultimately be verified on-chain” should be made clear; we should not report only the larger number. A peak figure also does not, by itself, answer questions about duration, failure rates, or congestion when channels are closed.
II. Do not conflate verification progress with a final conclusion
The October 7 announcement named CertiK as the independent auditor and said it would review materials such as proofs and execution logs, with a report to be published in the coming days. I have not yet been able to verify a complete public report for this test. So I am citing the results announced by the project; I am not portraying on-site verification as an independent recalculation by me, or describing a planned report as already completed.
The most important things to look for next are the measurement window, counting rules, how successes and failures are handled, and the settlement evidence after channels are closed. If any of these criteria change, the same TPS figure could mean something different.
III. How can performance capacity translate into real demand?
Sui’s September 2 article on machine payments also emphasized atomic settlement and constrained authorization: a multi-step process either completes as a whole or is not submitted, and an agent’s spending amount, time, and recipient also need limits. I think this explains why real-world applications cannot focus only on the number of actions. A large volume of automated interactions may be no more useful simply because they are faster if permissions are not controllable and settlements cannot be verified.
For the SUI asset, demonstrated throughput cannot be converted proportionally into revenue, token purchases, or a price target. Next, I will look at whether sustained usage, actual payments, and settlement demand keep pace before judging whether the technical results generate economic value. My conclusion today is that the measurement scope has been explained, while commercial adoption and the complete test report still need further verification.
