Swap cross-chain TON → Avalanche : comment ça marche

Pourquoi un agent doit déplacer de la valeur de TON vers Avalanche

Votre agent a repéré un bon prix sur un actif côté Avalanche, mais tout son solde est en GRAM sur TON. La suite, vous la connaissez : retirer les GRAM vers un exchange, attendre le crédit, passer le KYC, acheter le bon token, le retirer vers le réseau Avalanche, et payer chaque étape en frais et en temps. Cinq opérations manuelles, trois intermédiaires de confiance et une demi-heure pendant laquelle le prix, lui, a déjà bougé.

Pour un humain, c'est agaçant. Pour un agent IA autonome, c'est incompatible avec l'autonomie : il n'a pas de compte sur un exchange ni le droit de passer la vérification à votre place, et construire un processus fiable au-dessus d'un custodian qui peut geler un retrait à tout moment, c'est tout simplement exclu. À chaque étape, quelqu'un détient vos fonds, et l'agent doit stocker quelque part une clé API d'exchange ou la seed phrase d'un hot wallet.

Le swap cross-chain TON → Avalanche prend le problème autrement. Aucun exchange au milieu. Les fonds circulent entre les réseaux avec une garantie mathématique — « soit l'échange a eu lieu sur les deux chaînes, soit personne n'a rien perdu » — et non sur la promesse d'un intermédiaire. Voyons comment cela fonctionne concrètement via les outils MCP de TONNode — sans custodian et sans clés stockées côté serveur.

Comment fonctionne l'escrow HTLC atomique entre TON et Avalanche

La mécanique centrale, c'est l'escrow HTLC atomique (hashed timelock contract, un escrow à hashlock et timelock). Le nom est lourd, mais l'idée est simple, et une analogie avec un coffre bancaire la rend limpide.

Vous déposez des fonds dans un coffre qui ne s'ouvre qu'avec la bonne clé — le secret. Le coffre a un minuteur : si la clé n'est pas insérée dans le délai imparti, le contenu revient à son propriétaire. Placez maintenant deux coffres de ce type — un sur TON, l'autre sur Avalanche — et verrouillez-les avec le même cadenas :

• Un secret aléatoire S est généré, ainsi que son hash H = hash(S). Impossible de retrouver le secret à partir du hash, mais facile de vérifier qu'un secret présenté lui correspond.
• Côté TON, vous déposez vos GRAM dans un escrow avec le hashlock H.
• Côté Avalanche, la contrepartie (un market maker) dépose l'actif cible dans son propre escrow avec le même H.
• Quand vous révélez le secret S pour récupérer l'actif sur Avalanche, S devient public sur la blockchain. Le market maker le voit et récupère vos GRAM dans l'escrow TON avec ce même S.

D'où le mot atomique. Débloquer un escrow sans débloquer l'autre est impossible : le secret est le même sur les deux réseaux. Soit les deux parties reçoivent leurs fonds, soit, une fois le timeout écoulé, chacune récupère les siens via un refund. L'état intermédiaire « l'argent a quitté TON mais l'actif n'est pas arrivé » n'existe tout simplement pas.

La garantie repose ici sur la cryptographie et les timeouts, pas sur la réputation d'un intermédiaire. Et c'est précisément pour cela qu'aucun exchange n'est nécessaire au milieu.

Les cinq outils du cross-chain : quote, build, track, disclose, refund

Chez TONNode, le cross-chain tient en exactement cinq outils MCP, chacun couvrant une phase de la transaction :

• get_crosschain_quote — la cotation : quelle quantité d'actif vous recevrez sur le réseau cible pour vos GRAM ou votre jetton, route et timeouts compris.
• build_crosschain_swap_tx — assemble la transaction d'escrow HTLC non signée pour TON et renvoie le secret associé (et son hash). C'est le wallet de l'utilisateur qui signe la transaction.
• track_crosschain_swap — montre les phases de l'échange sur les deux réseaux : si votre dépôt est bien arrivé dans l'escrow TON, si l'escrow de contrepartie est apparu sur Avalanche.
• disclose_crosschain_secret — révèle le secret pour le règlement, après vérification on-chain que tout est prêt (escrow de contrepartie en place, montants et hash concordants).
• build_crosschain_refund — assemble la transaction de remboursement depuis l'escrow si l'échange est bloqué et que le timeout est passé.

