Swap cross-chain TON → Base : comment ça fonctionne

Votre agent IA a repéré une opportunité intéressante : le capital de l'utilisateur est sur TON, mais le protocole ou l'actif dont il a besoin se trouve sur Base. La réponse classique, c'est « passez par un bridge ». Sauf qu'un bridge signifie que quelqu'un détient vos fonds le temps de la traversée : le contrat du bridge, un relayer, un multisig composé de signataires que vous n'avez pas choisis. Ces dernières années, ce sont précisément les bridges custodiaux qui ont fait disparaître plus d'un milliard de dollars appartenant aux utilisateurs — non pas parce que la cryptographie était mauvaise, mais parce que quelqu'un détenait les fonds dans l'intervalle.

Pour un agent autonome, le problème est double. D'abord, un agent ne devrait jamais signer une transaction qui cède des fonds à un tiers sans garantie de retour. Ensuite, un agent ne devrait tout simplement pas posséder vos clés privées. Or c'est exactement ce qu'exige un bridge classique : faire confiance à un intermédiaire.

Il existe une autre voie : l'escrow HTLC atomique. Voyons comment exécuter un swap cross-chain TON → Base de sorte qu'aucun intermédiaire ne puisse, à aucun moment, toucher à vos clés ni à vos fonds — et comment tout ce flux se pilote depuis un agent IA via cinq outils MCP de TONNode.

Pourquoi swapper de TON vers Base, et pourquoi ce n'est pas un bridge ordinaire

Base est le L2 de Coinbase au-dessus d'Ethereum, construit sur l'OP Stack. C'est là que migre la liquidité, là que s'installent les protocoles DeFi, et de plus en plus souvent c'est là que se trouve le contrat avec lequel votre agent doit interagir. Votre capital de départ, lui, est sur TON — en GRAM (le Toncoin renommé en juin 2026 ; le réseau, lui, s'appelle toujours TON) ou en USDT sur TON.

Un bridge ordinaire règle le problème par la garde des fonds. Vous confiez vos fonds au contrat du bridge sur le réseau source ; quelque part, un relayer le constate et émet l'équivalent sur Base. Entre le moment où vous donnez et celui où vous recevez, il existe une fenêtre pendant laquelle ce n'est pas vous qui contrôlez votre argent. Pour un humain qui transfère des fonds une fois par mois, c'est tolérable. Pour un agent qui le fait en boucle et sans surveillance, c'est un risque inacceptable.

L'alternative, c'est l'échange atomique : il n'existe aucun instant durant lequel les fonds appartiennent à un intermédiaire. Soit la transaction s'exécute intégralement sur les deux réseaux, soit elle est intégralement annulée. C'est exactement ainsi que fonctionne le cross-chain dans TONNode.

Comment fonctionne l'escrow HTLC atomique entre TON et Base

HTLC, pour hashed timelock contract : un escrow avec deux conditions de déblocage, le hash d'un secret et un timelock. Le plus simple est d'imaginer deux coffres-forts, un sur TON et un sur Base. Les deux s'ouvrent avec la même clé — le secret. Tant que le secret n'est pas révélé, les deux restent verrouillés.

• Le verrou par hash. Les fonds sont verrouillés sur les deux réseaux sous un seul et même hash de secret h = hash(s). On ne peut ouvrir l'escrow qu'en présentant le secret s lui-même, celui dont le hash correspond.
• Le timelock. Chaque coffre a une échéance. Si la transaction ne s'est pas exécutée à temps, les fonds reviennent à leur propriétaire une fois le timelock expiré.

Le schéma, en version simple :

1. Un secret aléatoire s est généré, ainsi que son hash h = hash(s).
2. Sur TON, vos fonds sont verrouillés dans un escrow sous la condition suivante : « remettre à qui présentera s ; rendre à l'expéditeur si s n'a pas été présenté avant l'échéance ».
3. Sur Base, la contrepartie (le resolver qui fournit la liquidité de destination) verrouille ses propres fonds sous le même h, avec un timelock plus court.
4. Vous révélez s pour récupérer les fonds sur Base. À cet instant, s devient public on-chain.
5. La contrepartie voit le s révélé et récupère les fonds verrouillés sur TON.

