Aymen Gnaba

Posted on Oct 11

40 Million TPS, Rebuilt From the Chain

#blockchain #web3

What Sui's Basecamp record actually measured, reconstructed from mainnet settlement records.

TL;DR

I didn't wait for the audit. I found the contract behind Sui's 40,614,180 TPS record, pulled every settlement it wrote to mainnet, and rebuilt the throughput curve second by second. The chain gives a peak of 39.86 million TPS at 08:46:10 UTC on 7 October, within 2% of the official figure. The curve tracks the numbers called on stage to within a step.

So the number holds up. What it measures is more specific than "TPS":

One operator, scheduled waves. All 7,680 tunnels that produced the record were opened and funded by a single address and switched on in ten waves, every one a multiple of 256 tunnels. Each ran at about 5,230 offchain updates per second. 7,680 × 5,230 ≈ 40 million.
Sui anchored it; it didn't execute it. The live run's 15.2 billion offchain updates were committed through 11,502 mainnet transactions, for about 86 SUI of net gas.
Closing is where agents should look. Tunnels that ran closed onchain about 0.4 s after their last update. 593 tunnels whose counterparty never sent a single update were force-closed only after a fixed 3- or 6-hour window.

One image sums it up: a payment tunnel that made 3,132,986 transfers and closed with both sides holding exactly the 100 MTPS they started with.

What was claimed

The record closed Day 1 of Sui Basecamp on the Summit Stage, in a 4:35 pm session led by Mysten Labs co-founder and CPO Adeniyi Abiodun (Day 1 livestream, from about 5:35:00). He said he'd love to go "way past" 12 or 15 million, and noted the audience's median guess was 9.04 million. Then he called the counter as it climbed, and it passed 40 million.

The official write-up gives the details (Sui blog):

40,614,180 TPS, measured inside Sui tunnels: programmable offchain state and payment channels, similar to Lightning channels.
A tunnel takes two onchain transactions, one to open and one to close, and every closed tunnel is cosigned and verifiable onchain.
More than 10,000 tunnels opened on mainnet. CertiK will examine the proofs, logs and journals and publish a report.
The previous record was 6,086,766 TPS on 4 July, also measured inside tunnels (Sui blog).

On stage Abiodun called Sui "a trust plane for AI agents". In Sui's write-up he goes further: Sui doesn't need to process every agent interaction, it needs to be the trust layer for all of them. That is a testable claim, and the trust layer is a public chain, so I went and read it.

How I rebuilt it

I couldn't find a public tunnels SDK, but the event explorer is public. Its production build config names the contract it talks to: an arena-tunnel package at 0x9498…7eb1 on mainnet, published on 2 October, with a registry object and a test coin (MTPS) beside it. Everything after that is public chain data.

Crawl every event the package emitted through Sui's GraphQL endpoint: 43,327 tunnels created, 43,037 activated, 40,330 settled and 868 disputes opened between 2 and 9 October.
Read every settlement record. Each settled tunnel leaves a SettledOutcomeRecord holding a transcript_root (a commitment to every offchain step), a receipt_count, the final state, and the timestamp of the last offchain update.
Isolate the live run. Tunnel creations cluster in rehearsals on 4–6 October and at 12:03 SGT on the day. The live run is the burst at 16:41–16:48 SGT (08:41–08:48 UTC). 10,376 tunnels were created in the hour around it; 8,657 settled, and 7,680 of those actually ran.
Rebuild the curve. Each tunnel's receipts are spread evenly between its activation and its last offchain update, then summed per second.

Step 4 is an assumption, so I checked it. Across the 7,680 tunnels that ran, throughput is almost flat: a median of 5,231 receipts per second, a 99th percentile of 5,933. When every tunnel runs at nearly the same constant rate, spreading receipts evenly loses very little.