Cinq outils, ce n'est pas « peu ». Ce sont exactement les cinq étapes qui composent physiquement un swap atomique : coter, déposer, suivre, régler et, en cas d'échec, rembourser. Pas un de trop, pas un qui manque.

Non-custodial : le serveur ne signe rien et ne stocke aucune clé

Ce n'est pas une formule marketing, c'est une contrainte d'architecture. Les outils cross-chain, swap et wallet de TONNode sont strictement non-custodial :

• Le serveur ne signe jamais de transactions et ne détient jamais de fonds ni de clés privées.
• build_crosschain_swap_tx renvoie un message TonConnect non signé. La signature vient du wallet de l'utilisateur — Tonkeeper, MyTonWallet ou n'importe quel wallet compatible TonConnect. Le serveur n'a fait qu'assembler une enveloppe de transaction correcte.
• Le secret S du HTLC est généré par le serveur puis vous est remis avec la transaction assemblée — sa révélation reste ensuite sous votre contrôle. Même l'appel à disclose_crosschain_secret est un geste délibéré, effectué après la vérification on-chain, que vous initiez vous-même — pas une action automatique quelque part sur le backend.

Si le serveur TONNode disparaît subitement au milieu de l'échange, vos fonds ne sont pas perdus : ils reposent dans un escrow sur la blockchain, et build_crosschain_refund les récupérera une fois le timeout passé. Pour déplacer de la valeur entre réseaux, le non-custodial se résume à une chose simple : sur le serveur, il n'y a rien à voler et rien à geler.

Comparez avec le modèle custodial, où l'opérateur détient la clé et signe lui-même. Les deux modèles ont leur place — nous avons détaillé cette frontière dans le texte sur le MCP custodial vs non-custodial et dans l'analyse du swap non-custodial pour agent.

Quels réseaux sont pris en charge (et pourquoi TON est toujours la source)

Les réseaux cibles du cross-chain : Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON n'est pas encore pris en charge — ne l'intégrez pas dans vos process.

Une contrainte de direction importante : TON est toujours la source du swap. Vous déposez des GRAM ou un jetton dans l'escrow TON, et vous récupérez l'actif de contrepartie sur le réseau EVM cible. Cela découle de la mécanique : le HTLC est initié par un dépôt sur TON, là où vivent votre wallet et votre solde, et la contrepartie le réplique sur le réseau cible.

Conclusion pratique : si votre agent vit sur TON et doit livrer de la valeur vers Avalanche, c'est exactement le scénario pour lequel tout a été conçu. En revanche, s'il faut faire entrer des fonds dans TON depuis l'extérieur, cette route n'existe pas aujourd'hui. Le cross-chain de TON vers Ethereum fonctionne à l'identique — seul le paramètre du réseau cible change ; l'analyse détaillée est dans le swap TON → Ethereum.

Scénario pas à pas : swap GRAM → Avalanche

Assemblons le tout. Voici l'ordre réel des appels ; l'agent le déroule seul, il ne vous reste qu'à signer la transaction dans votre wallet.

Étape 1. La cotation. L'agent demande le prix :

« Donne-moi une cotation cross-chain : 500 GRAM de TON vers USDC sur Avalanche. »

Sous le capot : get_crosschain_quote. L'agent voit le montant en sortie, la route et les paramètres des timelocks. Si le prix convient, on continue.

Étape 2. Assemblage de la transaction d'escrow HTLC.

« Ça me va. Assemble la transaction sur cette cotation vers mon adresse Avalanche 0x… et renvoie le message TonConnect non signé et le hash du secret. »

C'est build_crosschain_swap_tx qui est appelé. Il renvoie la transaction de dépôt dans l'escrow TON non signée, plus le secret et son hash H. L'utilisateur signe le message avec son wallet via TonConnect — c'est à cet instant précis que les GRAM partent dans l'escrow sur TON. Le serveur ne touche pas à la signature.

Étape 3. Suivi de l'escrow de contrepartie.

« Suis l'échange via track_crosschain_swap jusqu'à ce qu'un escrow de contrepartie avec mon hash apparaisse sur Avalanche. »

