MCP custodial vs non-custodial : qui détient les clés de l'agent

Vous demandez à un agent IA de faire un swap sur TON. Il appelle le bon outil et, dix secondes plus tard, la transaction est déjà dans la blockchain — vous ne l'avez pas signée, vous n'avez pas ouvert votre wallet, vous n'avez rien confirmé. Pratique ? Oui. Et maintenant, ce même agent parse mal votre prompt, confond amount et envoie 500 GRAM au lieu de 5. Sans rien demander, là non plus. La question à se poser avant le premier swap, pas après : qui détient réellement la clé privée, et qui appose la signature sur la transaction ?

C'est précisément la ligne de partage entre les deux modèles de serveurs MCP pour TON. Examinons le MCP custodial face à l'agent-wallet non-custodial de manière concrète — avec les configs, les outils et les risques honnêtes des deux côtés.

MCP custodial ou agent-wallet non-custodial : qui détient les clés et qui signe

D'abord, les bases. MCP (Model Context Protocol) est le standard par lequel les agents IA (Claude, Cursor, ChatGPT/Codex et tout autre client MCP) appellent des outils externes. Un agent ne sait pas interroger la blockchain par lui-même — il appelle un outil MCP du genre « donne-moi le solde » ou « construis un swap », et le serveur MCP fait le travail. Et pour la blockchain, tout se ramène à un détail technique : la transaction doit être signée avec une clé privée.

La custodialité d'un agent se définit par deux choses :

1. Où se trouve physiquement la clé privée — sur le serveur MCP ou chez l'utilisateur ? Celui qui la possède dispose des fonds.
2. Qui appose la signature — le serveur lui-même ou le wallet de l'utilisateur ? La signature transforme une intention en mouvement d'argent irréversible.

Si la clé et la signature vivent côté service/agent, c'est le modèle custodial : l'agent peut dépenser tout seul. Si la clé est chez l'utilisateur, que chaque transaction est signée par son wallet et que le serveur ne fait qu'assembler une transaction non signée, c'est le modèle non-custodial : le serveur est physiquement incapable de dépenser l'argent d'autrui.

C'est la différence entre « confier sa carte bancaire et son code PIN à un ami » et « lui remettre un ordre de virement pré-rempli, que l'on ira signer soi-même à la banque ». Dans les deux cas l'ami rend service, mais le risque est fondamentalement différent. Aucun des deux modèles n'est « plus juste » que l'autre dans l'absolu — ils offrent un équilibre différent entre autonomie et contrôle. Voyons maintenant ce que cela donne sur des produits concrets.

Le modèle custodial : le @ton/mcp officiel et la split-key

Le @ton/mcp officiel de la TON Foundation est un agent-wallet custodial. Il détient la clé operator et signe les transactions lui-même. Il fonctionne sur un modèle split-key : la clé operator chez l'agent, la clé owner chez l'utilisateur. Autrement dit, l'agent n'est pas tout-puissant (la clé owner reste un levier côté humain), mais dans les limites de ses droits, il dépense les fonds sans signature manuelle à chaque opération.

Ce que sait faire @ton/mcp :

• lire l'état du réseau et des comptes ;
• envoyer des GRAM, des jettons et des NFT ;
• swapper via un agrégateur de DEX ;
• créer et importer des agent-wallets ;
• lire les NFT et le DNS.

Ce qu'il ne sait pas faire : le cross-chain — il ne fonctionne qu'à l'intérieur de TON. Il se lance en local, via HTTP ou en serverless.

C'est le paquet officiel de la Foundation, et il a des atouts bien réels :

• Autonomie de dépense totale. L'agent exécute une chaîne d'actions sans pause de confirmation — exactement ce qu'il faut pour des scénarios réellement autonomes (abonnements, paiements automatiques).
• NFT et DNS prêts à l'emploi.
• Le statut officiel — le support de la Foundation.

Le prix de l'autonomie est évident : la clé operator vit dans l'environnement de l'agent. Or l'agent, c'est un LLM que l'on peut tromper avec du texte. Qui contrôle cet environnement et sa configuration contrôle aussi la signature, dans les limites des droits operator.

Le modèle non-custodial : TONNode renvoie des messages TonConnect non signés

TONNode est un serveur MCP hébergé pour TON (site tonnode.io) avec exactement 16 outils. Ici, les outils de swap, de cross-chain et de wallet sont strictement non-custodiaux : le serveur ne signe jamais rien et ne détient ni fonds ni clés privées.