La propriété clé : h est identique sur les deux réseaux. Dès que le secret est révélé pour régler un côté, l'autre côté peut mathématiquement finaliser la transaction. L'état intermédiaire « mon argent est chez un inconnu » n'existe pas : il n'y a que les mathématiques du hash et l'horloge du timelock. Si quelque chose tourne mal et que le timelock expire, les fonds reviennent à leurs propriétaires d'origine. C'est atomique : soit les deux jambes s'exécutent, soit les deux sont annulées.

Dans le schéma de TONNode, TON est toujours le réseau source de la transaction, et Base (ou un autre réseau pris en charge) la destination.

Les cinq outils de swap cross-chain dans TONNode MCP

TONNode est un serveur MCP hébergé pour TON avec exactement 16 outils. MCP (Model Context Protocol) est le standard par lequel les agents IA (Claude, Cursor, ChatGPT/Codex et tout client MCP) appellent des outils externes. Le kit cross-chain compte exactement 5 outils, et ils sont disponibles sur tous les plans :

• get_crosschain_quote — la cotation : combien vous recevrez sur Base en échange de vos fonds sur TON, route et timelocks inclus.
• build_crosschain_swap_tx — construit la transaction d'escrow HTLC non signée pour TON et la renvoie avec le secret. C'est le wallet de l'utilisateur qui la signe, via TonConnect.
• track_crosschain_swap — affiche les phases du swap sur les deux réseaux : les fonds sont-ils verrouillés sur TON, la contrepartie a-t-elle verrouillé sur Base, le secret est-il révélé, le swap est-il finalisé.
• disclose_crosschain_secret — révèle le secret pour le règlement, mais seulement après confirmation on-chain que la jambe opposée est prête.
• build_crosschain_refund — construit la transaction non signée de récupération des fonds de l'escrow si le swap s'est bloqué et que le timelock a expiré.

Notez l'ordre des responsabilités : l'outil qui révèle le secret ne le fait pas à l'aveugle, mais après avoir vérifié que tout est prêt sur Base. Cela vous protège du scénario où vous révéleriez s alors que la contrepartie n'aurait encore rien verrouillé.

Le flux complet : cotation → construction → suivi → révélation du secret

Commencez par brancher le serveur. En local et gratuitement, avec le paquet @tonnode/mcp — open source (MIT), qui parle le protocole natif ADNL de TON sans couche HTTP intermédiaire :

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

Ensuite, tout se passe par des prompts adressés à l'agent — c'est lui qui les décompose en appels d'outils.

Étape 1. La cotation.

Donne-moi une cotation de swap cross-chain : 200 USDT de TON vers USDC sur Base.
Utilise get_crosschain_quote.

L'agent renvoie combien vous recevrez sur Base et quels sont les timelocks de l'escrow : les chiffres, avant toute action. Si cela vous convient, on continue.

Étape 2. Construction de la transaction non signée.

Construis la transaction d'escrow HTLC pour cette cotation via build_crosschain_swap_tx.
Mon adresse TON est EQ…, l'adresse de réception sur Base est 0x…

En sortie : un message TonConnect non signé contenant l'escrow HTLC, et le secret du swap. Le secret est à vous, conservez-le ; le serveur ne le stocke pas. Les fonds sont verrouillés dans l'escrow sur TON sous le hash de ce secret. La signature vient de votre wallet via TonConnect — le serveur ne touche jamais à la signature.

Étape 3. Le suivi.

Vérifie le statut du swap via track_crosschain_swap avec le hash h….
La contrepartie a-t-elle verrouillé les fonds sur Base ?

L'outil montre les phases sur les deux réseaux. L'agent attend que les deux côtés soient verrouillés sous le même hash.

Étape 4. La révélation du secret.

Les fonds sont verrouillés sur Base. Révèle le secret pour le règlement
via disclose_crosschain_secret.

L'agent ne révèle le secret qu'une fois que track_crosschain_swap a confirmé on-chain que tout est prêt. La révélation exécute les deux escrows de manière atomique : vous recevez les fonds sur Base, et la contrepartie, grâce au secret désormais public, clôture son côté sur TON. Le swap est terminé.

Remarquez l'ordre : le secret est révélé en dernier, et seulement après vérification que l'escrow d'en face est bien en place. Avant la révélation, vos fonds ne peuvent aller nulle part ; après la révélation, la transaction est déjà atomique.

Une analyse détaillée du même flux, mais avec Ethereum comme destination, se trouve dans un article dédié : swap cross-chain TON → Ethereum — la mécanique est identique, seul le réseau de destination change. Et pour comprendre pourquoi le seul fait de pouvoir déplacer de la valeur hors de TON par la main d'un agent constitue une nouvelle classe d'opérations, lisez cet article.