track_crosschain_swap montre les phases sur les deux réseaux. On attend que le market maker dépose l'actif cible dans son escrow sur Avalanche sous le même H. Tant que l'escrow de contrepartie n'est pas là, on ne révèle pas le secret.

Étape 4. Révélation du secret et règlement. Quand le suivi a confirmé que tout est prêt on-chain :

« L'escrow de contrepartie est en place. Vérifie l'état on-chain et révèle le secret via disclose_crosschain_secret. »

disclose_crosschain_secret vérifie d'abord que tout est prêt (l'escrow de contrepartie existe, montants et hash concordent), puis révèle le secret. Celui-ci déverrouille les deux escrows : vous recevez vos USDC sur Avalanche, la contrepartie récupère les GRAM de l'escrow TON avec ce même S. L'échange est clôturé atomiquement.

Étape 5 (seulement en cas d'échec). Le remboursement. Si l'escrow de contrepartie n'est jamais apparu et que l'échange est bloqué, on ne révèle pas le secret. On attend le timeout et on appelle build_crosschain_refund :

« L'échange est bloqué, le timeout est écoulé. Assemble le remboursement via build_crosschain_refund. »

L'outil assemble la transaction qui renvoie les GRAM de l'escrow TON vers votre adresse ; l'utilisateur la signe avec son wallet. Perdre des fonds à cause d'une contrepartie défaillante est impossible by design : le timelock les protège.

Notez la discipline : le secret n'est révélé qu'une fois que le suivi a confirmé l'escrow de contrepartie. Le révéler trop tôt est la seule façon de se faire avoir — et c'est précisément pour cela que cette étape est un outil explicite et distinct, pas un automatisme caché.

Brancher le serveur MCP, et la suite

D'abord, une distinction importante à poser tout de suite, pour ne pas perdre de temps. Le paquet @tonnode/mcp est open source (MIT, GitHub tonnode/mcp) et parle le protocole natif ADNL de TON, sans couche HTTP intermédiaire. Lancé en local avec la config publique, il donne l'ensemble complet des outils de lecture (8 outils read : solde, état de compte, transactions, get-methods, etc.) — de quoi lire TON, mais ni swap, ni cross-chain, ni wallet. La config locale pour un client MCP (Claude, Cursor, Codex, tout client compatible MCP) :

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

Les cinq outils cross-chain de cet article (comme le swap et la génération de wallet) ne fonctionnent que via l'endpoint hébergé mcp.tonnode.io avec une clé Bearer. La clé Hobby est gratuite et délivrée dès la connexion, sans carte bancaire (60 requêtes/min) — mais c'est bien une clé pour l'endpoint hébergé, pas le simple npx local. La config pour le pipeline cross-chain :

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

Quelques faits pour lever les questions habituelles :

• TONNode compte 16 outils au total. Les 16 sont disponibles sur tous les plans — vous payez pour le débit, pas pour le « déblocage de fonctionnalités ». La différence entre les deux configs ci-dessus ne tient pas au catalogue mais au point d'entrée : le npx local ne donne que la lecture, l'endpoint hébergé avec clé ouvre l'ensemble complet, dont les cinq outils cross-chain.
• GRAM est le nouveau nom du Toncoin depuis juin 2026. Le réseau s'appelle toujours TON ; seul le nom de la monnaie a changé.
• La clé gratuite Hobby — 60 requêtes par minute, sans carte bancaire — suffit à dérouler le pipeline cross-chain complet.

Et maintenant

Si votre agent vit déjà sur TON et que vous devez livrer de la valeur vers Avalanche (ou Ethereum, Base, Arbitrum, BNB Chain, Polygon), montez la chaîne get_crosschain_quote → build_crosschain_swap_tx → track_crosschain_swap → disclose_crosschain_secret et gardez build_crosschain_refund en filet de sécurité. Pourquoi il vaut mieux traiter le cross-chain depuis TON via MCP plutôt que via un exchange, nous le détaillons à part — dans ce texte.

Obtenez votre clé Hobby gratuite et branchez les outils cross-chain dès maintenant : tonnode.io/dashboard?plan=hobby. Pas de carte bancaire, et 60 requêtes/min suffisent pour dérouler le pipeline complet et voir le HTLC atomique à l'œuvre.

Pour voir les 16 outils : la page des outils. Ce qui arrive ensuite : la roadmap.