Un bot de trading Uniswap v4 doit identifier et comprendre un pool donné avant de pouvoir automatiser une opération. La paire de jetons ne suffit pas. La configuration des frais, l’espacement des ticks et l’adresse du hook font également partie de l’identité du pool, tandis que la chaîne concernée et le gestionnaire déployé définissent le contexte dans lequel cette identité a un sens.
Ce point est important, car les hypothèses familières issues des teneurs de marché automatisés antérieurs ne se transposent pas telles quelles. Un pool v4 n’est pas nécessairement un contrat de paire distinct détenant ses propres soldes de jetons faciles à interpréter. Les hooks peuvent ajouter des comportements, et un champ de frais affiché ne décrit pas toujours les frais actuels qui seront facturés lors du prochain échange. Ce guide explique comment évaluer ces différences sans supposer que tous les pools ou hooks sont pris en charge. Tous les exemples chiffrés sont fictifs.
Identité des pools pour un bot de trading Uniswap V4
Pour un bot de trading Uniswap v4, l’identité d’un pool commence par la bonne chaîne et le bon déploiement de PoolManager. Dans ce contexte, la clé du pool contient les devises dans leur ordre défini, le champ des frais, l’espacement des ticks et l’adresse du hook. Une modification de l’un de ces champs peut désigner un autre pool, même lorsque les deux symboles de jetons familiers restent identiques.
Enregistrez l’identité complète dans la décision de trading, plutôt que de la reconstituer plus tard à partir d’un résultat de recherche. Le graphique d’un pool ne doit pas autoriser une transaction sur un autre pool qui échange par hasard les mêmes actifs.
Par exemple, deux marchés hypothétiques échangent les jetons A et B. L’un applique des frais fixes sans comportement supplémentaire de hook. L’autre applique des frais dynamiques et utilise un hook doté de sa propre configuration. Les considérer comme interchangeables pourrait associer les recherches sur le premier marché à l’exécution sur le second.
Le guide du marché Uniswap explique le processus de découverte dans son ensemble. Avec V4, cet enregistrement de découverte doit conserver plus que le nom d’une paire avant de pouvoir devenir une instruction exécutable.
Comprendre le modèle comptable singleton
PoolManager conserve l’état de plusieurs pools v4 au sein d’une architecture de contrat partagée. Examiner le solde de jetons du gestionnaire ne permet donc pas d’isoler les réserves disponibles pour un pool précis. Un ancien processus fondé sur la lecture des soldes d’un contrat de paire distinct nécessite une autre interprétation.
Une analogie utile est celle d’un entrepôt desservant plusieurs comptes indépendants. Le stock total dans le bâtiment ne révèle pas la quantité allouée à un client. Cette analogie a ses limites, mais elle illustre pourquoi la garde partagée et la comptabilité des pools doivent être examinées séparément.
Le bot doit utiliser l’état propre au pool et une méthode de cotation prise en charge. Il doit aussi consigner l’interprétation utilisée, en particulier lorsque les hooks peuvent influer sur la comptabilité au-delà d’une simple lecture de la liquidité du cœur du protocole.
Un solde inhabituellement élevé du gestionnaire ne prouve pas que l’opération envisagée dispose d’une liquidité profonde. Si un tableau de bord présente ce total comme la profondeur disponible d’un nouveau marché de jetons, sa précision apparente peut masquer une erreur comptable élémentaire.
Distinguer l’initialisation de la liquidité utilisable
Un pool peut être initialisé avant de disposer d’une liquidité utilisable. L’initialisation établit un état initial ; elle ne prouve pas qu’un ordre de la taille prévue peut être exécuté à un prix acceptable. Cette distinction compte pour les systèmes qui réagissent aux pools nouvellement observés.
La liquidité concentrée introduit une autre distinction. Le capital associé à un pool n’est pas nécessairement actif au prix actuel. Une position située en dehors de la plage pertinente ne peut pas être assimilée à la profondeur immédiatement disponible autour de l’échange envisagé.
Supposons qu’un marché fictif affiche une valeur totale déposée importante, mais qu’un achat de 200 unités de cotation produise un prix moyen nettement moins favorable qu’un achat de 20. La cotation du petit montant ne valide pas l’opération plus importante. Le bot a besoin de la quantité prévue, des conditions actuelles de la plage et du montant final attendu à la réception.
Le guide de l’exécution précoce sur Uniswap explique pourquoi la vitesse de découverte ne suffit pas à établir la possibilité de négocier. Une implémentation v4 doit distinguer explicitement l’observation de la création d’un pool, l’observation d’un état doté de fonds et une cotation actuellement exécutable.
Vérifications des hooks pour un bot de trading Uniswap V4
Les vérifications des hooks d’un bot de trading Uniswap v4 portent à la fois sur les fonctions de rappel autorisées et sur le comportement réel. Un hook peut intervenir à des étapes définies des opérations du pool. Savoir quelles fonctions de rappel sont activées indique à la personne qui examine le système où une logique supplémentaire peut s’exécuter ; cela ne prouve pas que cette logique est sans danger ou économiquement favorable.
Lisez l’implémentation vérifiée et la configuration pertinente du hook concerné. Un nom de projet reconnaissable ou une adresse copiée dans un ancien tutoriel ne prouve pas que la route actuelle utilise le déploiement examiné.
Distinguez aussi l’adresse du hook des comportements accessibles par son intermédiaire. L’adresse du hook d’un pool fait partie de son identité, mais une adresse fixe ne prouve pas à elle seule que chaque implémentation, paramètre d’administration ou dépendance derrière cette adresse est immuable.
Un dossier de compatibilité pertinent indique quels comportements des hooks le bot comprend et lesquels l’amènent à refuser l’exécution. La prise en charge d’un pool simple n’implique pas automatiquement celle de n’importe quelle logique de hook. Une condition non prise en charge doit rester visible, plutôt que de disparaître derrière une indication générique de réussite de la cotation.
Considérer les frais dynamiques comme un état actuel
V4 distingue les pools configurés avec des frais fixes de ceux configurés avec des frais dynamiques. Pour un pool dynamique, les frais pertinents peuvent dépendre de mises à jour ou du comportement du hook. Le champ des frais servant à l’identification ne doit pas être interprété comme s’il représentait toujours le taux exact de la prochaine transaction.
Cela modifie la gestion du cache. Une clé de pool peut rester inchangée alors que l’état des frais ayant une incidence économique évolue. Un cache indexé uniquement par les deux adresses de jetons peut manquer à la fois le bon pool et les conditions d’exécution actuelles.
Prenons une comparaison fictive dans laquelle les conditions économiques avant frais sont par ailleurs égales. La route A facture deux unités de coût d’échange et cinq unités de dépenses réseau. La route B facture quatre unités de coût d’échange et une unité de dépenses réseau. Leurs coûts totaux sont respectivement de sept et cinq unités. Les frais d’échange affichés les plus bas ne donnent pas la route complète la moins chère.
L’exemple exclut l’impact sur le prix et les comportements supplémentaires afin d’isoler le calcul. Une comparaison réelle doit inclure chaque coût compris et le montant final attendu sur le compte, et pas seulement un champ de frais mis en avant.
Définir ce qu’une cotation inclut réellement
Une cotation doit préciser la quantité en entrée, l’estimation en sortie, la route, la référence d’état et le traitement des coûts pertinents. Si un hook peut introduire des mouvements de jetons ou des restrictions supplémentaires, déterminez si la méthode de cotation les modélise. Un chiffre renvoyé par une interface générale n’est pas automatiquement une prévision économique complète.
Distinguez le montant coté en sortie du montant reçu utilisable. Ces valeurs peuvent différer lorsque le comportement du jeton ou des frais propres à la route affectent le compte destinataire. Le bot doit savoir quelle valeur est encadrée par sa protection de sortie minimale.
Imaginez une cotation de 10 000 unités qui devient 9 700 unités utilisables après une déduction modélisée. Comparer cette route à une autre qui livre 9 850 unités utilisables exige des définitions cohérentes. Classer la première d’après son chiffre initial de 10 000 reviendrait à comparer des étapes différentes de l’exécution.
Lorsque l’inclusion de certains éléments est incertaine, signalez cette incertitude et excluez la route de l’exécution automatique. Répéter plus fréquemment la même cotation non prise en charge n’améliore ni son périmètre ni sa fiabilité.
Lire un ensemble d’états cohérent
Une décision de trading combine l’état du pool, la configuration du hook, les métadonnées des jetons, la capacité du portefeuille et les autorisations de la route. Lire ces éléments à des moments très éloignés peut produire un ensemble de faits qui n’ont jamais coexisté. Des interrogations plus fréquentes ne remplacent pas la compréhension de leurs relations.
Par exemple, une observation des frais mise en cache peut précéder une mise à jour administrative tandis que la cotation de liquidité lui succède. L’explication qui en résulte pourrait attribuer un montant de sortie au mauvais régime de frais, même si l’échange lui-même réussit.
Conservez les références d’état et les heures d’observation avec la décision. Si l’infrastructure prise en charge ne peut pas fournir une vision suffisamment cohérente pour un hook donné, le bot peut réduire son univers pris en charge ou exiger une nouvelle étape de vérification.
Le guide de l’API Ethereum explique pourquoi une réponse constitue un élément de preuve daté plutôt qu’une vérité permanente. Pour v4, ce principe s’applique à l’état supplémentaire introduit par un hook comme aux soldes ordinaires et au prix du pool.
Limites d’exécution d’un bot de trading Uniswap V4
Les limites d’exécution d’un bot de trading Uniswap v4 doivent lier la route réelle à l’intention autorisée. Les champs pertinents comprennent les actifs, le contexte exact du pool, le montant à dépenser, le destinataire et le montant reçu acceptable. Une condition d’expiration est utile lorsque le routeur choisi en prend une en charge ; il ne faut pas en inventer une comme s’il s’agissait d’une propriété universelle de chaque opération du cœur du protocole.
Distinguez les intentions à montant d’entrée exact de celles à montant de sortie exact. Dépenser exactement 100 unités en exigeant au moins 9 000 jetons diffère d’obtenir exactement 9 000 jetons en autorisant une dépense allant jusqu’à 104 unités. Une interface utilisateur ne doit pas convertir silencieusement une instruction en l’autre.
Supposons qu’une cotation à montant d’entrée exact estime 12 000 jetons et que le minimum choisi soit de 11 640. Cela autorise 360 jetons de moins, soit 3 % sous l’estimation. Cela ne promet pas une exécution au montant estimé et ne plafonne pas toutes les pertes futures possibles sur la position acquise.
Conservez aussi des limites de position en dehors de la cotation. Une route techniquement valide peut tout de même enfreindre les règles d’exposition du compte lorsque les avoirs existants et les engagements non résolus sont inclus.
Recommandez et gagnez des USDC
Recommandez et gagnez des USDCNotre programme d’affiliation paie en temps réel.
Identifier précisément la monnaie native et les jetons enveloppés
V4 prend en charge la représentation de la monnaie native ; un bot doit donc distinguer l’ETH natif d’un jeton enveloppé, même lorsque les deux correspondent au même actif sous-jacent. La route et la comptabilité doivent identifier la forme dépensée, reçue ou convertie.
Cette distinction influe sur les fonds disponibles. Un compte possédant assez de jetons enveloppés pour une opération peut malgré tout manquer de monnaie native pour les dépenses réseau. À l’inverse, réserver toute la monnaie native comme montant d’entrée de l’opération peut laisser une capacité insuffisante pour le chemin d’exécution prévu.
Utilisez des catégories comptables distinctes pour le principal de l’opération, les mouvements d’enveloppement ou de désenveloppement et les coûts réseau. Un transfert de valeur entre les formes native et enveloppée ne doit pas apparaître automatiquement comme un gain de trading.
Dans un exemple fictif, un compte commence avec 0,30 unité native et en réserve 0,02 pour les besoins opérationnels prévus. Selon cette règle, son budget disponible pour négocier en monnaie native est au maximum de 0,28, avant les autres engagements. Une proposition de 0,29 dépasse cette limite, même si une vérification du seul solde indique que les fonds sont suffisants.
Associer les autorisations à l’adresse réellement autorisée à dépenser les jetons
Le pool, le hook, le routeur et le bénéficiaire de l’autorisation de dépense ne sont pas des rôles interchangeables. Un bot doit expliquer quel composant peut déplacer les jetons de l’utilisateur et pourquoi cette autorisation est nécessaire pour le chemin choisi. Reconnaître le pool ne valide pas une demande d’approbation sans rapport avec lui.
Examinez la portée de l’autorisation séparément de la taille de l’opération. Un achat prévu de 100 unités ne justifie pas de supposer qu’une autorisation de dépense bien plus élevée présente la même exposition pratique. Le fait que le compte conserve ses clés ne supprime pas non plus les pouvoirs déjà accordés à un autre contrat.
Le guide des autorisations ERC-20 explique la distinction fondamentale concernant les autorisations de dépense. Appliquez-la à l’adresse réellement autorisée à dépenser les jetons qu’utilise la route v4 prise en charge, plutôt que d’approuver n’importe quelle adresse apparaissant dans une invite d’interface commode.
Les changements d’autorisation ont également besoin de leur propre statut. Une approbation confirmée n’est pas un achat réalisé. Si l’échange suivant est abandonné ou échoue, le registre et l’interface doivent conserver la distinction entre les mouvements de jetons autorisés et les mouvements réellement effectués.
Interpréter la comptabilité flash sans inventer de capital gratuit
La comptabilité flash de V4 suit les variations de solde pendant les opérations et exige que les obligations pertinentes soient réglées au plus tard à la fin de l’interaction. Cela peut réduire les transferts intermédiaires inutiles dans le flux d’exécution pris en charge. Cela ne crée pas un bénéfice de trading garanti.
Un bot doit toujours comprendre la séquence complète des actions et les obligations finales. Une série d’étapes individuellement attrayantes peut laisser un montant final défavorable une fois les frais, les arrondis et le comportement de la route pris en compte.
Cela ne rend pas non plus atomiques des transactions sans lien entre elles. Deux opérations soumises séparément, ou des actions impliquant des chaînes différentes, n’acquièrent pas un comportement « tout ou rien » simplement parce qu’un composant utilise la comptabilité v4.
Évaluez l’atomicité au niveau du périmètre réel de la transaction. Si une stratégie dépend d’une seconde transaction indépendante, décrivez ce qui se passe lorsque la première réussit et que la seconde échoue. Cette exposition doit figurer dans le plan de position, plutôt que d’être masquée par un terme technique associé à la première opération.
Rapprocher les mouvements du compte plutôt que le prix affiché
La question comptable finale est de savoir ce que le compte a dépensé, reçu et détient encore. Un prix sur un graphique ou un message indiquant la soumission d’une transaction ne peut pas, à lui seul, répondre à cette question. Conservez le statut final de la transaction et les changements pertinents du compte.
Pour un achat fictif, 100 unités de cotation auxquelles s’ajoutent deux unités de dépenses mesurées séparément donnent un coût d’acquisition total de 102. Revendre plus tard la totalité de la position reçue pour 110 unités nettes produit huit unités de bénéfice. Une hausse de prix affichée de 10 % ne change pas ce résultat de huit unités.
Si seule la moitié de la position est vendue, répartissez le coût d’acquisition de façon cohérente et conservez les avoirs restants dans le suivi. Ne qualifiez pas toute la position de rentable simplement parce que la moitié réalisée a un résultat favorable alors que la moitié invendue s’est dégradée.
Lorsque la monnaie native sert aussi à payer le gas, séparez le mouvement du principal du débit lié au réseau. Sinon, une méthode fondée sur la différence de solde peut prendre des dépenses opérationnelles pour un montant d’achat supplémentaire ou masquer le montant réellement reçu lors d’une sortie.
Conserver un suivi commun de l’exposition entre pools similaires
Négocier le même jeton par l’intermédiaire de deux clés de pool v4 différentes ne crée pas deux expositions économiques sans rapport. L’identité du pool compte pour l’exécution, mais l’identité des actifs du portefeuille compte aussi pour le risque. Le bot a besoin de ces deux visions.
Supposons qu’un compte détienne déjà 240 unités d’exposition à un jeton et ait un achat de 60 unités non résolu. Une nouvelle proposition de 80 unités via un autre pool doté d’un hook porterait l’exposition engagée à 380. Avec un plafond de 350 unités, la proposition dépasse la capacité disponible de 30.
L’annulation d’une route ne libère pas la somme qui lui est réservée tant que le bot n’a pas établi l’état qui en résulte. Une transaction incertaine ne doit pas être considérée comme définitivement inexistante simplement parce qu’un pool plus récent offre désormais une meilleure cotation.
Conservez un budget commun au niveau de l’actif tout en gardant les enregistrements propres à chaque route. Cela permet à la personne chargée de l’examen de comprendre à la fois pourquoi un pool donné a été choisi et pourquoi une opération par ailleurs attrayante a été rejetée en raison d’engagements existants ailleurs.
Diagnostiquer une annulation d’exécution avant de modifier l’opération
Une transaction dont l’exécution est annulée ne signifie pas nécessairement que le montant minimal en sortie était trop strict. La cause peut être une condition du hook, un comportement de jeton incompatible, une autorisation insuffisante ou une hypothèse sur la route qui ne correspond plus à l’état actuel. Augmenter la tolérance sans avoir classé l’échec peut autoriser un prix moins favorable tout en laissant le vrai problème intact.
Conservez la décision initiale et les éléments attestant son échec. Comparez le chemin attendu avec l’état et la réponse observés pendant l’exécution. Si la cause reste inconnue, une nouvelle tentative ne doit pas bénéficier d’un budget illimité de tentatives simplement parce que la précédente n’a acquis aucun jeton.
Les tentatives échouées peuvent tout de même consommer des ressources réseau. Dans une session hypothétique, six transactions échouées coûtant chacune 0,40 unité consomment 2,40 unités avant qu’un achat réussi commence à rapporter ou à perdre quoi que ce soit. Un gain de trading ultérieur de trois unités ne laisserait que 0,60 après ces tentatives mesurées, en supposant l’absence d’autres coûts.
Le registre des échecs doit donc accompagner celui des positions. Il aide à distinguer une stratégie dont les opérations exécutées sont acceptables d’une implémentation qui dépense trop pour parvenir à ces exécutions. Une pause opérationnelle peut se justifier par des échecs répétés liés à des états incompatibles, même lorsque les perspectives de marché de l’actif n’ont pas changé.
Examiner les changements sans réécrire le passé
Les changements de configuration des hooks méritent des enregistrements datés. Lorsqu’une personne compare les résultats avant et après une modification, la stratégie ne doit pas faire comme si chaque opération avait utilisé les paramètres d’aujourd’hui. Sinon, une amélioration apparente peut simplement refléter des conditions d’exécution différentes qui n’ont jamais été consignées.
Conservez l’identité du pool, le contexte de l’implémentation examinée et la référence de configuration pertinente avec chaque décision menée à son terme. Si un nouvel examen modifie ce que le bot prend en charge, appliquez cette autorisation aux actions suivantes plutôt que de requalifier les éléments antérieurs comme s’ils respectaient déjà la nouvelle norme.
Un exemple pratique est celui d’un compte autorisé à négocier uniquement avec un ensemble restreint de hooks dont le fonctionnement est compris. Ajouter un autre hook à cet ensemble doit nécessiter une décision explicite et motivée sur sa compatibilité. Un jeton déjà détenu via une ancienne route n’autorise pas automatiquement la nouvelle route.
Cet historique permet également de retirer une autorisation. Lorsque les éléments de preuve deviennent incomplets ou contradictoires, le système peut cesser d’ouvrir de nouvelles expositions tout en conservant les enregistrements nécessaires à la gestion des avoirs existants. La décision de cesser d’ajouter du risque et celle concernant une position existante sont liées, mais distinctes.
Tester délibérément les cas non pris en charge
Une simulation pertinente doit inclure plus qu’un échange réussi sur un pool familier. Incluez un cas de liquidité manquante, une observation périmée des frais, une configuration de hook modifiée, une quantité insuffisante de monnaie pour les opérations et une route qui produit moins que le minimum configuré.
Testez aussi les erreurs d’identité. Une paire de jetons valide associée à la mauvaise adresse de hook ou au mauvais espacement des ticks ne doit pas être acceptée parce que ses symboles semblent corrects. Le résultat attendu est le rejet de l’intention incohérente, accompagné d’une explication utile.
Consignez le périmètre de chaque test. Une simulation réussie dans un état donné apporte des éléments sur cet état et cette route. Elle ne prouve pas une compatibilité permanente avec toutes les configurations futures ou avec un autre hook exposant des fonctions de rappel similaires.
Le critère pratique est un périmètre d’exécution explicable. Un bot bien spécifié peut indiquer quels pools il comprend, quels faits autorisent une opération, quelles limites l’encadrent et quels éléments finaux permettent de clôturer le registre. Les pools en dehors de ce périmètre restent des candidats à étudier tant que l’interprétation manquante n’est pas résolue.