Reading the receipts: what Sui's 40.6M TPS record actually left on-chain

Reading the receipts: what Sui’s 40.6M TPS record actually left on-chain

An independent on-chain reconstruction of the 7 October 2026 Basecamp throughput test. Data pulled from Sui mainnet on 11 October 2026. All scripts and raw data are published alongside this piece: data, scripts, how to reproduce.

By @SherkhanMM · 12 October 2026

On 7 October, at the Summit Stage session “Break the World Record: Sui’s TPS” (16:35 Singapore time), Sui announced that its programmable tunnels had processed 40,614,180 transactions per second, settled to mainnet, with CertiK named as the independent auditor. The headline travelled fast. The question of what it measures travelled slower.

Tunnels are off-chain channels: only opening and closing touch the base layer, so the figure can’t be read off a block explorer. But every closed tunnel leaves a settlement record on-chain, and those records say a great deal. I pulled every tunnel event, transaction and settlement record for 7 October and the rehearsal days before it.

Short version:

1. What was claimed, and by whom

Sui’s announcement says users and AI agents opened “more than 10,000” tunnels across chat, games and payments. It also says each closed tunnel is “mutually cosigned and independently verifiable onchain”, and that CertiK will examine “proofs, execution logs, journals and supporting evidence” and publish a report “in the coming days”. The announcement doesn’t define a transaction, and it doesn’t give the averaging window.

The event explorer linked from that announcement (tps.dopamint.fun) answers both points. It serves a public JSON endpoint, /v1/live/benchmark-report, and I saved a snapshot of it on 11 October at 20:05 UTC. The snapshot shows:

field value
peak_tps_15s 40,614,179.67
peak_tps_60s 40,357,075.62
moves_total 50,287,038,349
peak by workload (15 s) simple_payments_v3 34.28M, flash_v1 (chat) 4.26M, tic_tac_toe_v3 3.01M, battleship_v3 1.26M, blackjack_v3 1.09M, quantum_poker_v3 0.55M

So the headline is the best 15-second average of a counter the operator calls moves, and about 84% of the peak came from one simple-payments workload. Keep that in mind: everything below compares on-chain data with this counter.

2. Method

Contracts. I took the package IDs from the explorer’s public JavaScript bundle: the tunnel package 0x9498…7eb1 (modules anchor, attestation_registry, outcome_records, ownership, receipt_wire, signature, terminal_wire, and others) and the event token MTPS (0xcb91…edcd::mtps::MTPS). The full IDs are in the appendix.

Data. For on-chain data I used only the public Sui GraphQL endpoint (graphql.mainnet.sui.io): no private indexer and no API key. The pull covers:

Reproducibility. Every on-chain number in this article is computed by scripts/analyze.py into data/findings.json. The fetchers can resume after an interruption, and their output is de-duplicated by transaction digest. The README lists the exact commands.

3. The tunnels: two bursts, one address

chart-1

On 7 October, 19,423 tunnels were created and 17,393 settled. Every tunnel had exactly two seats. Activity came in two sharp bursts:

run bench tunnels opened (activations) all bench tunnels open settlements
Midday, 12:03–12:16 SGT 04:03:19–04:11:21 UTC 24 s 04:11:45–04:16:05 UTC
Stage, session at 16:35 SGT 08:41:52–08:46:09 UTC 151 s 08:48:40–08:53:07 UTC

The stage run matches the 16:35 SGT session slot, and (section 5) the operator’s 60-second peak.

Who opened them. One address, 0x490d…40b3, created 15,852 of the day’s 19,423 tunnels (81.6%). In every one of them it funded both seats and was the beneficiary of both (31,704 funding events, one source). It paid its own gas, opened tunnels in batches of eight and settled them itself. On-chain this is a load generator, not a user. I call it the bench, the same word the operator’s evidence API uses (published-by: "app" | "bench").

The other (“app”) tunnels pair a real wallet with a house address (0xae8c…835e). On 7 October 114 distinct wallets funded app seats, gas-sponsored by 0x8f5d…c6c3. That is the “gasless” part of the announcement.

“More than 10,000 tunnels within seconds.” Between 16:35 and 17:00 SGT, 10,104 tunnels were created: 7,680 bench and 2,424 app (85 wallets). The busiest 60 seconds saw 4,267 creations. The fastest any 10,000 were created was 966 seconds. So “more than 10,000” holds for the session, but “within seconds” doesn’t match the on-chain timestamps.

Opened but not closed. Of the session’s 2,424 app tunnels, 309 settled cooperatively, 592 were force-closed after a three-hour dispute timeout, and 1,523 were still open on 11 October. Every bench tunnel settled.

4. What a settlement record contains

