DEV Community: Aymen Gnaba

40 millions de TPS, reconstruits depuis la chaîne

Aymen Gnaba — Sun, 11 Oct 2026 17:17:52 +0000

Ce que le record de Sui à Basecamp a réellement mesuré, reconstruit à partir des règlements inscrits sur le mainnet.

En bref

Je n'ai pas attendu l'audit. J'ai retrouvé le contrat derrière le record de 40 614 180 TPS annoncé par Sui, récupéré chaque règlement qu'il a inscrit sur le mainnet, et reconstruit la courbe de débit seconde par seconde. La chaîne donne un pic de 39,86 millions de TPS à 08:46:10 UTC le 7 octobre, à moins de 2 % du chiffre officiel. Et la courbe suit, à une marche près, les chiffres annoncés sur scène.

Le record tient donc. Mais ce qu'il mesure est plus précis que « des transactions par seconde » :

Un seul opérateur, des vagues planifiées. Les 7 680 tunnels qui ont produit le record ont tous été ouverts et financés par une même adresse, puis activés en dix vagues, chacune un multiple de 256 tunnels. Chacun tournait à environ 5 230 mises à jour hors chaîne par seconde. 7 680 × 5 230 ≈ 40 millions.
Sui a ancré l'activité, il ne l'a pas exécutée. Les 15,2 milliards de mises à jour hors chaîne du run ont été engagées via 11 502 transactions mainnet, pour environ 86 SUI de gas net.
C'est à la fermeture qu'un agent doit regarder. Les tunnels actifs ont été réglés onchain environ 0,4 s après leur dernière mise à jour. 593 tunnels dont la contrepartie n'a jamais envoyé une seule mise à jour n'ont été clôturés de force qu'après une fenêtre fixe de 3 ou 6 heures.

Une image résume tout : un tunnel de paiement qui a enchaîné 3 132 986 transferts, et s'est refermé avec exactement les 100 MTPS de départ de chaque côté.

Ce qui a été annoncé

Le record a clôturé la première journée de Sui Basecamp, sur la Summit Stage, lors d'une session de 16 h 35 menée par Adeniyi Abiodun, cofondateur et CPO de Mysten Labs (livestream du jour 1, à partir d'environ 5:35:00). Il espérait dépasser largement 12 ou 15 millions, et a rappelé que la médiane des pronostics du public était de 9,04 millions. Puis il a commenté le compteur en direct, jusqu'au passage des 40 millions.

Le compte rendu officiel donne les détails (blog Sui) :

40 614 180 TPS, mesurés à l'intérieur des tunnels Sui : des canaux d'état et de paiement hors chaîne, programmables, proches des canaux Lightning.
Un tunnel coûte deux transactions onchain, une à l'ouverture et une à la fermeture, et chaque tunnel fermé est cosigné et vérifiable onchain.
Plus de 10 000 tunnels ouverts sur le mainnet. CertiK examinera preuves, logs et journaux avant de publier un rapport.
Le record précédent, 6 086 766 TPS le 4 juillet, avait aussi été mesuré dans des tunnels (blog Sui).

Sur scène, Abiodun a présenté Sui comme un « plan de confiance » pour les agents IA. Dans le blog, il va plus loin : Sui n'a pas besoin de traiter chaque interaction entre agents, il doit être la couche de confiance de toutes. C'est une affirmation vérifiable. Et comme cette couche de confiance est une blockchain publique, je suis allé la lire.

Comment je l'ai reconstruit

Je n'ai pas trouvé de SDK public pour les tunnels, mais l'explorateur de l'événement est public. Sa configuration de production nomme le contrat auquel il parle : un package « arena tunnel » à l'adresse 0x9498…7eb1 sur le mainnet, publié le 2 octobre, accompagné d'un registre et d'un jeton de test (MTPS). Tout le reste, ce sont des données publiques de la chaîne.