Non-custodial : pourquoi le serveur ne détient jamais vos clés

Ce n'est pas une formule marketing, c'est une propriété de l'architecture. Le serveur TONNode ne signe jamais de transactions et ne détient jamais de fonds ni de clés privées. Tout ce qu'il expose vers l'extérieur, ce sont des messages TonConnect non signés et des données : cotations, statuts, et le secret de votre propre swap.

Décomposons, étape par étape, où se trouve quoi :

• La clé privée de votre wallet TON — chez vous seul, dans le wallet.
• Le secret s — généré lors de la construction et remis à vous seul ; il ne reste pas sur le serveur.
• La signature de la transaction HTLC — apposée par votre wallet via TonConnect.
• Les fonds sur TON — dans un contrat d'escrow sous condition cryptographique, pas sur le compte d'un intermédiaire.

Même s'il le voulait, le serveur ne pourrait ni signer à votre place, ni détourner les fonds de l'escrow : il n'a ni la clé, ni le moyen de satisfaire la condition de déblocage à son profit. C'est fondamentalement différent de l'approche custodiale, où l'opérateur détient la clé et signe lui-même. Une comparaison développée des deux modèles se trouve dans l'analyse MCP custodial vs non-custodial ; et l'étude du swap sans garde des fonds à proprement parler, dans le texte sur le swap non-custodial depuis un agent.

Quels réseaux sont pris en charge en dehors de Base (et pourquoi TRON n'y est pas encore)

TON est toujours la source ; le réseau de destination peut être n'importe lequel parmi :

• Ethereum
• Arbitrum
• Base
• BNB Chain
• Polygon
• Avalanche

TRON n'est pas encore pris en charge. La raison est technique, pas idéologique : l'escrow HTLC atomique exige une sémantique compatible des hash-timelocks et un comportement prévisible des contrats côté destination. Si votre scénario dépend de TRON, ne construisez pas la logique de votre agent dessus : il ne fait pas partie du kit cross-chain actuel. Quand nous l'ajouterons, cela figurera dans la roadmap : tonnode.io/roadmap.

Comment se connecter, et que faire si le swap se bloque : le refund

Pour la production, avec un débit garanti, on utilise l'endpoint hébergé et sa propre clé :

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

Toutes les clés donnent accès aux 16 outils, kit cross-chain complet inclus. Vous ne payez que pour le débit, pas pour l'accès aux outils :

• Hobby — gratuit pour toujours, 60 requêtes/min. La clé est délivrée dès la connexion, sans carte bancaire.
• Pro — 29 $/mois, 300 requêtes/min.
• Scale — 199 $/mois, 1200 requêtes/min.

Et si la contrepartie n'a pas finalisé le swap ?

C'est ici que le timelock prend tout son sens. Si la partie adverse n'a pas exécuté sa part et que le timelock a expiré, vos fonds ne sont pas perdus : ils sont verrouillés sous une condition de retour à l'expéditeur passé l'échéance. L'agent appelle :

Le swap est bloqué, le timelock a expiré. Construis la transaction
de récupération des fonds de l'escrow via build_crosschain_refund.

build_crosschain_refund renvoie une transaction de récupération non signée — vous la signez avec votre wallet et récupérez vos fonds sur TON. C'est l'assurance intégrée au HTLC : le swap s'exécute atomiquement, ou il est annulé par le timelock. Un swap bloqué ne signifie pas de l'argent perdu, il signifie un refund. C'est précisément cette garantie qui fait de l'échange atomique un remplacement sûr du bridge custodial.

Par où commencer

Le swap cross-chain TON → Base cesse d'être un acte de foi envers un bridge dès lors que ce sont un verrou par hash et un timelock qui en répondent, et non un custodian tiers. Cinq outils, un non-custodial strict, six réseaux de destination — et tout cela s'appelle depuis votre agent avec une seule config MCP.

Le moyen le plus rapide d'essayer : prendre une clé Hobby gratuite (délivrée dès la connexion, sans carte bancaire) et dérouler le flux TON → Base depuis votre propre agent :

• Clé Hobby gratuite → tonnode.io/dashboard?plan=hobby
• Tarifs → tonnode.io/pricing
• Les 16 outils → tonnode.io/mcp
• Roadmap → tonnode.io/roadmap