The demonstration landed on October 7, 2026, at Sui Basecamp. Peak throughput was recorded at 40,614,180 transactions per second inside offchain tunnels. That clears a 20 million target set for the event, and it sits well above a July run that landed near 6.1 million on the same kind of channel. Payments, games, and chat were the workloads. The tunnels themselves were opened on mainnet. The chatter inside them was not.
What 40.6 Million TPS Really Counts
Here is the part that gets lost in the headline. This was not a claim that the base chain cleared forty million user transfers in a single second. A tunnel needs an onchain transaction to open and another to close. Everything between those two bookends stays inside the channel. Participants can trade messages, settle micro-payments, update a game state, or ping a chat thread without posting each step to the ledger. When the tunnel closes, the result is cosigned and can be checked onchain.
I have found that this distinction matters more than the raw figure. A chain that posts every coffee purchase is solving a different problem from a channel that batches a thousand agent interactions and settles the net. Both can be honest. They are not the same product. Treating them as the same product is how throughput debates turn into shouting matches.
Adeniyi Abiodun, Mysten Labs co-founder and chief product officer, led the test. His line on stage is the cleanest summary of the thesis I have heard all year.
No market in the world needs 6 million transactions per second, let alone 40 million: people just don’t move that fast. Agents do.
Adeniyi Abiodun, on the October demonstration
That is not a modest claim. It is also not crazy, once you stop picturing humans tapping a buy button. An agent negotiating a content license, checking a paywall, retrying a failed micropayment, and updating a shared state can burn through interactions the way a trading bot burns through quotes. People pause. Software does not, unless you tell it to.
A quick map of the demo
If you only remember five facts from the event, make them these.
- Peak reading: 40,614,180 transactions per second inside the tunnels.
- Scale: more than 10,000 tunnels, opened on mainnet.
- Workloads: payments, games, and chat, meant to mimic agent traffic.
- Benchmark: a July test on the same channel style reached about 6.1 million.
- Review: CertiK was named as independent auditor, with a full write-up still pending.
The pending review is the adult part of the story. A live peak is a moment. A report that inspects proofs, execution logs, journals, and supporting evidence is what lets outsiders decide whether the moment was reproducible. Until that lands, I would treat 40.6 million as a demonstrated peak under the stated design, not as a settled industry standard.
Why the July number still matters
Jumping from roughly 6.1 million to 40.6 million in a few months is the sort of leap that makes engineers either lean in or reach for a red pen. Both reactions are fair. The tunnels were introduced in that earlier demonstration and described as programmable, which is a bigger deal than the speed bump. A pipe that only moves coins is a payment rail. A pipe you can program is an application runtime that happens to settle.
Perhaps the most interesting aspect is the shape of the improvement, not the multiple. Going from a first public showing to a stage demo with ten thousand tunnels suggests the team spent the summer on orchestration, not on a single heroic benchmark machine. Orchestration is boring. It is also what breaks in production. I would rather see a messy, multi-tunnel test than a pristine lab run on one box.
| Checkpoint | What was shown | What it does not prove |
| July channel test | About 6.1 million TPS, tunnels introduced | That every app type can hit that rate |
| October Basecamp demo | 40.6 million TPS, 10,000-plus tunnels | That mainnet consensus itself runs at that speed |
| Pending audit | CertiK named to review logs and proofs | Anything, until the report is public |
| Settlement step | Open and close hit the chain | That dispute cases are cheap at this scale |
Read that last row twice. Channels are wonderful until someone disagrees about the final state. The design says closed tunnels are cosigned and can be checked independently. That is the right sentence to write. The hard sentence is what happens when a signature is missing, a journal is partial, or an agent goes offline mid-session. Those cases do not show up in a peak-TPS slide. They show up on a Tuesday.
Offchain does not mean invisible
People hear offchain and picture a side room with no rules. That is not how this setup is being described. The channel is opened on the base network. Activity runs inside it. Closure returns a cosigned result that others can verify. Think of a bar tab. You do not swipe a card for every crisp. You open the tab, you drink, you close. The restaurant still has a record. The card network still sees the final charge.
The analogy breaks if the bar lets anyone rewrite the tab. Programmability is the feature and the risk in the same breath. Builders can put rules in the channel, which is exactly what you want for an agent that should only spend inside a budget. Builders can also put sloppy rules in the channel. Speed does not audit your logic. In my experience, the teams that get hurt are the ones who treat a fast pipe as a substitute for a narrow permission set.
How a single tunnel actually spends its life
Strip the stage lights off and a tunnel is a short story with three beats. Open. Work. Close. The open is an onchain transaction, so it pays whatever the base network charges and waits on whatever the base network needs for finality. The work is the loud part: payments hopping between participants, a game state ticking, a chat thread appending messages, an agent retrying a call that failed the first time. The close is another onchain transaction, cosigned, meant to be checkable by someone who was not in the room.
That rhythm is why the headline number and the chain’s everyday capacity are allowed to diverge. If ten thousand tunnels are open, and each one is buzzing, the aggregate of inner steps can look absurd next to the number of opens and closes. Absurd is fine, as long as you label it. I would rather a team print a huge inner number with a clear label than a modest number that quietly mixes two different layers.
- Open on mainnet, which fixes the participants and the rules of the channel.
- Run the noisy work offchain, where repeated steps do not each need a block.
- Close with a cosigned result that others can check against the journal.
Miss the middle label and you will argue with people who are describing a different machine. I have watched that argument eat entire panels. It is avoidable.
Agents are the customer, not the metaphor
The foundation framed the October run as infrastructure for rapid interactions between AI agents. Abiodun has described the network as plumbing for millions of agents transacting daily. You can roll your eyes at the phrasing. The underlying pattern is already visible in ordinary software: bots refreshing inventory, scripts reconciling invoices, assistants booking a thing and then booking the cancellation. Crypto just makes the payment leg native instead of rented from a card processor.
Last September, Sui showed up as a launch partner for an open standard from a major search company aimed at agents paying on a user’s behalf. The role described at the time was programmable payment infrastructure. Paywall access and automated purchases were the examples. Creators were supposed to set rules for how work gets used and get paid when those rules fire. Users were offered cryptographic identifiers and context wallets so an agent could act without a blank check on the person’s data.
I like the instinct. I do not like the blank-check version of it. An agent that can spend should have a ceiling, a merchant list, and a kill switch a human can find without a manual. Speed makes that more urgent, not less. Forty million inner transactions a second is a wonderful demo if the permission model is boring and tight. It is a headache if the permission model is a comment in a README.
Where the stablecoin fits
Throughput without a unit of account is a race car with no road. On March 4 the foundation launched USDsui, a dollar-linked asset issued through Bridge, a Stripe subsidiary, on its Open Issuance platform. The pitch included enterprise controls and compliance features. Wallets and financial apps on the network integrated it at launch. The stated uses ran from person-to-person payments and remittances to lending, trading, and liquidity.
For scale, the March materials pointed at more than $111 billion in stablecoin transfers on the network during January 2026. That figure is value moved in a month. The October figure is interactions per second inside tunnels. They answer different questions. One asks whether dollars already flow here. The other asks whether software can chatter fast enough to make those dollars feel instant. You want both if the agent story is real. Either one alone is a press release.
A small warning, because I have watched this movie. Stablecoin volume can be genuine commerce, and it can be the same dollars lapping the pool. A high transfer number is a clue, not a verdict. Pair it with who holds the asset, how long balances sit, and whether payments leave the ecosystem or circle it. The tunnel demo does not answer that. It does make the question sharper.
The U.S. on-ramp is already a product
Retail access in the United States did not wait for this demo. February coverage recorded staking products tied to SUI, with Canary Capital’s SUIS on Nasdaq and Grayscale’s GSUI on NYSE Arca. Both began trading on February 18 and held tokens directly rather than futures. Canary’s product stakes part or all of its holdings, with rewards inside net asset value. Grayscale’s was described with a 0.35 percent annual sponsor fee and with holdings staked at launch.
On July 22, Coinbase opened SUI staking for customers at a one-token minimum, with estimated annual rewards in a 1.4 to 3.3 percent band, availability depending on location. None of that is the throughput story. It is the distribution story. A fast channel matters more when ordinary accounts can already hold and stake the asset without a treasure map. It also means the audience for a sloppy headline is larger. People in a brokerage account do not parse “offchain tunnel” the way a protocol engineer does.
Two clocks, easy to mix up: Inner clock = steps inside an open tunnel Outer clock = opens, closes, and base-chain settlement Headline = inner clock, October 7 peak Investor path = token products and exchange staking, separate topic
What I would ask the auditor
CertiK’s job, as described, is to examine proofs, execution logs, journals, and supporting evidence, with a report expected in the days after the event. If I were reading that report with a pen, I would not start at the peak. I would start at the edges.
- Were the 10,000-plus tunnels comparable, or did a subset do almost all the work?
- How was a “transaction” defined inside a payment, a game tick, and a chat message?
- What hardware, network conditions, and client versions produced the peak second?
- How are partial failures recorded when a participant drops mid-channel?
- Can a third party recompute the closed state from the published evidence?
None of those questions are hostile. They are how you tell a demonstration from a capability. I have sat through enough benchmark days to know the peak second is the easy screenshot. The minute before and the minute after are the article.
A builder’s reading, not a trader’s
If you are shipping an app, the useful question is narrower than “is 40 million real.” Can you open a channel, stuff it with your own rules, and close it without babysitting every step? The foundation’s description says yes, and says the tunnels are programmable beyond simple transfers. Games and chat in the demo are a hint that the team wants state, not just balances.
That opens a design menu. A marketplace agent could negotiate inside the tunnel and settle once. A game could tick locally and checkpoint. A support bot could append a transcript and pay a creator when a licensed snippet is used. The constraint is the close. If your product needs the world to see every intermediate step, a channel is the wrong tool. If your product needs the world to see the outcome and the proof, a channel is the point.
There is a cultural tell I keep noticing. Teams that come from payments talk about the close. Teams that come from consumer apps talk about the middle, because that is where the feeling of speed lives. Both are right about their own job. The product fails when one side ships without the other. A silky middle with a clumsy close feels like a frozen checkout. A perfect close with a sluggish middle feels like a form from 2009.
The human speed limit is the whole argument
Abiodun’s line sticks because it is slightly rude to the industry’s favorite fantasy. We do not need a chain that can outrun a city of people tapping phones. We might need a channel that can outrun a city of agents refreshing state. I buy the distinction. I do not buy every use case glued onto it.
Chat at machine speed is mostly noise unless something economic is attached. Games at machine speed are a niche unless players care about the settlement. Payments at machine speed are the piece that generalizes, and only if the unit is stable, the fees on open and close stay dull, and a person can revoke the agent without filing a ticket. The demo bundled all three workloads. The one I would underwrite first is payments with a hard budget.
A fast channel is a tool. A fast channel with a vague mandate is a way to lose money quickly and in an organized fashion.
That is my line, not theirs. It still feels like the right footnote under the stage number.
How this sits next to ordinary chain metrics
Everyday blockchains get judged on a handful of public numbers: transactions included in blocks, time to finality, fee spikes when a mint hits, and whether a node you do not run can follow the chain. Channel systems add a second scoreboard. Inner throughput. Dispute cost. Exit time. Proof size. If you only publish the inner scoreboard, skeptics will assume the outer one is the embarrassment. Publishing both is how you retire that assumption.
Sui’s earlier public story has always leaned on parallel execution and a move toward high single-thread and multi-thread throughput on the base chain. This October result is a different instrument. Mixing the two in a marketing sentence is tempting and, in my view, a mistake. Let the base chain be the base chain. Let the tunnel be the tunnel. Readers who care can hold both ideas. Readers who do not will bounce off a blended claim anyway.
What could still go wrong
A few failure modes are obvious enough to name without pretending to have the logs.
- Definition drift. If a chat ping and a payment settle count as the same “transaction,” the headline is a blend, not a payment rate.
- Concentration. Ten thousand tunnels sound broad until you learn fifty of them produced the peak.
- Exit congestion. Opens and closes still hit mainnet. A rush for the door is a different test from a rush inside the room.
- Agent misbehavior. Software that can retry can also loop. Budgets have to live in the channel, not in a hope.
- Audit lag. A report “in the coming days” is a promise. The number is already in the wild.
None of these erase the demonstration. They decide how much weight a careful person puts on it before the write-up. I would put real weight on the architecture and provisional weight on the peak. That is not a dunk. It is how you stay interested without becoming a billboard.
A practical way to think about cost
Users do not buy TPS. They buy a feeling that a payment finished, and a bill that did not surprise them. Under this design, the expensive or slow steps are the ones that touch the chain. The cheap steps are the ones that stay in the tunnel. An agent that opens a channel in the morning, does a few hundred small things, and closes in the evening is a sane customer. An agent that opens and closes every second is a customer who did not read the manual.
So the product question hides inside the benchmark. Can builders keep sessions long enough that the inner rate matters? Payments and chat can. A one-shot transfer cannot, and should not pretend to. If the October workloads were session-shaped, the number is aimed at the right buyer. If they were a spray of tiny opens, the number is a stress test of coordination more than a preview of fees.
Session math, plain version:
inner steps stay cheap
open + close carry the chain cost
long session = headline speed becomes user speed
tiny session = you mostly pay the bookendsIdentity, budgets, and the uncomfortable part
The September partnership talk leaned on cryptographic identifiers and context wallets. Translated out of product language: the user should be able to prove who is allowed to spend, and the agent should carry only the slice of context it needs. That is the grown-up version of agent payments. The teenage version is an API key with a balance.
I keep coming back to revocation. Speed is a liability if you cannot stop it. A channel that can be closed by the human, not only by the agent, is the feature I would demo second, right after the peak. The October stage optimized for throughput. The next stage, if the team is listening to anyone who has been burned by automation, should optimize for a visible off switch.
There is also a creator side that gets less airtime. Programmed rules for licensing only work if the rule is legible. “Pay when used” is a slogan. “Pay this amount when this hash is accessed by this class of agent, then stop” is a product. Tunnels can host that logic. They do not write it for you. The teams that win this lane will be dull about permissions and loud about receipts.
Why the Singapore stage still counts
Live tests are theatre, and theatre is not worthless. Doing this in a room, with a named lead, a named auditor, and a number specific to the last digit, is a different posture from a PDF that says “up to.” You can still dispute the setup. You cannot claim nobody was willing to run it in public. That willingness is a tell about internal confidence, even before the report lands.
The jump past a self-imposed 20 million target is the other tell. Teams that fear their own demo pick a number they have already cleared in private. Clearing the advertised bar by about double suggests either a late optimization or a conservative target. Both are fine. The awkward outcome would have been a miss, explained later as a definition. They did not miss.
What changes for people who already hold the asset
Not much, this week. A tunnel benchmark does not rewrite staking yields, sponsor fees, or the path through a brokerage product. It does change the story you are underwriting if you bought the “agents will need a fast settlement venue” version of the thesis. That story just got a public data point. It did not get a customer count.
I would separate three piles on the desk. Pile one is technology: channels, proofs, the pending review. Pile two is money motion: the January stablecoin transfer figure, USDsui’s issuer setup, whether balances stick. Pile three is distribution: exchange staking, the February listed products, ordinary wallets. The demo only refreshes pile one. People who mash the piles together will overtrade a stage result. People who keep them apart can still be early without being careless.
A note on comparisons you will see online
Someone will put 40.6 million next to another chain’s peak and declare a winner. Save yourself the afternoon. Unless both numbers count the same kind of operation, on a comparable network, with a published method, the chart is decoration. Inner-channel steps are not block transactions. Block transactions are not payment finality. Payment finality is not agent-to-agent chatter. The sentence that respects the reader is the longer one.
The honest comparison inside this story is July against October, same channel family, same team, public both times. That comparison says the orchestration got much faster. It does not say every rival is behind on base-layer capacity. Different race. Different finish line. Mixing them is how comment sections go to die.
If you are deciding whether to build here
Wait for the audit if your app moves other people’s money. Read the channel rules if your app moves your own. Sketch the session length before you sketch the logo. A programmable tunnel is a fit for workflows with a beginning, a noisy middle, and a receipt. It is a poor fit for workflows that need every tick notarized for a regulator who has never heard the word tunnel.
Start with a budget cap you would be willing to explain to a customer. Then decide what “done” means when the agent crashes at step forty. Then, and only then, care about whether the inner loop can fly. Teams that reverse that order ship a demo and a support queue. I have watched the queue win.
The part worth keeping
Strip the confetti and the October demonstration says something simple. Sui opened a large set of mainnet tunnels, ran payment, game, and chat traffic inside them at a recorded peak of 40.6 million steps a second, beat its own event target, and beat its July channel result by a wide margin. An outside firm is supposed to inspect the evidence. Agents, not people, are the stated user. A dollar asset and U.S. staking products already exist around the token, which means the audience for this claim is no longer only developers.
I do not need the number to be the future of finance to find it useful. I need it to be labeled correctly. Offchain inner steps. Onchain bookends. Programmable rules. A report still owed. Hold those four and the headline becomes a tool instead of a slogan. Drop them and it becomes another figure that aged badly in a screenshot.
Would I build an agent payment flow on a channel like this? For a narrow budget and a session that closes on a schedule, yes, once the logs have a public referee. For an open-ended spender with a charming personality and no ceiling, not a chance. People do not move at forty million steps a second. Agents might. That is a reason to design the brakes before you admire the speed.
One last practical habit, if you cover this space or allocate in it. Write down what would change your mind. For me it is a report that defines the transaction, shows the tunnel distribution, and lets an outsider recompute a close. If that arrives and holds, the October peak graduates from stage craft to evidence. If it arrives and hedges, the architecture can still be interesting and the number should shrink back to a demo. Either outcome is better than arguing from a single integer.
The integer is 40,614,180. Remember the room it was counted in. The rest is the work.
]]>