Récupérer chaque événement émis par le package via l'endpoint GraphQL de Sui : 43 327 tunnels créés, 43 037 activés, 40 330 réglés et 868 litiges ouverts entre le 2 et le 9 octobre.
Lire chaque enregistrement de règlement. Chaque tunnel réglé laisse un SettledOutcomeRecord qui contient un transcript_root (un engagement sur chaque étape hors chaîne), un receipt_count, l'état final et l'horodatage de la dernière mise à jour hors chaîne.
Isoler le run en direct. Les créations de tunnels se regroupent en répétitions du 4 au 6 octobre et à 12 h 03 heure de Singapour le jour J. Le run en direct, c'est la salve de 16 h 41 à 16 h 48 (08:41–08:48 UTC). 10 376 tunnels ont été créés dans l'heure qui l'entoure ; 8 657 ont été réglés, et 7 680 ont réellement tourné.
Reconstruire la courbe. Les reçus de chaque tunnel sont répartis uniformément entre son activation et sa dernière mise à jour, puis additionnés seconde par seconde.

L'étape 4 repose sur une hypothèse, alors je l'ai vérifiée. Sur les 7 680 tunnels actifs, le débit est presque constant : une médiane de 5 231 reçus par seconde, un 99e centile de 5 933. Quand tous les tunnels tournent à un rythme quasi identique, la répartition uniforme ne coûte presque rien.

Les 977 autres tunnels réglés se sont fermés avec zéro reçu. 384 d'entre eux affichent en plus un horodatage final qui n'est pas une heure réelle (des valeurs 64 bits apparemment aléatoires) ; je les ai exclus de la courbe. Leurs nonces cumulés ne représentent que 260 358 mises à jour, moins de 0,01 % du total.

Ce que montre la chaîne

La courbe reconstruite culmine à 39 862 531 TPS à 08:46:10 UTC, soit 1,85 % sous les 40 614 180 officiels. Ma courbe lisse chaque tunnel sur toute sa session, donc un petit écart avec un compteur en direct n'a rien d'étonnant. La montée est plus parlante encore : les points orange sont les chiffres annoncés sur scène, placés selon l'horloge du stream, et ils tombent sur les marches, ou juste à côté, d'une courbe construite uniquement à partir des règlements. Un seul paramètre libre : j'ai calé l'horloge du stream sur l'annonce finale des « 40 millions », les autres points tombent où ils tombent.

Le run est resté au-dessus de 20 millions pendant environ 6 min 30, et proche du pic pendant environ 2 min 30. Il est redescendu par paliers à mesure que les tunnels se fermaient ; le dernier tunnel actif s'est arrêté à 08:53 UTC.

Run en direct, 7 oct. (08:30–09:30 UTC)	Valeur
Tunnels créés	10 376
Tunnels réglés	8 657
Tunnels ayant tourné (avec reçus)	7 680, tous à deux parties
Reçus hors chaîne engagés	15,24 milliards
Transactions mainnet portant les événements du package	11 502
Gas net, remboursements de stockage inclus	85,74 SUI
Adresses ayant ouvert et financé les 7 680 tunnels actifs	1
Adresses ayant ouvert les 977 tunnels à zéro reçu	81
Adresses ayant activé des tunnels	2

Répétitions comprises, le package a engagé au total 117,4 milliards de reçus hors chaîne.