The other 977 settled tunnels closed with zero receipts. 384 of them also report a final timestamp that isn't a real time (random-looking 64-bit values), so I left them out of the curve; their nonces add up to just 260,358 updates, under 0.01% of the total.

What the chain shows

The rebuilt curve peaks at 39,862,531 TPS at 08:46:10 UTC, 1.85% under the official 40,614,180. Since my curve averages each tunnel over its whole session, a small gap from a live counter is expected. The climb is the more convincing part. The orange dots are the numbers called on stage, placed by stream time, and they sit on or next to the steps of a curve built only from settlement records. There is one free parameter: I pinned the stream clock to the final "40 million" call, and the other dots fall where they fall.

The run held above 20 million for about 6.5 minutes and near its peak for about 2.5. It unwound in steps as tunnels closed; the last running tunnel finished at 08:53 UTC.

Live run, 7 Oct (08:30–09:30 UTC)	Value
Tunnels created	10,376
Tunnels settled	8,657
Tunnels that ran (produced receipts)	7,680, all two-party
Offchain receipts committed	15.24 billion
Mainnet transactions carrying the package's events	11,502
Net gas, storage rebates included	85.74 SUI
Addresses that opened and funded the 7,680 running tunnels	1
Addresses that opened the 977 zero-receipt tunnels	81
Addresses that activated tunnels	2

Across every rehearsal and the live run, the package has committed 117.4 billion offchain receipts.

