Comment échanger et bridger des tokens avec MetaMask Agent Wallet : 9 conseils clés

MetaMask Agent Wallet échange des tokens sur la même chaîne et les transfère entre chaînes via l'ensemble de commandes mm swap. Un trader demande à son agent d'échanger ou de déplacer des tokens en langage naturel, et l'agent achemine cette demande vers les commandes qui récupèrent un devis, comparent les routes et exécutent l'opération. Contrairement au trading de contrats à terme perpétuels sur Agent Wallet, où seul le dépôt de garantie est une transaction EVM vérifiée par MetaMask, un swap ou un bridge est lui-même la transaction — ce qui change ce qu'un trader doit préciser en amont et ce que les contrôles au niveau du portefeuille MetaMask voient réellement.

C'est à ce moment de transfert que le trading piloté par agent diffère d'une navigation dans une interface. Une seule phrase peut contenir de nombreuses hypothèses implicites sur la tolérance au slippage, le routage et la chaîne de destination. Cet article couvre les détails qu'il vaut mieux expliciter.

Il s'agit d'un guide sur la mécanique du trading, pas d'une introduction aux swaps. Pour comprendre le fonctionnement du slippage et comment calibrer une tolérance, voir qu'est-ce que le slippage. Pour comparer les ordres au marché et les ordres à cours limité, notamment en quoi une tolérance au slippage est l'équivalent AMM le plus proche d'un ordre à cours limité, voir les types d'ordres en crypto. Pour comprendre les différences entre DEX, agrégateurs et swaps natifs au portefeuille, voir meilleures plateformes de swap crypto en 2026. Pour la catégorie de portefeuille elle-même, voir qu'est-ce qu'un portefeuille agentique et comment fonctionnent les portefeuilles agentiques. Pour calibrer les dépôts de garantie et savoir quelle étape d'un trade MetaMask vérifie réellement dans une autre classe d'actifs, voir comment trader des perps avec MetaMask Agent Wallet.

La surface de swap, décortiquée

Voici les commandes sur lesquelles s'appuie un workflow de swap ou de bridge. Connaître cette surface facilite la formulation d'une demande qui aboutit comme prévu.

Source : Référence des commandes MetaMask Agent Wallet

Avec cette compréhension de base, voici 9 conseils pour utiliser MetaMask Agent Wallet afin d'échanger et de transférer des tokens, y compris des actions tokenisées et d'autres actifs (souvent appelés real world assets ou RWAs).

1. Demandez d'abord un devis, et considérez « indisponible » comme une réponse normale

mm swap quote évalue un trade sans le soumettre. mm swap execute peut également prendre les mêmes paramètres de swap directement et effectuer l'évaluation puis l'exécution en un seul appel, mais exécuter le devis séparément en premier est la valeur par défaut la plus sûre : c'est le seul moyen de voir le prix, la route et les frais avant toute signature. Lorsque le bridge ou l'agrégateur DEX sous-jacent ne trouve pas de route, la CLI ne renvoie pas d'erreur bloquante — elle retourne un résultat kind: "unavailable" avec un reason (tel que AMOUNT_TOO_LOW, SLIPPAGE_TOO_HIGH ou NO_QUOTES), un message et un hint.

Cette distinction est importante pour un agent agissant sur une instruction. Un devis indisponible est une réponse exploitable — l'agent peut élargir le slippage, ajuster le montant ou essayer un token différent — et non un échec à rapporter tel quel. La seule exception est le signal transitoire QUOTE_RETRY, qui est une véritable erreur bloquante méritant une nouvelle tentative telle quelle. Dans tous les cas, un agent ne doit jamais fabriquer ou réutiliser un quoteId pour appeler execute après qu'un devis est revenu indisponible ou expiré ; l'étape d'exécution échoue proprement, mais aucune transaction n'est soumise sur une supposition.

2. Définissez une tolérance au slippage plutôt que de faire confiance à la valeur par défaut

mm swap quote accepte --slippage en pourcentage de 0 à 100, et utilise 0,5 % par défaut lorsqu'il est omis. Cette valeur par défaut est un compromis raisonnable, mais elle s'applique à chaque trade quelle que soit la liquidité du token.

Comme l'explique qu'est-ce que le slippage, une tolérance serrée protège contre des exécutions défavorables mais entraîne davantage d'échecs de devis en conditions volatiles, tandis qu'une tolérance large remplit plus fiablement à un prix moins avantageux. Une instruction tradant une paire à forte liquidité comme ETH vers USDC peut raisonnablement s'appuyer sur la valeur par défaut de 0,5 % ; une instruction tradant un token à faible liquidité a tout intérêt à préciser explicitement une tolérance, dans un sens ou dans l'autre, plutôt que d'hériter d'un chiffre qui n'a jamais été choisi en tenant compte de ce token.

