TON a-t-il un mempool ? Ce que l'on voit avant un bloc

Posez la question « TON a-t-il un mempool ? » dans un chat de développeurs et vous obtiendrez deux réponses assurées. La première : « Non, TON n'a pas de mempool. » La seconde : « Si, voici une transaction pending de toncenter. » Les deux ont raison sur un point. TON n'a pas de pool unique de transactions non confirmées, partagé par tout le réseau, que chaque nœud conserverait et sur lequel tous s'accorderaient, comme dans Bitcoin. Mais un message existe bel et bien avant d'entrer dans un bloc, les nœuds le voient, et quelques API permettent de regarder dans cette fenêtre.

Cet article explique ce que le mot signifie sur TON, pourquoi « pending » chez toncenter est une émulation, ce qu'un flux de messages d'avant-bloc peut et ne peut pas vous dire, et comment fonctionne le flux mempool de TONNode, limites d'abord.

Ce que « mempool » signifie sur TON

Sur Bitcoin ou Ethereum, le mempool est un objet concret : chaque nœud complet garde un ensemble de transactions non confirmées, le diffuse à ses pairs, et les producteurs de blocs y puisent, généralement selon les frais.

TON part d'une autre unité. Un utilisateur n'envoie jamais de « transaction ». L'application wallet signe un message externe et le remet à un nœud. Selon docs.ton.org, « les messages externes sont envoyés depuis l'extérieur de la blockchain et n'ont donc qu'une adresse d'expéditeur externe facultative ». Le contrat destinataire, qui pour un utilisateur est le contrat du wallet, vérifie la signature et le numéro de séquence, appelle ACCEPT, et c'est seulement alors qu'une transaction naît : « lorsqu'un message externe entrant est traité, une transaction n'est créée que si le contrat accepte le message ».

Trois conséquences en découlent, et elles expliquent pourquoi « le mempool de TON » est une expression approximative plutôt qu'un objet du protocole.

• Il n'y a rien pour enchérir. Un message externe ne porte aucun paiement de son expéditeur. Le contrat de destination paie le gaz après avoir accepté, sur un crédit de gaz qui lui permet d'abord d'inspecter le message. Aucune file n'est ordonnée par prix, parce que le message n'a pas de prix.
• Il n'y a pas de file unique. TON est shardé : un compte appartient à la shardchain dont le préfixe ouvre son adresse, et un message adressé à un wallet n'intéresse que les nœuds qui produisent les blocs de ce shard. Un nœud qui reçoit un message externe le diffuse dans l'overlay public, et la documentation note que « les validateurs les partagent entre eux et peuvent le livrer plusieurs fois, par accident (ou intentionnellement) ». Chaque nœud garde ce qu'il a entendu ; il n'existe d'ensemble convenu nulle part.
• Un message rejeté ne laisse aucune trace. Si le contrat n'accepte pas, parce que la signature est fausse, que le seqno a déjà servi, que valid_until est dépassé ou qu'il n'y a pas de solde pour payer, aucune transaction n'est créée et aucun bloc n'enregistre la tentative.

Alors, quand quelqu'un dit « mempool de TON », la traduction honnête est : les messages externes qu'un nœud a reçus et diffusés, et qu'aucun bloc n'a encore inclus. C'est une fenêtre de quelques secondes, elle diffère d'un nœud à l'autre, et une partie de son contenu ne s'exécutera jamais. Cette fenêtre, c'est ce qu'un flux mempool vous montre.

Pourquoi « pending » chez toncenter est une émulation

L'API v3 de toncenter propose GET /api/v3/pendingTransactions, documenté comme « interroger les transactions pending correspondant aux filtres indiqués », par compte ou par trace id. Sa Streaming API livre des événements avec un champ finality valant pending, confirmed ou finalized, et définit le premier niveau avec précision : « pending — résultat d'une émulation ou d'une exécution spéculative. Cet état peut être invalidé. »

