Aller au contenu
Financial Context Wiki

Échéance, slippage et calldata d'un swap : vérifications avant signature

Apprenez à décoder un appel de swap sur un DEX et à vérifier routeur, fonction, limites de montant, route, destinataire et échéance avant de signer.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil ni une recommandation d’investissement. Tout investissement peut entraîner des pertes.

Réponse directe

Avant de signer un swap sur un DEX, vérifiez la chaîne, le contrat destinataire, la fonction décodée, les adresses des jetons, la limite d’entrée ou de sortie, la route, le bénéficiaire et toute échéance. Le pourcentage de « slippage » affiché par une interface n’est pas lui-même une instruction on-chain. Il sert généralement à calculer une limite telle que amountOutMin ou amountOutMinimum pour un swap exact-input, ou amountInMax ou amountInMaximum pour un swap exact-output.

L’échéance est une protection temporelle, pas une garantie de prix. Si le routeur la contrôle et que la transaction s’exécute après, l’appel devrait être annulé par un revert. Avant cette échéance, la transaction peut toujours s’exécuter à tout prix autorisé par la limite de montant. Une échéance lointaine prolonge la durée d’utilisation de l’autorisation ; une échéance trop proche augmente le risque d’expiration avant inclusion.

Calldata n’est pas auto-descriptive. Décodez-la avec l’ABI vérifiée du contrat exact sur la chaîne choisie, y compris les multicalls ou commandes Universal Router imbriqués. Si le portefeuille ne présente pas de champs décodés fiables, ne déduisez pas leur sens de la seule position des octets ou d’une base de noms de fonctions.

Fonctionnement

Décoder l’appel réel

Selon l’ABI de Solidity, les premiers 4 bytes de calldata forment le sélecteur de fonction et les arguments encodés commencent au cinquième octet. Un sélecteur peut entrer en collision ou être mal étiqueté : confrontez-le donc à l’ABI du contrat destinataire vérifié. Un proxy, agrégateur ou routeur peut encapsuler le swap dans multicall, execute ou une autre fonction ; décodez chaque charge imbriquée capable de transférer des jetons ou de changer le bénéficiaire final.

Dans un swap exact-input, l’entrée est fixe et le champ de protection définit la sortie minimale acceptable. Dans un swap exact-output, la sortie visée est fixe et le champ de protection plafonne l’entrée. Une limite nulle ou anormalement large peut supprimer toute protection de prix utile. Les décimales du jeton comptent : associez chaque adresse à ses décimales et à son symbole corrects avant de comparer les entiers bruts.

Vérifier route, bénéficiaire et value

Confirmez que la route commence par le jeton dépensé et finit par celui attendu. Examinez les jetons intermédiaires, frais de pools et commandes qui enveloppent, désenveloppent, récupèrent ou transfèrent des soldes. Le bénéficiaire doit être le portefeuille prévu ou un contrat dont le comportement est compris. Vérifiez aussi la value native de la transaction ; elle peut être distincte des montants ERC-20 encodés dans calldata.

Repérer l’échéance

L’emplacement de l’échéance dépend de la version du routeur. Les fonctions de routeur de type Uniswap V2 comprennent un argument deadline, tout comme les structures du ISwapRouter original d’Uniswap V3. Universal Router propose execute(commands, inputs, deadline) ainsi qu’une surcharge sans échéance. Ne supposez donc pas que chaque swap a une échéance ni qu’elle figure toujours dans les mêmes paramètres imbriqués.

L’échéance est normalement comparée à l’horodatage du bloc utilisé pendant l’exécution. Elle n’annule pas une transaction en attente, ne garantit pas une inclusion rapide et ne protège pas contre un prix défavorable toujours compris dans la limite. Pour annuler, l’émetteur doit utiliser le mécanisme de remplacement de sa chaîne et de son portefeuille ; le remplacement n’est plus garanti une fois l’original inclus.

Exemple détaillé

Un devis prévoit 10,000 USDC pour un swap exact-input et l’utilisateur choisit 1% de slippage. Sans tenir compte des frais déjà inclus dans le devis, le minimum attendu est 9,900 USDC. USDC utilisant 6 decimals, l’entier brut de cette limite est 9900000000.

Or l’appel décodé contient amountOutMinimum = 9000000000, soit 9,000 USDC. Il autorise jusqu’à 10% de moins que le devis, et non 1%. Le bénéficiaire est aussi une adresse inconnue et l’échéance se situe plusieurs heures plus tard. Une seule de ces anomalies suffit à rejeter la demande et à la reconstruire dans une interface fiable. Simulez ensuite la transaction non signée exacte sur un état récent, puis revérifiez la charge décodée avant de signer.

Liste de contrôle et risques

  • Confrontez la chaîne choisie et l’adresse du routeur ou proxy aux registres de déploiement officiels du protocole.
  • Décodez avec l’ABI du contrat vérifié ; développez les appels imbriqués et commandes du routeur plutôt que de contrôler uniquement la fonction externe.
  • Vérifiez adresses, sens, décimales, montant fixe, limite protectrice, route, niveaux de frais, bénéficiaire et value native.
  • Convertissez l’échéance en heure absolue et décidez si la fenêtre restante est intentionnelle. Traitez l’absence d’échéance comme un choix de conception à examiner séparément.
  • Simulez la transaction exacte depuis l’adresse signataire sur un état récent. Une simulation réussie est une preuve pour cet état, pas une garantie d’inclusion ou d’exécution finale.
  • Contrôlez séparément les approbations ou permissions Permit2. De bonnes limites de swap ne sécurisent pas une autorisation de jetons illimitée ou malveillante.
  • Des limites serrées peuvent provoquer un revert lors d’un mouvement normal ; des limites larges augmentent les risques de prix d’exécution et d’attaque sandwich. Une transaction on-chain annulée peut encore consommer du gas.

Idées reçues

Mythe : le pourcentage de slippage affiché est signé

La charge signée contient généralement des limites de montant calculées depuis ce réglage. Vérifiez les entiers réels et les décimales du jeton ; une étiquette correcte ne prouve pas que calldata utilise la même tolérance.

Mythe : chaque swap utilise amountOutMin et deadline

Les noms et emplacements varient selon le routeur et la fonction. Les swaps exact-output protègent le côté entrée, et certains points d’entrée omettent l’échéance ou la placent dans l’appel externe.

Mythe : une échéance empêche un mauvais prix

Elle limite seulement le moment d’exécution si le code appelé l’applique. La protection du prix vient de la limite de montant, qui autorise malgré tout toute exécution à l’intérieur de cette limite.

Mythe : décoder la fonction externe suffit

Les agrégateurs et routeurs universels peuvent contenir plusieurs appels, permissions de jetons, transferts et commandes de nettoyage. Le bénéficiaire ou montant important pour la sécurité peut se trouver dans une charge imbriquée.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...