3. Les bridges cross-chain nécessitent une chaîne de destination, et le refuel a un mode d'échec spécifique

L'ajout de --to-chain-id est ce qui transforme un swap sur la même chaîne en bridge cross-chain ; lorsqu'il est omis, la destination prend par défaut la chaîne source. --to-address permet à la sortie d'atterrir ailleurs que dans le portefeuille du signataire, mais uniquement sur les routes cross-chain — il n'a aucun effet lorsque la chaîne source et la chaîne de destination sont identiques.

--refuel intègre une petite quantité de gas natif de la chaîne de destination dans un devis cross-chain, ce qui est utile lorsque le trader ne détient pas encore de token de gas sur la chaîne de destination. Il est optionnel et réservé au cross-chain, et il présente un mode d'échec spécifique : l'utiliser lorsque le token de destination est déjà l'actif de gas natif de la chaîne de destination (par exemple, bridger de l'ETH vers de l'ETH sur Arbitrum) retourne NO_QUOTES. Une instruction comme « bridge des USDC de Base vers Arbitrum et assure-toi que j'ai un peu d'ETH là-bas pour travailler » décrit exactement ce flag ; une instruction bridgeant directement vers le token natif d'une chaîne n'en a pas besoin et échouera si on l'ajoute quand même.

4. Comparez les routes délibérément, puis exécutez une route spécifique

--all-quotes retourne toutes les routes candidates classées avec la route recommandée marquée, classées selon --strategy (valeurs séparées par des virgules : cost, speed, impact, output ; la valeur par défaut est cost,speed). Comparer les routes et exécuter un --quote-id spécifique ensuite est un processus en deux étapes, et c'est délibéré : --all-quotes ne peut pas être combiné avec --yes, donc une instruction demandant à voir toutes les routes et à ignorer la confirmation demande deux choses que la CLI ne fera pas dans le même appel.

Les artefacts de devis sont automatiquement supprimés après 24 heures, donc une route intéressante aujourd'hui n'est pas nécessairement valide pour être exécutée la semaine prochaine.

5. L'exécution sans gas et les approbations groupées se produisent automatiquement, sans demande explicite

Lorsque le solde natif du portefeuille ne peut pas couvrir le gas, mm swap execute achemine automatiquement les devis éligibles incluant le gas via un relais sans gas utilisant EIP-7702, déduisant les frais de relais du token échangé lui-même. Il n'y a pas de flag pour cela ; c'est un mécanisme de repli que la CLI applique d'elle-même aux devis éligibles, et non une garantie sur chaque swap à faible gas.

Par ailleurs, sur les chaînes et comptes éligibles, la CLI combine l'approbation ERC-20 et le trade en un seul appel atomique via l'exécution par lots ERC-7821, que la réponse signale comme route: "erc7821" lorsque cela se produit. Lorsque le batching n'est pas disponible, la CLI revient à une soumission séquentielle. Aucun de ces comportements n'a besoin d'être demandé dans une instruction, mais les deux méritent d'être connus lors de la lecture de ce qui s'est réellement exécuté — un swap groupé sans gas et un swap en deux étapes avec gas peuvent tous deux satisfaire la même demande, et les champs de réponse permettent de distinguer lequel s'est produit. REMARQUE : L'exécution sans gas peut entraîner des frais plus élevés.

6. Sachez que c'est le swap lui-même, et non une étape séparée, que le mode Guard vérifie

C'est le schéma inverse du trading de contrats à terme perpétuels sur Agent Wallet, où l'ouverture ou la fermeture d'une position Hyperliquid se produit hors chaîne et seul le dépôt de garantie est une transaction EVM évaluée par MetaMask. Un swap ou un bridge ne présente pas une telle séparation : mm swap execute soumet le trade directement en tant que transaction EVM, c'est donc la transaction que la limite de sortie glissante sur 24 heures du mode Guard mesure, et c'est ce que l'analyse des menaces de MetaMask ainsi que les listes d'autorisation de réseaux, d'adresses et de tokens évaluent directement.

Un swap de 2 000 $ compte comme une sortie de 2 000 $ sur la limite glissante dès sa confirmation, qu'il s'agisse d'un trade sur la même chaîne ou d'un bridge cross-chain. S'il dépasse la limite, ou si l'analyse des menaces le signale, le job se met en pause dans l'état AWAITING_MFA pour une approbation par authentification à deux facteurs — une notification push MetaMask Mobile pour les connexions par QR code, ou un lien par e-mail pour les connexions via navigateur — et l'agent ne peut pas continuer jusqu'à ce que quelqu'un réponde. Cela s'applique au mode server-wallet ; les modes de trading ne s'appliquent pas aux configurations bring-your-own-wallet. La conséquence pratique : la discipline de dimensionnement sur une instruction de swap n'est pas une habitude séparée de ce que le portefeuille applique déjà, comme c'est le cas avec un dépôt de perps — le montant du swap lui-même est le chiffre que le mode Guard surveille.