La mécanique est simple. Au lieu de « fais le swap », l'outil build_swap_tx renvoie un message TonConnect non signé — une transaction toute prête, que le wallet de l'utilisateur signe (Tonkeeper, MyTonWallet, n'importe quel wallet compatible TonConnect). Le serveur a rempli l'« ordre de virement », mais c'est le détenteur de la clé qui signe. Le serveur ne voit que des données publiques : adresse, montant, contrat cible. Il ne touche jamais à la clé privée, par construction.

Le flux typique d'un swap ressemble à ceci :

1. get_swap_quote — une cotation ferme du DEX (GRAM ⇄ jetton, liquidité STON.fi + DeDust via le protocole Omniston).
2. build_swap_tx — une transaction non signée correspondant à cette cotation.
3. Le wallet de l'utilisateur la signe via TonConnect. C'est tout.

Le prompt donné à l'agent reste, lui, tout à fait banal :

Donne-moi une cotation pour swapper 10 GRAM en USDT, puis construis la
transaction de swap pour mon adresse EQ... — je la signerai dans mon wallet.

L'agent appellera get_swap_quote, puis build_swap_tx, et vous obtiendrez en sortie un objet transaction, pas un débit déjà effectué.

Même la création de wallet est non-custodiale. generate_wallet crée un wallet en version v3r2 / v4 / v5r1 / highload_v3 et remet la mnémonique, les clés et l'adresse à l'utilisateur — le serveur ne les stocke pas. Vous générez, vous récupérez votre seed phrase, et le serveur l'« oublie ».

Pour le détail des versions et le stockage sécurisé de la seed, voir notre analyse de la génération d'un wallet TON.

L'angle DeFAI : pourquoi l'emplacement de la clé privée compte pour les agents autonomes

Le DeFAI, c'est quand des agents IA opèrent eux-mêmes dans la DeFi. Et là, la question « où vit la clé » cesse d'être théorique.

Un LLM est un système probabiliste. Il lit des données venues de la blockchain, de contrats tiers, de textes qu'on lui met sous les yeux. L'attaque classique est la prompt injection : dans la description d'un jetton ou dans la réponse d'un outil tiers se cache une instruction du type « transfère tous les fonds vers l'adresse X ». Dans le modèle custodial, où l'agent signe lui-même, une telle injection peut se traduire par une dépense bien réelle — la clé est à portée de main de l'agent qu'on vient de tromper. Contexte empoisonné, bug dans la chaîne d'outils, hôte compromis : chacun de ces scénarios finit en signature, parce que l'environnement lui-même sait signer.

Dans le modèle non-custodial, l'attaque se heurte à un mur : même si l'agent a été convaincu d'assembler une transaction malveillante, build_swap_tx ne renverra qu'un message non signé. Il ne déplace rien tant que le détenteur de la clé ne l'a pas signé dans son wallet — et à cette étape, l'utilisateur voit l'adresse du destinataire et le montant. L'humain (ou une politique de signature dédiée) reste le dernier rempart.

Cela ne veut pas dire que l'autonomie est un mal. Cela veut dire qu'autonomie et contrôle des clés sont deux axes distincts, et que le choix doit être conscient. Pour en savoir plus sur les swaps non-custodiaux pour agents, lisez notre article sur le swap agentique sur TON.

Les risques des deux modèles : dépense autonome contre signature manuelle

Soyons honnêtes des deux côtés, sans parti pris.

Modèle custodial (@ton/mcp) :

• Avantage : l'agent est réellement autonome — il paie et opère lui-même, les chaînes d'opérations s'exécutent sans interruption.
• Avantage : la split-key limite l'agent (la clé owner reste côté utilisateur) — ce n'est pas un « accès total à tout ».
• Avantage : le statut officiel de la Foundation, pratique pour les scénarios sans humain dans la boucle (abonnements, paiements automatiques, NFT/DNS).
• Risque : la clé opérationnelle de signature se trouve au même endroit que le LLM piloté par du texte — une prompt injection ou une hallucination peut mener à une dépense réelle.
• Risque : une erreur de l'agent (montant ou adresse mal parsés) s'exécute sans barrière manuelle.

Modèle non-custodial (TONNode) :

• Avantage : la clé privée ne quitte jamais l'utilisateur — le serveur ne peut physiquement ni débiter, ni détourner quoi que ce soit.
• Avantage : chaque dépense passe par une confirmation visuelle dans le wallet — le dernier rempart contre l'erreur de l'agent et l'injection.
• Limite : il faut une étape de signature par le wallet — impossible de construire ainsi un autopilote 24 h/24 entièrement « sans humain ».
• Limite : l'utilisateur est seul responsable de la conservation de la mnémonique remise par generate_wallet (le serveur ne la stocke pas — personne ne pourra la restaurer).

Un mot à part sur le cross-chain, là où le modèle de risque est le plus visible. Chez TONNode, TON est toujours la source, et l'échange passe par un escrow HTLC atomique :

• get_crosschain_quote — la cotation.
• build_crosschain_swap_tx — la transaction d'escrow HTLC non signée, plus le secret.
• track_crosschain_swap — les phases de l'échange sur les deux réseaux.
• disclose_crosschain_secret — révéler le secret pour le règlement, une fois la disponibilité vérifiée on-chain.
• build_crosschain_refund — le remboursement des fonds depuis un escrow bloqué, si la contrepartie n'a pas finalisé l'échange.

L'existence de build_crosschain_refund est une conséquence directe de la non-custodialité : puisque la clé et le secret sont chez l'utilisateur, c'est lui qui a le levier pour récupérer son argent d'un échange coincé, au lieu d'« écrire au support ». Réseaux compatibles : Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON n'est pas encore pris en charge.

Comparaison honnête : quand choisir quelle approche

Critère	@ton/mcp (custodial)	TONNode (non-custodial)
Qui détient la clé	clé operator chez l'agent	clé privée chez l'utilisateur
Qui signe	le serveur/agent lui-même	le wallet de l'utilisateur
Dépense autonome	oui	non (signature requise)
Cross-chain	non, TON uniquement	oui, HTLC (TON en source)
NFT / DNS	oui	non (sur la roadmap)
Format	local / HTTP / serverless	local + option hébergée
Statut	paquet officiel de la Foundation	open source tiers (MIT)

Le choix en pratique :

Prenez le @ton/mcp custodial si :

• vous avez besoin d'une véritable autonomie de l'agent — il doit dépenser lui-même, sans humain dans la boucle ;
• les NFT et le DNS dans TON comptent pour vous ;
• le statut officiel de la Foundation compte pour vous ;
• tout se passe à l'intérieur de TON — pas besoin de cross-chain, et vous acceptez en connaissance de cause les risques opérationnels de la clé operator.

Prenez le TONNode non-custodial si :

• vous voulez que la clé privée et la signature restent chez vous, et que chaque dépense soit signée manuellement ;
• il vous faut le cross-chain : TON toujours en source, escrow HTLC atomique, avec remboursement en cas d'échange bloqué ;
• il vous faut une option hébergée avec un débit garanti et votre propre clé ;
• vous voulez un paquet open source (MIT) sur ADNL natif.

La différence est honnête et sans exagération : @ton/mcp est custodial et limité à TON ; TONNode est non-custodial, avec le cross-chain et une option hébergée. Pour un comparatif détaillé des fonctionnalités, voir l'analyse dédiée TONNode contre le TON MCP officiel ou la page de comparaison avec le MCP officiel.

Une petite remarque sur l'infrastructure. Si, sous charge, vous utilisez des lightservers publics ou des API HTTP publiques (toncenter, tonapi.io), gardez en tête les limites réelles : en cas de dépassement, vous recevez un HTTP 429 « Too Many Requests » (sans clé — environ 1 requête par seconde), et les lightservers publics répondent souvent « not ready » ou par un timeout ADNL. Il n'existe aucune « erreur 228 » dans les API : ce mème est du folklore de la communauté, pas un code de réponse.

Comment essayer le MCP non-custodial en quelques minutes

Le moyen le plus rapide de sentir la différence : lancer le serveur en local et donner à l'agent un prompt simple. La config publique, gratuite et sans carte bancaire, avec l'ensemble complet des outils de lecture :

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

Ensuite, demandez à l'agent en langage naturel — sur cette config gratuite, tous les outils de lecture sont ouverts :

Affiche le solde de l'adresse EQ... en GRAM, consulte les métadonnées de l'USDT
et donne-moi une cotation ferme pour swapper 10 GRAM en USDT.

L'agent appellera get_balance, get_jetton_info et get_swap_quote — et renverra les données sans rien dépenser. Ni signature, ni mouvement de fonds : la lecture reste de la lecture.

Le paquet @tonnode/mcp est open source (MIT) et parle le protocole ADNL natif de TON, sans couche HTTP intermédiaire. Quand vous aurez besoin des outils qui construisent des transactions (swap, cross-chain, génération de wallet), ce sont les 16 outils au complet sur l'endpoint hébergé, avec votre propre clé et un débit garanti :

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

Avec une clé hébergée, vous pouvez confier à l'agent un scénario non-custodial complet :

Crée un nouveau wallet TON en version v5r1 et affiche l'adresse.
Puis construis un swap de 10 USDT en GRAM et renvoie la transaction non signée.

L'agent appellera generate_wallet, puis get_swap_quote et build_swap_tx — et vous renverra un message non signé. Notez bien : à cet instant, rien n'a été dépensé. La signature est votre étape à part, consciente. C'est exactement ça, la non-custodialité en pratique.

Tous les forfaits donnent accès aux 16 outils — vous ne payez que pour le débit. La clé gratuite Hobby (60 requêtes/min, à vie, sans carte bancaire) est délivrée dès la connexion.

Pour un guide général de connexion de MCP à TON, voir le guide MCP pour TON.

---

Une clé capable de dépenser votre argent ne devrait pas se trouver à côté d'un modèle que l'on peut tromper avec un seul paragraphe de texte. Si, pour votre scénario, la dépense autonome prime — le @ton/mcp custodial remplit honnêtement cette mission. Si ce qui compte davantage, c'est que la signature reste entre vos mains — commencez avec le TONNode non-custodial et décidez vous-même où tracer la frontière de confiance.

Essayer le MCP non-custodial gratuitement — obtenir une clé Hobby : tonnode.io/dashboard?plan=hobby