Each settlement creates an immutable (frozen) SettledOutcomeRecord. Its fields are tunnel_id, execution_id, execution_manifest_digest, participant_set_digest, protocol_id, protocol_version, product_manifest_digest, resolution_policy_digest, disposition, terminal_nonce, terminal_timestamp, terminal_state_commitment, transcript_root, receipt_count, outcome, entitlements, total_settled, settled_at_ms and evidence_class.

Two of these matter most:

The sums tell the story:

  tunnels settled 7 Oct sum of terminal_nonce
bench 15,852 28,775,092,181
app 1,541 (919 cooperative + 622 force-closed) 700,003

A bench tunnel committed a median of 1.77 million moves (10th–90th percentile 0.82M–2.76M). An app tunnel committed a median of 200.

A useful cross-check: the operator’s moves_total (50,287,038,349) matches the on-chain sum of terminal_nonce for everything settled since 6 October (50,297,836,942) to within 0.02%. The operator’s counter and the chain agree on the count. What remains open is what a single “move” consists of.

5. Reconstructing the peak from the chain

chart-2

A record says how many moves a tunnel made, not when. Two things can still be computed.

A floor. The stage run committed 15,241,348,297 moves within 675 seconds (first activation to last settlement). So at least one 60-second window carried ≥ 21.2M moves/s, if you accept the counts.

An even-rate model. Assume each bench tunnel moved at a constant rate between on-chain activation and on-chain settlement. Summing the 7,680 tunnels second by second gives a plateau of 39,811,565 moves/s for the 151 seconds when all were open (08:46:09–08:48:40 UTC). That is 2.0% below the claimed 15-second peak and 1.4% below the 60-second peak. The model is conservative: a tunnel stops moving before its settlement lands, so true rates are higher.

The arithmetic is simple. The median bench tunnel ran at ≈5,225 moves per second, and 7,680 × 5,225 ≈ 40.1M. The headline is parallelism times a per-channel rate: 7,680 two-seat channels, each doing about 5,000 state updates per second.

The model also tells the runs apart. In the midday run all bench tunnels overlapped for only 24 seconds, so its best 60 seconds reconstruct to 37.7M, too low for the published 60-second peak of 40.36M. The stage run gives 39.8M for both windows, so it is the likely source of the record.

Rehearsals. The same bench ran the same configuration five times:

run (first activation, UTC) bench tunnels moves committed reconstructed 15-s peak median moves/s per tunnel
4 Oct 13:06 5,880 25.5B 23.9M 5,010
5 Oct 02:47 7,680 41.3B 38.5M 5,158
6 Oct 07:57 7,680 21.5B 39.2M 5,202
7 Oct 04:03 7,680 12.9B 39.6M 5,215
7 Oct 08:41 (stage) 7,680 15.2B 39.8M 5,225

chart-4

Rehearsing a benchmark is normal, but it changes the reading: the 40.6M figure came from a scripted load test whose level had already been reached in rehearsal, not from organic demand peaking on stage. The operator’s counter appears to have been reset before the 6 October run, so the 5 October rehearsal (41.3B moves) isn’t part of moves_total.

6. What the base layer did meanwhile

chart-3

From 16:35 to 17:00 SGT, Sui mainnet executed 161,242 transactions: 107.5 TPS on average. Its busiest 60 seconds reached 158.9 TPS, its busiest 10 seconds 195.9 and its busiest single second 437.8. Tunnel-contract transactions made up 12,082 of them (7.5%). For the whole day the network averaged 112.0 TPS, against 102.5 on 6 October and 132.7 on 8 October. Over 7 October the tunnel contract accounted for 0.22% of all transactions.

The claimed off-chain peak is therefore about 256,000 times the busiest minute of the base layer during the session. That isn’t a criticism, since moving work off the base layer is the point of channels. But the two numbers measure different things. Sui mainnet did not process 40 million transactions per second. The announcement never said it did, but headlines like “Sui Network Hits 40.6 Million TPS Record” invite that reading.

7. What the on-chain footprint cost

Gas on Sui is computation plus storage minus storage rebates. Deleting an object refunds most of its storage deposit, and freezing one locks the deposit for good.

  transactions net gas
Stage-run bench (16:35–17:00 SGT) 4,800 (960 each: registry, key registration, create, fund/activate, settle) 99.23 SUI ≈ $113
All tunnel-contract transactions in the session 12,082 131.1 SUI ≈ $149
All tunnel-contract transactions, 7 Oct 21,350 242.6 SUI ≈ $275

Prices are CoinGecko hourly: $1.1395 at 08:00 UTC and a day average of $1.1323.

That works out to 0.0129 SUI (≈$0.015) per bench tunnel, ≈3.2 million off-chain moves per on-chain transaction, and $0.0074 per million moves. Batching eight tunnels per transaction means the bench used 0.625 transactions per tunnel, below the “two per tunnel” in the announcement. Settlement transactions paid 84.1 SUI in storage fees and recovered 144.4 SUI in rebates from the deleted tunnel objects. The frozen records keep their deposit permanently.