Une transaction pending chez toncenter n'est pas repêchée dans la file d'un nœud. L'indexeur prend le message externe, l'exécute contre l'état courant du compte comme le ferait un validateur, et publie la transaction prédite et les actions qu'elle produirait. Quand le vrai bloc arrive, l'événement est réémis en confirmed, puis en finalized ; quand la prédiction se révèle fausse, une notification trace_invalidated suit. Les abonnements sont par adresse : l'opération subscribe du WebSocket prend une liste addresses qui « peut rester vide seulement pour un abonnement à un trace, et est obligatoire pour les autres types d'événements ».

C'est excellent pour la question que posent la plupart des produits : le paiement de mon utilisateur est-il passé, et puis-je l'afficher une seconde plus tôt ? Ce que cela ne donne pas, c'est le flux brut du réseau avant le bloc, chaque message de chaque wallet, avant toute émulation. Ce sont deux produits différents.

Ce qu'un flux mempool TON peut et ne peut pas montrer

Un flux mempool est l'autre produit : un nœud qui relaie les messages externes à l'instant où il les entend. Avant de construire dessus, les limites comptent plus que les fonctionnalités. Celles-ci viennent de la section « qualité des données » de la documentation du mempool.

La couverture est partielle. Le flux porte ce qu'un nœud reçoit de l'overlay public. Un message qui n'atteint jamais ce nœud n'est pas dans le flux, et l'absence dans le flux ne prouve rien. TONNode ne publie aucun chiffre de complétude ni de vitesse et ne prétend pas être le premier.

Pending ne veut pas dire inclus. Un message checked a passé les vérifications de diffusion du nœud, pas l'exécution du validateur. Dans un échantillon de 90 minutes d'octobre 2026, environ un message checked sur cinq n'a jamais été accepté sur la chaîne.

Les messages précoces ne sont pas vérifiés. Le hook le plus précoce du nœud s'exécute avant sa vérification de signature à la diffusion, là où n'importe quel pair de l'overlay peut injecter des octets. Le flux les livre comme "path":"early","unverified":true, par défaut, parce que pour certains usages l'avance compte plus que la certitude. Tout ce qui agit automatiquement envoie "include_unverified":false ou attend la copie checked portant le même cell_hash.

parsed est fait au mieux. Le corps de wallet décodé (v4r2, v5r1, highload_v3, un transfert de jetton, un swap DEX) est déduit des seuls octets du message, et un contrat qui imite la structure d'un wallet peut être mal étiqueté.

Les doublons existent. Le même cell_hash peut arriver en early puis en checked, de nouveau après une reconnexion, et rarement après la fenêtre de déduplication. Le traitement doit être idempotent par cell_hash.

Certains messages sont écartés volontairement : les BoC de plus de 65 535 octets, les BoC qui ne sont pas des messages externes, et les destinations qui ne sont pas de simples addr_std.

Si l'un de ces points casse votre cas d'usage, il vous faut des transactions confirmées, pas un mempool. Détecter un paiement USDT entrant en est l'exemple canonique : un paiement est une transaction dans un bloc, et rien avant cela ne doit marquer une commande comme payée.

Comment fonctionne le flux mempool de TONNode

Le flux de TONNode est un seul WebSocket, wss://mempool.tonnode.io/v1/stream. Un serveur s'authentifie avec Authorization: Bearer tnmp_… ; un navigateur ne peut pas poser d'en-têtes, donc un backend qui détient la clé demande à POST /v1/ticket un ticket à usage unique valable 30 secondes et passe les sous-protocoles renvoyés à new WebSocket(url, subprotocols). Le premier message de chaque connexion est hello, copié ici depuis la documentation :

{"v":1,"type":"hello","contract":"1.1","epoch":"9f3c1a7be2d04c11","head_seq":123456,"oldest_seq":118020,
 "ts_gw_us":1791322891600000,"key_id":"0123456789ab",
 "limits":{"max_conn":3,"max_filters":null,"delay_ms":0,"replay_limit":null}}

