Swap cross-chain TON vers BNB Chain : comment ça marche

Un agent chargé d'« échanger des GRAM contre des BNB et de payer une contrepartie sur BNB Chain » se heurte à un mur dès la première étape. Il n'a aucun moyen de transférer de la valeur en toute sécurité entre deux blockchains qui ne savent rien l'une de l'autre. La voie classique, c'est le bridge centralisé ou l'exchange : déposez vos fonds, faites confiance, attendez et espérez que rien ne restera coincé entre les deux réseaux. Pour un agent IA autonome, c'est inacceptable : il ne peut pas « faire confiance » à un custodian, n'a pas le droit de remettre les clés d'autrui à un tiers, et n'a pas de mains pour débloquer manuellement une transaction en rade.

Il faut un moyen de déplacer la valeur de TON vers BNB Chain qui ne laisse que deux issues : soit tout passe intégralement, soit tout revient au point de départ — sans intermédiaire qui détient l'argent. C'est exactement ce que fait le swap cross-chain via un escrow HTLC atomique. Voyons comment il fonctionne, quels sont les cinq outils MCP de TONNode avec lesquels l'agent mène l'opération, et pourquoi le serveur ne touche jamais à vos fonds au passage.

Qu'est-ce qu'un swap cross-chain TON → BNB Chain, et pourquoi un agent en a besoin

Un swap cross-chain, c'est l'échange d'un actif sur un réseau contre un actif sur un autre, sans registre commun entre les deux. TON et BNB Chain sont deux réseaux indépendants, chacun avec sa machine virtuelle ; ils n'ont pas de « banque » commune qui se contenterait de réécrire les soldes. Il faut donc un protocole qui synchronise deux transferts indépendants au point de les rendre indissociables.

Chez TONNode, le cross-chain part toujours de TON comme réseau source vers un réseau EVM cible — dans notre cas, BNB Chain. Il n'existe ni sens inverse ni « BNB comme source » : TON est toujours le point de départ. Vous verrouillez des GRAM ou un jetton côté TON, et vous recevez l'actif côté BNB Chain.

GRAM, c'est le Toncoin renommé en juin 2026. Le réseau s'appelle toujours TON, seul le nom de la monnaie a changé.

Pourquoi un agent en a-t-il besoin ? Parce que les tâches réelles se cantonnent rarement à un seul réseau. Un agent-trésorier détient ses réserves en GRAM, mais le fournisseur doit être payé sur BNB Chain. Un bot de trading repère un arbitrage entre un DEX sur TON et un autre sur BNB. Un assistant exécute la consigne « transfère l'équivalent de 50 GRAM à la contrepartie sur BSC ». Dans tous les cas, il faut un moyen de franchir la frontière entre réseaux — de façon déterministe, sans custodian et sans intervention manuelle.

Comment fonctionne l'escrow HTLC atomique : secret, hash et timelock

HTLC signifie Hashed Timelock Contract — un contrat à verrou de hachage et à timelock. Ça a l'air compliqué, mais l'analogie est simple.

Imaginez deux coffres : l'un sur TON, l'autre sur BNB Chain. Les deux se ferment avec le même cadenas, qui ne s'ouvre qu'avec une unique clé secrète — un nombre aléatoire, le « secret » S. Ce qui est déposé sur la blockchain, ce n'est pas le secret lui-même mais son hash H = hash(S) — l'empreinte du cadenas. N'importe qui peut vérifier que la clé correspond au cadenas, mais impossible de reconstruire la clé à partir de l'empreinte.

Le coffre côté BNB Chain, ce n'est pas vous qui le remplissez : la jambe opposée est posée par la contrepartie — un résolveur (market maker) qui verrouille des BNB sous le même hash H, et qui compte bien récupérer vos GRAM côté TON avec ce même secret. C'est précisément ce qui rend l'opération symétrique : les deux côtés sont fermés par le même cadenas.

Ensuite, deux conditions entrent en jeu :

• Le verrou de hachage. On ne peut retirer les fonds d'un coffre qu'en présentant le secret correspondant au hash publié. Dès que le secret est révélé d'un côté, il devient visible de l'autre — et la seconde jambe de l'opération s'exécute avec la même clé. Celui qui retire les fonds est obligé de présenter S en clair on-chain.
• Le timelock. Chaque coffre a son minuteur. Si l'opération ne s'est pas conclue avant l'expiration du timelock, les fonds reviennent à leur propriétaire d'origine. Les timelocks sont calibrés de sorte que la partie qui révèle le secret en premier ne puisse pas duper la partie adverse.

Résultat : l'atomicité. Soit les deux jambes s'exécutent, soit les deux sont remboursées. L'état intermédiaire où vous avez cédé vos GRAM sans recevoir les BNB n'existe physiquement pas. Aucun tiers ne « garantit » l'opération ici — la garantie vient des mathématiques de la fonction de hachage et de la logique des timelocks dans les contrats. C'est le même mécanisme que celui des atomic swaps et des paiements Lightning, simplement adapté à TON et à l'EVM.

Les cinq outils de l'opération : cotation, construction, suivi, révélation, remboursement