En nombre de reçus, le run se répartit ainsi : 79,0 % simple_payments, 10,8 % flash (les messages du chat de l'explorateur, a priori), 4,0 % tic_tac_toe, 3,4 % battleship et 2,8 % de tunnels dont le résultat est une paire de piles de jetons, probablement les tables de cartes.

D'où viennent les 40 millions

TPS effectifs ≈ tunnels actifs × mises à jour par tunnel et par seconde = 7 680 × ~5 230 ≈ 40 millions

Chaque tunnel, ce sont deux parties qui s'échangent des mises à jour d'état signées aussi vite que possible. Rien à l'intérieur d'un tunnel ne passe par le consensus : le chiffre affiché dépend donc du nombre de tunnels qui tournent en même temps.

Les activations montrent comment ce nombre a été construit. Les 7 680 tunnels actifs ont été allumés en dix vagues entre 08:41:52 et 08:46:04 UTC : 256, 256, 256, 512, puis quatre vagues de 1 280, puis 1 024 et 256. Chaque vague correspond à une marche du graphique. Toutes les activations ont été envoyées par l'une de deux adresses.

C'est exactement à ça que ressemble un passage à l'échelle horizontal : le débit croît linéairement avec le nombre de canaux simultanés, et la couche de base n'a qu'à suivre le rythme des ouvertures et des fermetures. Cela veut aussi dire que « 40 millions » mesure une capacité, pas une demande.

Ce que le chiffre n'est pas

Le compte rendu de Sui précise bien que le comptage a eu lieu à l'intérieur des tunnels. Mais trois choses ressortent des données, et elles se perdent facilement quand le chiffre circule seul.

Ce ne sont pas des TPS de couche de base. Pendant le run, le commentaire sur scène a comparé le compteur à Visa, puis décrit les quelque 120 validateurs de Sui comme capables de traiter les transactions plus vite que des systèmes centralisés. Les validateurs ont traité les 11 502 transactions qui ont ouvert, financé, activé et réglé les tunnels. Les 15,2 milliards de mises à jour, elles, ont circulé entre les deux parties de chaque tunnel.
Ce ne sont pas 40 millions de paiements. Un reçu est une mise à jour d'état signée, pas un transfert de valeur. Sur les 6 144 tunnels de paiement du run, 3 080 se sont refermés avec les deux soldes exactement à leur niveau de départ, 100 MTPS chacun. L'un d'eux après 3 132 986 transferts (enregistrement de règlement). La compensation est la raison d'être d'un canal ; cela signifie que ce qui est réglé sur Sui, c'est le solde net, pas le compteur.
Ce n'est pas le public. Abiodun a évoqué environ 10 000 personnes connectées au stream et participant, et le public a bien ouvert des tunnels : 977, depuis 81 adresses. Aucun n'a produit de reçu. Toutes les mises à jour du record viennent des 7 680 paires d'agents ouvertes par une seule adresse, ce qui est précisément le scénario que le test voulait démontrer.

Rien de tout cela ne rend le record faux. Cela le rend précis : Sui a ancré 15,2 milliards de mises à jour hors chaîne, produites à un pic d'environ 40 millions par seconde, pour 86 SUI de gas.

Ce qui compte quand on construit des agents

Je construis des wallets d'agents bornés : des plafonds de dépense onchain qui tiennent même quand le raisonnement de l'agent ne tient plus. Vu d'ici, la donnée la plus utile de ce run n'est pas le pic. C'est la façon dont les tunnels se terminent.

Quand les deux parties sont là, la fermeture est instantanée. Les 7 680 tunnels actifs ont été réglés onchain en médiane 0,43 seconde après leur dernière mise à jour hors chaîne (90e centile 0,64 s, pire cas 1,2 s). Aucun n'a fait l'objet d'un litige.

Quand une partie ne se présente jamais, l'argent attend. 593 tunnels ont été ouverts, financés et activés, mais la contrepartie n'a jamais envoyé une seule mise à jour. Le runtime a ouvert un litige sur chacun, en général dans les 18 secondes. Chacun a ensuite été réglé exactement 3 heures (526 tunnels) ou 6 heures (67) après l'ouverture du litige, ce qui ressemble à une fenêtre de contestation fixe. Rien n'a été perdu ; tout a été bloqué. Pour un agent, la panne réaliste est une contrepartie qui se tait : budgets et délais doivent être dimensionnés pour cette fenêtre, pas pour la médiane de 0,4 seconde.

Le même package embarque aussi deux modules que le run n'a jamais utilisés : agent_allowance (un mandant finance un séquestre et désigne un bénéficiaire et un délégué, avec un débit par seconde, un plafond de dépense, une expiration, une pause et une révocation) et streaming_payment. Aucun n'a émis le moindre événement. Des tunnels pour la vitesse et une allocation bornée pour l'autorité : cela ressemble à la prochaine étape.

Les deux autres annonces de Basecamp complètent la pile :

Couche	Brique Sui	État aujourd'hui
Autorité : que peut dépenser l'agent ?	Les autorisations de Sui Agent Payments : services autorisés, budget total, plafond par paiement, expiration, appliqués onchain au règlement. Compatible MPP et x402 ; le rail agent annonce actuellement MPP	Testnet ; appels payants sur invitation ; annuaire et tableau de bord « bientôt ». Les services d'Alibaba Cloud doivent s'y brancher, sans date, tarif ni liste de services pour l'instant (BeInCrypto)
Débit : à quelle vitesse deux agents transigent-ils ?	Les tunnels : environ 5 230 mises à jour par seconde et par paire, engagées par une racine de transcription	Démontré sur le mainnet ; pas de SDK public à ma connaissance
Preuve : un tiers peut-il vérifier ce qui s'est passé ?	Le Verifiable Agent Arbiter avec Google Cloud : journaux privés dans le stockage du client, preuves sur Walrus, coordination sur Sui, litiges rejoués via A2A	Annoncé le 6 octobre ; premiers déploiements en entreprise d'abord, aucun client nommé

Le plus intéressant, c'est la jointure entre les lignes. Une autorisation plafonne chaque paiement, mais dans un tunnel, un paiement n'est qu'une mise à jour signée parmi des millions. Où les limites d'une autorisation s'appliquent-elles sur un tunnel : à l'ouverture, à chaque mise à jour ou à la fermeture ? C'est la question de conception à laquelle j'aimerais le plus une réponse.

Questions pour le rapport CertiK

La chaîne confirme déjà le chiffre principal. Voici ce qu'elle ne peut pas trancher seule.

Qu'est-ce qu'une transaction, exactement ? Sur 38 243 des 40 330 enregistrements, receipt_count est égal au nonce final : un reçu correspond donc à une transition d'état. Est-ce bien ce qui a été compté, et sur quelle fenêtre d'échantillonnage les 40 614 180 ont-ils été mesurés ?
Peut-on vérifier une transcription ? Chaque règlement engage un transcript_root. Les journaux hors chaîne seront-ils publiés, pour qu'un tiers puisse recalculer quelques racines au lieu de faire confiance aux compteurs ?
Pourquoi aucun tunnel du public n'a-t-il tourné ? Les 977 tunnels ouverts par le public se sont tous fermés avec zéro reçu, et 384 portent un horodatage final qui n'est pas une heure réelle. Choix de conception ou limite de capacité ce jour-là ?
La fenêtre de contestation est-elle configurable ? Les tunnels inactifs ont été clôturés après exactement 3 ou 6 heures. Quelle valeur une intégration d'agent pourra-t-elle choisir ?
Le runtime était-il attesté ? Le package contient un registre d'attestation pour enclaves Nitro, mais chaque règlement du run porte evidence_class 0. Si cela signifie « pas d'attestation », mieux vaut le dire : cela change le degré de confiance à accorder au runtime.

Reproduire l'analyse

Tout ce qui précède vient de données publiques du mainnet et tourne avec la bibliothèque standard de Python (le graphique demande matplotlib), sans wallet ni clé d'API. Les scripts sont sur github.com/Makabeez/sui-40m-tps-rebuild.

Package arena tunnel : 0x9498606724aa4c03dd0e50ce508b3f5555c4915d3f8d0d4525c0f98dd1737eb1
Registre 0x11c05904ca67cea5658d5bc2a0a0171eafb5d1649bd4f3cd81392b2d11ea571d ; jeton de test 0xcb913929…3eedcd::mtps::MTPS (0 décimale)
Endpoint : https://graphql.mainnet.sui.io/graphql, données récupérées le 10 octobre 2026

Si les chiffres de CertiK diffèrent des miens, je publierai l'écart.

Sources

40 Million TPS, Rebuilt From the Chain

Aymen Gnaba — Sun, 11 Oct 2026 17:16:41 +0000

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.