By receipts, the live run was 79.0% simple_payments, 10.8% flash (the explorer's chat messages, as far as I can tell), 4.0% tic_tac_toe, 3.4% battleship and 2.8% tunnels whose outcome is a pair of chip stacks, likely the card tables.

Where 40 million comes from

effective TPS ≈ tunnels running × updates per tunnel per second = 7,680 × ~5,230 ≈ 40 million

Each tunnel is two parties exchanging signed state updates as fast as they can. Nothing inside a single tunnel touches consensus, so the headline number is set by how many tunnels run at once.

The activations show how that number was built. The 7,680 running tunnels went live in ten waves between 08:41:52 and 08:46:04 UTC: 256, 256, 256, 512, then four waves of 1,280, then 1,024 and 256. Each wave is a step in the chart. Every activation was sent by one of two addresses.

That is what horizontal scaling looks like: throughput grows linearly with concurrent channels, and the base layer only has to keep up with opening and closing them. It also means "40 million" is a statement about capacity, not demand.

What the number is not

Sui's write-up is clear that the count was measured inside tunnels. Three things follow from the data that are easy to lose when the number travels on its own.

It is not base-layer TPS. During the run, the stage commentary compared the counter with Visa and then described Sui's roughly 120 validators as able to process transactions faster than centralized systems. The validators processed the 11,502 transactions that opened, funded, activated and settled the tunnels. The 15.2 billion updates ran between the two parties of each tunnel.
It is not 40 million payments. A receipt is a signed state update, not value moved. Of the 6,144 live payment tunnels, 3,080 closed with both balances exactly where they started, 100 MTPS each. One of them did so after 3,132,986 transfers (settlement record). Netting is the whole point of a channel; it means what settles on Sui is the net, not the count.
It is not the audience. Abiodun said around 10,000 people on the stream were participating, and the public did open tunnels: 977 of them, from 81 addresses. None of those produced receipts. Every update in the record came from the 7,680 agent pairs opened by one address, which is the scenario the test was built to show.

None of this makes the record fake. It makes it precise: Sui anchored 15.2 billion offchain updates, produced at a peak of about 40 million per second, for 86 SUI of gas.

What matters if you build agents

I build bounded agent wallets: onchain spending limits that hold even when the agent's reasoning doesn't. From that seat, the most useful data in this run isn't the peak. It is how tunnels end.

When both sides are there, closing is instant. All 7,680 running tunnels settled onchain a median of 0.43 seconds after their last offchain update (90th percentile 0.64 s, worst 1.2 s). None of them was disputed.

When one side never shows up, money waits. 593 tunnels were opened, funded and activated, but the counterparty never sent a single update. The runtime opened a dispute on each, typically within about 18 seconds. Each then settled exactly 3 hours (526 tunnels) or 6 hours (67) after the dispute opened, which looks like a fixed challenge window. Nothing was lost; it was locked. For an agent, a counterparty that goes silent is the realistic failure, so budgets and timeouts have to be sized for that window, not the 0.4-second median.

The same package also ships two modules the run never used: agent_allowance (a principal funds an escrow and names a payee and a delegate, with a per-second rate, a spend cap, an expiry, pause and revoke) and streaming_payment. Neither has emitted an event. Tunnels for speed plus a bounded allowance for authority looks like the next step.

The other two Basecamp announcements fill in the rest of the stack:

Layer	Sui piece	State today
Authority: what may the agent spend?	Sui Agent Payments grants: allowed services, total budget, per-payment cap, expiry, enforced onchain at settlement. Supports MPP and x402; the agent rail currently advertises MPP	Testnet; paid calls invite-only; directory and dashboard "coming soon". Alibaba Cloud services are to plug in, with no date, pricing or service list yet (BeInCrypto)
Throughput: how fast can two agents transact?	Tunnels: about 5,230 updates per second per pair, committed by a transcript root	Demonstrated on mainnet; no public SDK that I could find
Evidence: can a third party check what happened?	Verifiable Agent Arbiter with Google Cloud: logs private in the customer's storage, proofs on Walrus, coordinated on Sui; disputes replayed over A2A	Announced 6 October; initial enterprise deployments first, no customers named

The interesting part is the seam between the rows. A grant caps spend per payment, but inside a tunnel a payment is one of millions of signed updates. Where a grant's limits bind on a tunnel, at open, per update or at close, is the design question I'd most like answered.

Questions for the CertiK report

The chain already confirms the headline. These are the questions it can't answer on its own.

What exactly is one transaction? On 38,243 of 40,330 records, receipt_count equals the final nonce, so one receipt is one state transition. Is that what was counted, and over what sampling window was 40,614,180 measured?
Can anyone check a transcript? Each settlement commits a transcript_root. Will the offchain journals be published so a third party can recompute a few roots, rather than trust the counts?
Why did no public tunnel run? The 977 tunnels the public opened all closed with zero receipts, and 384 of them carry a final timestamp that isn't a real time. Was that by design, or a capacity limit on the day?
Is the challenge window configurable? Idle tunnels were force-closed after exactly 3 or 6 hours. What will an agent integration be able to set it to?
Was the runtime attested? The package includes a Nitro-enclave attestation registry, but every live settlement record has evidence_class 0. If that means no attestation, it is worth saying, because it bears on how much the runtime has to be trusted.

Reproduce it

Everything above comes from public mainnet data and runs with Python's standard library (the chart needs matplotlib), no wallet or API key. The scripts are at github.com/Makabeez/sui-40m-tps-rebuild.

Arena-tunnel package: 0x9498606724aa4c03dd0e50ce508b3f5555c4915d3f8d0d4525c0f98dd1737eb1 (modules anchor, outcome_records, ownership, agent_allowance, streaming_payment, attestation_registry, and wire formats)
Registry 0x11c05904ca67cea5658d5bc2a0a0171eafb5d1649bd4f3cd81392b2d11ea571d; test coin 0xcb913929…3eedcd::mtps::MTPS
Endpoint: https://graphql.mainnet.sui.io/graphql, crawled 10 October 2026

crawl_events.py pulls every anchor::ArenaTunnel* event.
fetch_records.py reads each SettledOutcomeRecord.
analyze.py isolates the live run and rebuilds the per-second curve.
footprint.py counts every transaction carrying the package's events (funding included), its sender and gas, and the settlement lag.

If CertiK's numbers differ from mine, I'll post the diff.

DEV Community