Tout le cycle de vie d'un swap cross-chain chez TONNode est couvert par cinq outils MCP. L'agent les appelle l'un après l'autre — comme les étapes successives d'une même opération.

get_crosschain_quote — la cotation

Renvoie la cotation de l'opération TON → BNB Chain : combien vous cédez côté TON et combien vous recevez côté BNB Chain. Tout swap commence par là — l'agent montre les chiffres à l'utilisateur avant que quoi que ce soit ne soit verrouillé.

build_crosschain_swap_tx — construction de la transaction + secret

Renvoie une transaction d'escrow HTLC non signée, plus le secret. La transaction est signée par le portefeuille de l'utilisateur via TonConnect, pas par le serveur. Le secret S est généré ici même et reste chez l'utilisateur/l'agent — c'est lui qui déverrouillera plus tard la seconde jambe. Le serveur a généré la transaction et le hash, mais la signature et la possession du secret restent chez l'utilisateur.

track_crosschain_swap — suivi des phases

Montre les phases de l'opération sur les deux réseaux — TON et BNB Chain : la jambe TON est-elle verrouillée, la jambe opposée est-elle apparue sur BNB Chain, le secret est-il révélé, le règlement est-il terminé. Ce sont les yeux de l'agent : sans ce suivi, il ne sait pas quand il peut révéler le secret sans risque, ni s'il est temps de passer au remboursement.

disclose_crosschain_secret — révélation du secret

Révèle le secret pour le règlement — mais seulement après vérification on-chain que tout est en place. L'outil ne livrera pas S à l'aveugle : il s'assure d'abord que la jambe opposée sur BNB Chain est bien là et que les conditions sont remplies. Cela vous protège du scénario où le secret est révélé alors qu'il n'y a rien à récupérer en face.

build_crosschain_refund — récupération depuis l'escrow

Construit la transaction de retour des fonds depuis l'escrow si l'opération est restée bloquée — une fois le timelock expiré. Là encore, une transaction non signée pour TonConnect. Le filet de sécurité, sur lequel nous reviendrons à la fin.

Pourquoi c'est non-custodial : le serveur ne signe rien et ne garde aucune clé

C'est ici que passe la ligne rouge de TONNode. Les outils de swap, de cross-chain et de portefeuille sont strictement non-custodiaux. Le serveur ne signe JAMAIS et ne détient jamais ni fonds ni clés privées — il ne renvoie que des messages TonConnect non signés, que le portefeuille de l'utilisateur signe lui-même.

Concrètement, dans le cas du cross-chain :

• build_crosschain_swap_tx renvoie une transaction sans signature. C'est le portefeuille de l'utilisateur qui signe — Tonkeeper, MyTonWallet, n'importe quel portefeuille compatible TonConnect. Tant que l'utilisateur n'a pas confirmé la transaction, rien n'est verrouillé.
• Le secret S part côté client. Le serveur ne peut pas vider l'escrow en douce : il faudrait pour cela la signature du propriétaire, et le serveur ne l'a pas.
• Même le remboursement est une transaction non signée : c'est l'utilisateur qui l'initie, pas le serveur.

Conclusion pratique : un serveur compromis n'entraîne pas de vol de fonds — il n'y a rien à y dérober : ni clés, ni signatures, ni contrôle sur l'escrow. Au pire, ce qui peut « casser », c'est la disponibilité du service (l'agent n'obtiendra pas de cotation) — pas votre argent.

Comparez avec le modèle custodial, où un portefeuille-agent détient une clé operator et signe lui-même. Les deux modèles ont leur raison d'être, mais pour un cross-chain traversant deux réseaux indépendants, la non-custodialité est particulièrement critique — vous ne voulez pas qu'un intermédiaire contrôle des fonds suspendus entre deux blockchains. L'analyse détaillée des deux approches se trouve dans MCP custodial ou non-custodial. Et pour voir ce que cela donne sur un swap classique à l'intérieur de TON, lisez Swap non-custodial pour un agent.

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

Chez TONNode, le cross-chain va toujours de TON vers un réseau EVM cible. Les cibles prises en charge :

• Ethereum
• Arbitrum
• Base
• BNB Chain (notre cas)
• Polygon
• Avalanche

TRON n'est PAS encore pris en charge. La raison est technique : l'escrow HTLC atomique exige que le réseau cible interprète les contrats hash-timelock de manière identique dans le cadre du protocole d'escrow retenu. Les six réseaux listés sont compatibles EVM et rentrent dans ce modèle ; TRON, malgré sa ressemblance de surface, vit selon son propre modèle et demande une implémentation d'escrow à part. Tant qu'elle n'existe pas, TRON n'est pas dans la liste — et nous ne faisons pas passer un souhait pour un fait.

Sur la paire la plus populaire — TON → Ethereum — il existe une analyse dédiée : Swap cross-chain TON → Ethereum. La mécanique est la même, seul le réseau cible change.

Déroulé pas à pas d'un swap TON → BNB via MCP