What moved inside the tunnels was MTPS, an event token with zero decimals that the deployer can mint through mtps::admin_mint. Bench seats deposited 100 MTPS (a few 2,000), and app seats deposited 1, 100 or 1,000. In the bench tunnels the same address sat on both sides, so no value changed owners.

8. What the chain actually verifies

I read the bytecode of anchor::settle_cooperative_local, the function behind all 16,771 cooperative settlements that day. It checks four things:

  1. the evidence class is admitted (assert_admitted_evidence_class; every record that day has evidence_class = 0, the “local” class);
  2. the terminal state is well formed, its payouts add up to the escrow (assert_conserves), and its nonce isn’t lower than any state already committed on-chain (assert_settlement_admissible);
  3. every seat signed the settlement digest (verify_every_seat);
  4. those seat keys are registered in a LocalEvidence attestation registry (assert_cooperative_signers_registered_local).

It does not re-execute any moves, check them, or recount them. terminal_nonce and receipt_count are numbers that both seat keys signed. Two facts about this deployment matter here:

So the chain shows that two keys agreed on a final count, and, for bench tunnels, that both keys were registered by the party that ran both seats. It doesn’t show that the moves happened. That gap is what a third-party audit of the transcripts has to close.

The evidence archive. The explorer has a public evidence endpoint for each tunnel. For 24 of the 25 cooperative app tunnels I sampled, it returned closure manifests with transcript artifacts, averaging about 2.3 KB per move. For all 31 bench tunnels I sampled it returned HTTP 502 manifest-too-large. At the same encoding, the stage run alone would be roughly 35 TB. That is an extrapolation, not a measurement, but it shows the scale of “examining the journals”.

9. Tunnels vs Lightning: where the trust sits

  Lightning channel Sui tunnel (as deployed on 7 Oct)
Funding 2-of-2 multisig output on Bitcoin Shared Move object with an escrow balance, funded per seat
What updates off-chain Balance commitments Arbitrary programmable state (payments, games, chat) under a product manifest
Who can close Either party, cooperatively or unilaterally Cooperative (all seats sign), dispute and timeout, or a referee if one is declared
Cheating defence Penalty: an old state lets the counterparty take everything, enforced by Bitcoin script and timelocks Dispute window (3 h) in which a newer signed state can be adopted; optional referee key
Arbiter None; the script is the judge The Move contract plus an optional referee; “court” in Mysten’s wording
Routing Multi-hop via HTLCs None observed; each tunnel is a closed set of seats
What the chain proves at close Final balances signed by both parties Final state, count and transcript root signed by all seats; the transcript stays off-chain

What tunnels add is programmability: the same escrow-and-signature pattern can carry a poker hand or a chat session as well as a payment. The trust question is the same as for Lightning. Off-chain throughput only means something if the parties are independent and each one can enforce its view on-chain. Between two keys held by one operator, any number of moves per second is a matter of CPU, not of consensus. For agent-to-agent commerce, where the parties are genuinely independent, the design is promising. The 7 October benchmark simply wasn’t that setting.

10. CertiK status

As of 11 October 2026: CertiK’s blog listing (latest entries 8 October) has no post on Sui tunnels. Sui’s announcement carries no update or link, and a news search found no report. Some coverage says CertiK verified the figure “in real time”, but the published material describes a report still to come. Until it appears, the record is an operator measurement that the on-chain data makes plausible.

When it does appear, these questions will show whether it closes the gap:

  1. What exactly is one move? Is every move signed by both seats, or only checkpoints? Signing every move would mean about 81M signatures per second at peak.
  2. Were both seat keys of each bench tunnel held by one process or machine?
  3. Can a third party recompute receipt_count and transcript_root from published transcripts?
  4. Why did the run use the local, untrusted attestation profile instead of the Nitro path in the same package?
  5. What hardware produced the moves, and how many machines?

11. Limitations

12. Conclusion

The on-chain data neither debunks the 40.6M figure nor confirms it independently. What it shows is narrower and more useful. The settlement records carry the counts, and the counts reproduce the claim to within 2%. They match the operator’s counter to 0.02%. They show that the throughput came from a rehearsed benchmark in which one address ran 7,680 channels, each at about 5,000 updates per second, and that the chain checked signatures, not work. The design’s real test is still ahead: tunnels between parties who don’t trust each other, settled with keys the chain has reason to trust. Until the CertiK report is out, “40.6M TPS” is best read as “7,680 self-owned channels at ~5k updates per second each, with the counts publicly committed”.

Appendix: identifiers and reproduction

Independent analysis from public data. Not investment advice.

Code in scripts/ — MIT licence. Text, charts and derived tables — CC BY 4.0.