Pourquoi TON déjoue les explorateurs ordinaires
TON est construit sur un modèle d’acteurs. Chaque contrat est un acteur indépendant avec son propre état, et les contrats communiquent uniquement en s’envoyant des messages entre eux. Il n’y a pas d’appels synchrones — un contrat ne peut pas en appeler un autre et attendre la réponse au sein de la même exécution.
Une seule action utilisateur se décompose donc en une séquence. Vous envoyez un message à votre contrat de portefeuille. Il envoie un message à un portefeuille jetton. Celui-ci envoie un message au portefeuille jetton du destinataire. Celui-ci peut envoyer une notification plus loin. Chaque saut est une transaction on-chain distincte, dans un bloc distinct, éventuellement dans un shard distinct.
Un explorateur qui vous montre « la transaction » vous montre le premier saut. Tout ce qui comptait réellement s’est passé après, et si quelque chose a échoué trois sauts plus loin, le premier saut paraît quand même entièrement réussi.
Tonviewer trace l’arbre. Ouvrez une action et vous voyez toute la cascade, avec le sort de chaque message. C’est le produit, et c’est la différence entre comprendre ce qui s’est passé et deviner.
Les portefeuilles jetton, qui déroutent tout le monde
Le standard de token de TON s’appelle Jetton, et il ne fonctionne pas comme l’ERC-20.
Sur Ethereum, un contrat de token détient un mapping du solde de chaque détenteur. Sur TON, chaque détenteur reçoit son propre contrat de portefeuille jetton, déployé séparément, ne détenant que son solde. Le contrat maître régit le token ; il ne stocke pas qui possède quoi.
C’est une décision de mise à l’échelle délibérée — elle évite qu’un contrat unique ne devienne un goulot d’étranglement à travers les shards — et elle produit une confusion spécifique et récurrente : votre solde de token n’est pas à l’adresse de votre portefeuille. Il est à une adresse de portefeuille jetton dérivée que votre portefeuille possède.
Les gens envoient constamment des tokens vers le mauvais de ces portefeuilles. Tonviewer les étiquette explicitement, montrant le propriétaire aux côtés de chaque portefeuille jetton, ce qui est la chose qui rend le modèle compréhensible plutôt qu’alarmant.
Issu de nos tests
Nous avons tracé un transfert de jetton qui semblait avoir échoué. Le premier saut a réussi, le second a réussi, et le troisième a rebondi car le portefeuille jetton du destinataire n’avait pas été déployé et la valeur attachée était insuffisante pour le déployer. Deux des trois explorateurs que nous avons essayés montraient une transaction réussie. Seule la trace de messages complète a révélé le rebond.
Les messages rebondis : la version TON d’un revert
Quand un message TON ne peut pas être traité, il rebondit — la valeur retourne à l’expéditeur, moins les frais. C’est le mode d’échec normal et cela ne ressemble en rien à un revert EVM, car la transaction originale a déjà réussi au moment où le rebond se produit.
L’implication pratique : sur TON, une transaction réussie ne signifie pas un résultat réussi. Cela signifie que votre message a été accepté pour livraison. Ce qui s’est passé à l’autre bout est un événement séparé qui peut arriver quelques secondes plus tard.
Tonviewer marque clairement les messages rebondis dans la trace. Si un transfert « est passé » et que le destinataire ne signale rien, c’est le premier endroit à regarder, et c’est le champ qui explique l’écrasante majorité de ces cas.
TonAPI
Tonviewer s’appuie sur TonAPI, qui offre un niveau gratuit avec une clé et des plans payants au-delà. C’est une surface nettement plus conviviale que l’accès brut à un nœud TON, car elle fait le même travail de réassemblage que l’interface web — vous obtenez des traces plutôt que des messages isolés.
Ce réassemblage est précisément pourquoi vous l’utiliseriez plutôt que d’interroger un nœud directement. Reconstruire un arbre de messages depuis des transactions brutes à travers les shards est un vrai travail, et l’API qui le fait pour vous est l’essentiel de la valeur.
Pour des besoins plus légers, des points d’accès HTTP TON publics existent et Tonscan est open source, ce qui en fait le meilleur point de départ si vous voulez voir comment les données sont assemblées plutôt que de faire confiance au fait qu’elles le sont.
Tonviewer ou Tonscan ?
Tonviewer quand vous devez comprendre ce qui s’est passé — un transfert qui n’est pas arrivé, une interaction de contrat avec un résultat inattendu, tout ce qui implique plus d’un saut.
Tonscan quand vous voulez la vitesse et la simplicité, ou quand vous voulez un outil open source. Il est plus léger, il s’affiche plus vite, et il fait moins de décodage, ce qui est parfois exactement ce que vous voulez.
Utilisez les deux. Sur une chaîne aussi structurellement inhabituelle, un second rendu des mêmes données a résolu plus de confusion pour nous que sur tout autre réseau. Et quel que soit celui que vous utilisez, souvenez-vous des deux règles spécifiques à TON : vos tokens ne sont pas à l’adresse de votre portefeuille, et une transaction réussie n’est pas un résultat réussi.