Commençons par brancher TONNode sur l'agent. La config publique locale @tonnode/mcp est gratuite et donne le jeu complet d'outils de lecture — mais rien que la lecture. Le paquet est open source (MIT), fonctionne via le protocole natif ADNL de TON, sans couche HTTP intermédiaire :

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

Précision importante : les cinq outils cross-chain ne sont pas accessibles via le npx public local — il n'y a là que la lecture. L'opération cross-chain passe par l'endpoint hébergé avec sa propre clé, et la clé gratuite Hobby suffit :

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

Avec une clé hébergée, les 16 outils — y compris les cinq outils cross-chain — sont disponibles sur tous les plans, à partir du plan Hobby gratuit. Vous ne payez que le débit (Hobby — gratuit, 60 requêtes/min ; Pro — 29 $/mois, 300 requêtes/min ; Scale — 199 $/mois, 1200 requêtes/min). Le cross-chain n'est pas verrouillé derrière un plan supérieur — mais le npx local ne fera pas l'affaire : il faut une clé hébergée.

Passons au déroulé lui-même. Le prompt donné à l'agent peut être on ne peut plus humain :

« Échange 50 GRAM de mon portefeuille TON vers BNB Chain à l'adresse 0x…. Montre-moi d'abord la cotation, puis construis la transaction — je signerai moi-même. »

Ce qui se passe sous le capot :

1. Cotation. L'agent appelle get_crosschain_quote (source TON, cible BNB Chain, montant 50 GRAM) et montre combien arrivera côté BNB Chain.
2. Construction. Après votre « ok », l'agent appelle build_crosschain_swap_tx. Il reçoit la transaction d'escrow HTLC non signée et le secret S. Vous confirmez la transaction dans votre portefeuille via TonConnect. Les fonds sont verrouillés dans l'escrow côté TON sous le hash H.
3. Suivi. L'agent appelle périodiquement track_crosschain_swap et surveille les phases sur les deux réseaux : la jambe TON est-elle verrouillée, la jambe opposée est-elle montée sur BNB Chain (c'est le résolveur qui la pose, sous le même hash H).
4. Révélation et règlement. Dès que track_crosschain_swap indique que tout est prêt, l'agent appelle disclose_crosschain_secret. L'outil vérifie l'état on-chain et révèle S — le secret devient visible sur BNB Chain, les deux jambes s'exécutent, les BNB arrivent à votre adresse.
5. Confirmation. Un dernier track_crosschain_swap montre que les deux côtés sont réglés. L'opération est close.

Tout l'intérêt est là : à chaque instant, vous voyez l'état de l'opération sur les deux réseaux et vous ne signez que ce que vous voyez. Si la philosophie générale du premier déplacement de valeur hors de TON via MCP vous intéresse, elle est décortiquée dans Le premier transfert de valeur cross-chain depuis TON.

Si l'opération reste bloquée : récupérer les fonds de l'escrow

Le cross-chain, ce sont deux réseaux indépendants, et parfois la jambe opposée ne monte pas : la contrepartie a un problème, le réseau est saturé, quelque chose a déraillé. Dans le modèle custodial, c'est là que commencent les échanges de messages avec le support. Avec HTLC, on attend simplement le timelock.

Les fonds ne sont pas verrouillés pour toujours. Dès que le timelock a expiré sans que l'opération se conclue, l'agent appelle build_crosschain_refund et obtient une transaction non signée de retour depuis l'escrow. Vous la signez avec votre portefeuille via TonConnect — et les GRAM verrouillés vous reviennent. Pas de « fonds coincés à jamais » : cette garantie est inscrite dans le contrat lui-même, ce n'est pas une promesse du service.

Le prompt peut ressembler à ceci :

« Mon swap cross-chain vers BNB Chain ne s'est pas terminé. Vérifie le statut et, si le timelock est expiré, récupère mes fonds. »

L'agent appellera track_crosschain_swap, s'assurera que le règlement n'a pas eu lieu et que le timelock est passé, puis construira le retour via build_crosschain_refund et vous remettra la transaction à signer.

Le point de sécurité clé : le secret n'est révélé via disclose_crosschain_secret qu'après vérification on-chain que tout est en place. L'agent ne se retrouvera pas dans le piège où le secret est déjà révélé et où il n'y a rien à récupérer. Soit le règlement passe atomiquement, soit le timelock déclenche le remboursement. Il n'y a pas de troisième issue — c'est tout le sens du mot « atomique ».

---

Récupérer une clé gratuite et brancher le cross-chain

Les cinq outils cross-chain font partie du jeu standard de 16 — rien à acheter en plus. Prenez la clé gratuite Hobby (60 requêtes/min, sans carte bancaire, délivrée dès la connexion) et branchez TONNode sur votre agent : tonnode.io/dashboard?plan=hobby.

Vous préférez d'abord parcourir les 16 outils et leurs paramètres — la page des outils est là : tonnode.io/mcp.

Le cross-chain de TON vers BNB Chain cesse d'être un exercice de « confiance envers un bridge » et devient un simple appel d'outil — atomique, non-custodial, avec remboursement garanti si quelque chose tourne mal.