7. Ne relancez pas aveuglément execute après un timeout

Un swap peut se mettre en pause pour une authentification à deux facteurs avant qu'un hash de transaction existe, entrant dans un état AWAITING_MFA avec un ID de polling associé. Si le poll MFA expire sur un leg de relais sans gas ou un leg séquentiel de server-wallet, cela se manifeste comme RELAY_TIMEOUT ou JOB_TIMEOUT, tous deux portant le même conseil de récupération : exécutez mm wallet requests watch pour récupérer le hash, et n'appelez pas à nouveau execute tant que le job original peut encore se terminer.

Relancer execute dans cette fenêtre risque une deuxième soumission redondante plutôt que de résoudre quoi que ce soit. Approuver la demande en attente et surveiller le job est la bonne voie de récupération.

8. Il n'y a pas de simulation à sec pour les swaps — comparer les devis est l'équivalent le plus proche

Contrairement à mm perps open, qui accepte --dry-run pour valider un ordre sans le signer, mm swap execute n'a pas de mode de prévisualisation équivalent. La chose la plus proche d'une répétition d'un swap est de demander un devis et, pour tout ce qui sort de la routine, de récupérer --all-quotes pour voir l'ensemble complet des routes candidates avant de s'engager sur l'une d'elles. Aucune ne remplace une simulation à sec au sens strict — un devis peut toujours devenir obsolète, et les conditions de marché peuvent évoluer entre l'évaluation et l'exécution — mais c'est l'outil disponible pour détecter une instruction mal formulée avant qu'elle ne signe quoi que ce soit.

9. Vérifiez la prise en charge de la chaîne et du sans-gas avant de demander un devis

mm chains list retourne un champ features par chaîne, qui indique si swap y est pris en charge, ainsi qu'un flag relaySupported indiquant si le relais sans gas est disponible. Vérifier cela avant de demander un devis évite un aller-retour inutile : une demande de devis sur une chaîne sans prise en charge du swap, ou une hypothèse que l'exécution sans gas s'activera sur une chaîne où le relais n'est pas pris en charge, ne se manifeste comme une erreur qu'après coup plutôt que comme quelque chose qui aurait pu être écarté en amont.

Cela s'associe à deux codes d'erreur spécifiques aux swaps à reconnaître : GASLESS_UNSUPPORTED signifie que le relais n'est pas disponible sur cette chaîne, et INSUFFICIENT_GAS signifie que le solde natif du portefeuille ne peut pas couvrir le gas et qu'aucun mécanisme de repli sans gas ne s'est appliqué. Les deux renvoient à la même question de prise en charge de la chaîne à laquelle mm chains list répond en amont.

Ce que Agent Wallet ne fait pas pour les swaps

Être clair sur les limites est plus utile que de laisser entendre qu'elles sont plus larges.

Il n'y a pas de swap récurrent ou planifié intégré — pas de fonctionnalité native de dollar-cost averaging, pas de rééquilibrage automatique d'un portefeuille, et pas de carnet d'ordres à cours limité permanent comme pourrait en offrir une bourse centralisée. Chaque appel mm swap est un cycle unique d'évaluation et d'exécution ; tout ce qui est récurrent est un script ou une boucle d'agent appelant ce cycle selon un calendrier, et non une fonctionnalité du portefeuille. Les traders souhaitant ce type de logique permanente peuvent la construire comme un plugin, une fonctionnalité bêta permettant à un package npm installé d'ajouter de nouvelles commandes à la CLI sous des capacités soumises à consentement, mais c'est une voie à construire soi-même plutôt qu'une fonctionnalité intégrée.

Il n'y a pas de garantie de meilleure exécution cross-DEX au-delà de ce que l'étape de devis rapporte. --all-quotes et --strategy font remonter des candidats classés, mais le classement reflète les routes disponibles au moment du devis, et non la garantie qu'un meilleur prix n'apparaîtra pas quelques instants plus tard.

La protection contre le slippage est un plafond sur le mouvement de prix acceptable, et non une protection contre le fait que le trade sous-jacent soit une mauvaise idée. Un swap qui respecte sa tolérance au slippage peut tout de même s'exécuter à un prix que le trader n'aurait pas choisi avec le recul ; la tolérance ne fait que limiter l'écart entre le prix d'exécution et le devis.