Rien n'est livré tant que le client ne s'est pas abonné. Les filtres sont facultatifs et combinés en OU : dest (le wallet émetteur), out_dest (vers où le wallet envoie), op (un code d'opération, comme 0x0f8a7ea5 pour les transferts de jettons) et pool (un pool DeDust). "filters":{} est le flux entier ; un abonnement contient jusqu'à 10 000 entrées, et un subscribe ultérieur remplace les filtres sans rejeu. Un abonnement utilisant les quatre types de filtre et refusant les messages précoces :

{"v":1,"type":"subscribe",
 "filters":{"dest":["0:2a18ac1734f34579e6a6c2a9e738bb5799d21e7a73ef106895c00c34549a9167"],
            "out_dest":["EQB3ncyBUTjZUA5EnFKR5_EnOMI9V1tTEAAPaiU71gc4TiUt"],
            "op":["0x0f8a7ea5"],
            "pool":["0:a0d1bc3a139cbc6b39a3e3633f74476be441343f9d0fd88b949fca0327b65a75"]},
 "include_unverified":false}

Le serveur confirme avec le nombre d'entrées distinctes en vigueur et le point de départ de la livraison :

{"v":1,"type":"subscribed","filters":4,"include_unverified":false,"from_seq":123451}

À partir de là, un objet JSON par message arrive dans l'ordre des seq : le boc brut, ses hachages (cell_hash, le norm_hash normalisé selon TEP-467, sha256), le wallet de destination, path et unverified, deux horodatages et, lorsque la structure du corps est reconnue, parsed avec le type de wallet, seqno, valid_until et les transferts et swaps sortants.

Rejeu. Le serveur conserve les ~60 dernières secondes d'événements, au plus 64 Mio. Après une coupure, reconnectez-vous, envoyez resume avec l'epoch et le dernier seq traité, et recevez ce que vous avez manqué à travers vos nouveaux filtres. Un événement gap indique ce qui a été sauté et pourquoi : slow, source_reconnect ou ring.

Plans. Rien n'est compté sauf les connexions simultanées sur une clé : Test, 7 jours, 1 connexion, 5 $ ; Start, 30 jours, 1 connexion, 15 $ ; Pro, 30 jours, 3 connexions, 30 $ ; Business, 30 jours, 10 connexions, 100 $ ; davantage sur demande. Pas de quota de messages, pas de délai ajouté, pas de plan gratuit. La clé s'achète dans la console avec le même solde que les plans de nœuds ; le tableau complet est sur la page des tarifs.

Ce qui n'y est pas. Les messages envoyés via les propres liteservers de TONNode ne sont pas relayés aux abonnés du mempool. Si vous envoyez avec une clé de nœud TONNode, ces transactions n'apparaissent pas dans ce flux ; pour observer un wallet que vous contrôlez, envoyez par une autre route ou lisez vos propres envois depuis la chaîne.

Les consommateurs complets en Node.js, Python et Go, le parcours navigateur avec tickets et les codes d'erreur sont dans la documentation du flux mempool.

TonAPI streaming et toncenter streaming, comparés honnêtement

Trois services touchent la fenêtre d'avant-bloc, et ils ne sont pas interchangeables. La Streaming API de TonAPI proposait GET /v2/sse/mempool et une méthode WebSocket subscribe_mempool avec un filtre de comptes facultatif ; sa propre documentation s'ouvre désormais sur « Streaming API is deprecated — please use Webhooks API for real-time updates ». La Streaming API de Toncenter, sur wss://toncenter.com/api/streaming/v2/ws, livre transactions, actions, traces et changements d'état avec un niveau de finalité ; les événements pending sont émulés et peuvent être invalidés, et les abonnements exigent des adresses pour tout sauf les traces.

Aucun des trois ne publie de chiffre permettant de comparer la couverture. Mesurez sur votre propre trafic avant de décider.

Qui a besoin d'un flux mempool, et qui n'en a pas besoin

Vous en avez probablement besoin si :

• vous exploitez un DEX ou un bot de trading, et les secondes entre la diffusion d'un swap et son exécution sont votre avantage, avec include_unverified:false ou une étape de confirmation avant que quoi que ce soit ne bouge ;
• vous surveillez un ensemble de wallets ou un pool et voulez voir un transfert ou un swap à l'instant de sa diffusion, pas à l'arrivée du bloc ;
• vous étudiez le réseau : débits de messages, versions de wallets, routeurs DEX chargés, combien de messages ne s'exécutent jamais.

Vous n'en avez pas besoin si :

• vous détectez des paiements. Un paiement est une transaction dans un bloc ; lisez-la avec get_transactions et ne marquez jamais une commande comme payée à partir d'un message pending ;
• vous affichez des soldes ou un historique. Le mempool n'a pas d'état ; utilisez le chapitre LiteServers et l'historique des transactions par lt et hachage ;
• il vous faut chaque message, ou vos propres envois via les liteservers TONNode. La couverture est partielle par nature de l'overlay, et vos propres envois ne sont pas dans le flux, à dessein.

Pour le cas du trading, construire un agent de trading TON parcourt la boucle lire, coter, swapper devant laquelle un flux mempool viendrait se placer.

FAQ

TON a-t-il un mempool ?

Pas un mempool global unique. TON n'a pas de pool de transactions non confirmées partagé par tout le réseau que chaque nœud conserverait et sur lequel tous s'accorderaient. Ce qui existe, c'est l'ensemble des messages externes qu'un nœud donné a reçus de l'overlay public et n'a pas encore vus dans un bloc ; il diffère d'un nœud à l'autre, dure quelques secondes et contient des messages qui ne s'exécuteront jamais.

Peut-on voir les transactions TON en attente ?

Oui, en deux sens. Toncenter montre des transactions et actions pending produites en émulant un message externe contre l'état courant, par adresse, et peut les invalider ensuite. Un flux mempool comme celui de TONNode montre les messages externes bruts eux-mêmes, tels qu'un nœud les entend, avant toute exécution. Ni l'un ni l'autre n'est une transaction confirmée ; seul un bloc l'est.

Pourquoi un message pending n'est-il pas dans un bloc ?

Parce qu'une transaction n'est créée que si le contrat destinataire accepte le message. Un wallet rejette une signature fausse, un seqno déjà utilisé, un valid_until expiré ou un message qu'il ne peut pas payer, et un message rejeté ne laisse aucune trace sur la chaîne. Un message peut aussi se perdre avant d'atteindre les nœuds qui produisent les blocs de ce shard. Dans un échantillon de 90 minutes d'octobre 2026, environ un message checked sur cinq n'a jamais été accepté.

Le flux mempool TON est-il complet ?

Non, et aucun flux ne peut l'être. Le flux de TONNode porte ce qu'un nœud reçoit de l'overlay public ; un message qui ne l'atteint jamais n'est pas dans le flux. TONNode ne publie aucun chiffre de complétude ni de vitesse et ne prétend pas être le premier. L'absence dans le flux ne prouve jamais que quelque chose n'a pas eu lieu.

Que signifie « unverified » dans le flux ?

Un message précoce, écrit avant la vérification de signature du nœud à la diffusion, à un point où n'importe quel pair de l'overlay peut injecter des octets, et qui peut donc être du bruit ou une contrefaçon. Les messages précoces sont livrés par défaut ; un abonnement avec "include_unverified": false ne reçoit que les messages checked, qui ont passé les vérifications de diffusion du nœud mais n'ont pas été exécutés par un validateur.

Combien coûte le flux mempool de TONNode ?

Les plans sont tarifés par connexions simultanées sur une clé : Test, 7 jours avec 1 connexion pour 5 $ ; Start, 30 jours avec 1 connexion pour 15 $ ; Pro, 30 jours avec 3 connexions pour 30 $ ; Business, 30 jours avec 10 connexions pour 100 $. Il n'y a ni quota de messages, ni délai ajouté, ni plan gratuit.

Avant de vous connecter

Relisez la section « qualité des données », décidez si vous avez même besoin des messages précoces, rendez votre traitement idempotent par cell_hash, et confirmez sur la chaîne avant que l'argent ne bouge. Si cela vous convient, une clé Test coûte 5 $ pour 7 jours sur la page des tarifs. Sinon, l'accès privé aux liteservers, qui lit l'état confirmé, est l'outil dont la plupart des produits ont réellement besoin.