Hooks Uniswap v4 : cas d'usage concrets au-delà du battage médiatique

Quel problème les hooks v4 essaient réellement de résoudre

Uniswap v3 donnait aux fournisseurs de liquidité un contrôle fin sur la fourchette de prix dans laquelle leur capital était déployé. C'était un progrès net par rapport à la courbe plate de v2, mais cela laissait chaque pool bloqué avec le même niveau de frais fixe, la même logique de swap simple et la même exposition à une catégorie d'attaques appelée maximal extractable value, ou MEV, où les producteurs de blocs et les bots réordonnancent, insèrent ou censurent des transactions pour capter du profit sur le dos des traders et des LP.

Le système de hooks de v4 est la réponse à une frustration de fond : si vous vouliez faire quoi que ce soit de personnalisé dans v3, vous deviez forker les contrats, redéployer un AMM parallèle et fragmenter votre liquidité loin des pools principaux. Il n'existait pas de façon propre d'ajouter une courbe de frais personnalisée, un oracle ou une règle de rééquilibrage sans abandonner la marque Uniswap et les effets de réseau liés à sa liquidité.

Les hooks changent cela en permettant à un pool de rattacher des smart contracts externes que le routeur principal appelle à des moments bien définis du cycle de vie du pool : avant un swap, après un swap, avant l'ajout de liquidité, après le retrait de liquidité, et autour des changements de prix. Le propriétaire du pool choisit une adresse de hook lors de la création du pool, et ce hook peut lire l'état du pool, exécuter sa propre logique et, dans certains cas, modifier la façon dont le swap s'exécute. Le cœur mathématique reste la même courbe de liquidité concentrée d'Uniswap, mais l'enveloppe autour peut désormais faire des choses qui exigeaient auparavant un projet distinct.

Les risques liés à la complexité des hooks

Avant de passer en revue les cas d'usage, les risques doivent être mis au premier plan, car les hooks déplacent les modes de défaillance. Plusieurs effondrements ont déjà eu lieu dans l'univers des contrats personnalisés de type hook, et le schéma se répète : un smart contract qui exécute une logique privilégiée sur les fonds des utilisateurs se fait exploiter, souvent via un bug de logique plutôt qu'une faille cryptographique connue.

Le premier risque est la surface d'audit. Chaque hook est essentiellement un smart contract séparé qui peut déplacer des tokens ou modifier le comportement d'un swap. Quand vous déposez de la liquidité dans un pool v4 avec un hook exotique, vous faites confiance au créateur du pool, au développeur du hook et à tout auditeur qu'il a engagé. Un bug dans le hook peut vider le pool, geler les fonds des utilisateurs ou permettre à un attaquant d'extraire de la valeur de chaque swap qui le traverse.

Le deuxième risque est la centralisation de la revue de code. v3 offrait peu de personnalisation, ce qui signifiait que chaque pool pouvait être analysé avec le même modèle mental. v4 permet à n'importe qui de publier un hook, et beaucoup le font vite. L'équipe Uniswap relit les contrats principaux, mais les hooks restent largement un Far West tiers. Quiconque consulte l'adresse du hook d'un pool doit encore traiter le hook comme une boîte noire, sauf à lire le code lui-même ou à se fier à un rapport d'audit d'une firme réputée.

Le troisième risque est le MEV quand les hooks sont absents. La plupart des créateurs de pool déploieront un hook standard ou aucun hook, ce qui signifie que la majorité du volume sur v4 passera probablement par des pools exposés aux mêmes attaques sandwich qu'en v3. Les bots sandwich détectent les grosses transactions en attente, placent un achat juste avant et une vente juste après, capturant l'impact sur le prix comme profit au détriment du LP et du trader. Les hooks peuvent atténuer cela, mais seuls les pools qui activent réellement cette protection en bénéficient.

Le quatrième risque est celui des schémas de type rug. Comme créer un hook et y relier un pool coûte peu, des projets frauduleux peuvent lancer un token, déployer un hook tape-à-l'œil promettant quelque miracle de frais dynamiques, encaisser les dépôts des utilisateurs et disparaître. L'utilisateur n'a aucun recours, et la marque Uniswap donne à l'ensemble une apparence de légitimité que les anciens scams de DEX forkés n'avaient jamais eue.

Cas d'usage concret 1 : courbes de frais dynamiques et personnalisées

Le bénéfice le plus concret des hooks est de remplacer les paliers de frais fixes de la v3 (0,05 %, 0,30 %, 1,00 %) par une logique qui s'ajuste en fonction des conditions du pool. Il ne s'agit pas d'une fonctionnalité théorique. Des projets comme le déploiement v4 de PancakeSwap et plusieurs studios de hooks indépendants ont déjà livré des hooks de frais qui réagissent à la volatilité, à l'heure de la journée ou à des tranches de volume.

L'argument économique est simple. Les pools de stablecoins vers stablecoins traitent surtout de petites variations de prix et profitent de frais aussi bas que 0,01 %, tandis qu'un lancement de token à longue traîne peut connaître des mouvements de 20 % en une heure et tirerait parti d'un frais proche de 1 % pour compenser le risque d'inventaire supporté par les LP. La v3 force chaque pool à choisir un seul chiffre. Un hook peut facturer 0,01 % pendant les heures calmes, monter à 0,50 % lors d'un pic de volatilité, puis redescendre lorsque le marché se normalise.

Cela permet aussi des frais asymétriques, où les frais facturés lors de l'achat d'un token diffèrent de ceux facturés lors de la vente. Cela peut sembler étrange, mais les launchpads et les émetteurs de tokens programmatiques veulent réellement subventionner les ventes (pour faciliter la liquidité de sortie après le lancement) tout en taxant plus lourdement les achats (pour freiner les afflux spéculatifs). La v3 ne pouvait tout simplement pas exprimer cela. Les hooks de la v4 le peuvent, en inspectant la direction du swap et les réserves de tokens avant que la transaction ne soit réglée.

Cas d'usage concret 2 : ordres à cours limité on-chain via des hooks

Dans la v3, la seule façon de placer un véritable ordre à cours limité consistait à ajouter de la liquidité concentrée dans une plage étroite. N'importe qui pouvait ainsi devenir un micro-LP dont la position se convertissait en un actif lorsque le prix pénétrait dans sa plage. Cela fonctionnait, mais cela immobilisait du capital dans une position qui ne générait plus de frais une fois exécutée.

Les hooks de la v4 permettent à un pool de mettre en œuvre un schéma d'ordre à cours limité plus propre. Un hook peut surveiller le prix, et lorsqu'un niveau de prix spécifié par l'utilisateur est franchi, il exécute un swap pour le compte de l'utilisateur, transfère les tokens de sortie à l'utilisateur et supprime la position désormais vide. Du point de vue de l'utilisateur, cela se comporte comme un ordre à cours limité sur une bourse centralisée, mais tout reste on-chain et l'échange a lieu au sein du même réseau de liquidité que le reste du pool.

Cela importe car cela ramène vers les venues on-chain une activité qui fuyait auparavant vers les carnets d'ordres centralisés. Cela importe aussi car c'est véritablement composable : un hook peut enchaîner l'exécution d'un ordre à cours limité avec une autre action, comme acheminer les produits vers un vault de prêt ou les swapper en stablecoin. La contrepartie est que l'utilisateur fait confiance au développeur du hook pour exécuter fidèlement la logique d'exécution, et un bug dans le hook peut permettre à un attaquant d'anticiper l'exécution ou de sauter des étapes.

Cas d'usage concret 3 : résistance au MEV et aux sandwichs

La troisième catégorie est celle où les hooks ont l'argument technique le plus solide, car le MEV est une taxe réelle et mesurable sur chaque transaction on-chain. Les hooks explicitement anti-MEV font quelques choses différemment d'un pool standard. Ils chiffrent ou s'engagent sur le contenu de la transaction avant que le swap ne soit réglé, ils regroupent et aléatoirisent l'ordre d'exécution, ou ils détectent les schémas de sandwich et rejettent la jambe traînante de l'attaque.

L'attaque sandwich classique repose sur le fait que l'attaquant voit la transaction de la victime dans le mempool public, achète d'abord, puis vend immédiatement après. Si un hook introduit un schéma commit-reveal, où le trader soumet d'abord une intention hachée et ne révèle les paramètres qu'à l'intérieur du bloc, l'attaquant ne peut plus observer la transaction à temps pour l'anticiper. Le hook pourrait aussi annuler les transactions dont le profil de gaz environnant ressemble à un sandwich, au prix de quelques faux positifs.

Cette catégorie est éprouvée en conditions réelles dans des conceptions adjacentes. CoW Protocol et d'autres venues de batch auction ont démontré pendant des années que le batching et les prix de compensation uniformes réduisent considérablement la valeur extractible. Les hooks apportent des idées similaires à un pool unique plutôt que d'exiger un agrégateur séparé. L'honnête réserve est que les hooks anti-MEV sont eux-mêmes des smart contracts, et la logique qu'ils utilisent pour détecter et bloquer les attaquants constitue elle-même une surface d'attaque. Un filtre mal conçu peut être exploité pour nuire, subir un DoS ou servir à censurer des transactions légitimes. Le code défensif doit être au moins aussi bien écrit que le code offensif qu'il cherche à battre.

Cas d'usage concret 4 : oracles TWAP et rééquilibrage des LP

Deux idées adjacentes complètent cette liste pratique. La première consiste à utiliser un hook pour publier un prix moyen pondéré dans le temps, ou TWAP, pour le pool. Les oracles sont la manière dont les protocoles DeFi obtiennent des informations de prix on-chain, et les TWAP d'Uniswap v3 figurent déjà parmi les flux de prix les plus utilisés dans l'espace. Un hook v4 peut calculer et exposer un TWAP à moindre coût que le schéma de contrat externe de la v3, car le calcul peut s'exécuter à l'intérieur de la même exécution de hook que le swap.

La seconde idée est le rééquilibrage automatisé. Un hook peut surveiller la position de liquidité concentrée d'un utilisateur et, lorsque le prix sort de la plage sélectionnée, migrer progressivement la position vers la plage active, idéalement via une suite de petits swaps afin de minimiser le coût du rééquilibrage. C'est ce qui se rapproche le plus dans la v4 d'une stratégie de LP active, et c'est véritablement utile pour les LP qui devraient autrement rééquilibrer manuellement chaque semaine.

Ces fonctionnalités sont moins tape-à-l'œil que les frais dynamiques ou l'anti-MEV, mais elles sont utiles, durables et sans histoires. Elles seront probablement déployées dans de nombreux pools sans que les utilisateurs ne les remarquent jamais, ce qui est la marque d'une infrastructure réussie.

Là où les hooks sont surtout cosmétiques

Hooks sociaux, de gouvernance et de réputation

Chaque cycle de la v4 a produit une vague de propositions de hooks implémentant des comportements sociaux ou de gouvernance inédits : des ristournes de frais pour les détenteurs de longue durée, des frais pondérés selon l'historique on-chain d'un utilisateur, ou des pools qui distribuent une partie des frais à une trésorerie communautaire. Ces idées sont ingénieuses sur le papier et échouent presque toujours en pratique.

La raison tient à une logique économique simple. Ajouter une ponction vers une trésorerie communautaire à la mécanique de frais d'un pool rend ce pool strictement moins intéressant pour les traders et les LP qu'un pool identique sans ce hook, sauf si le mécanisme social génère un flux compensatoire. Dans un espace où les traders acheminent leurs ordres vers le pool qui leur offre la meilleure exécution, un prélèvement de 5 % au profit d'une trésorerie sera tout simplement évité. Le pool restera vide, et le projet accusera le marché de ne pas apprécier la valeur de la couche sociale.

Les hooks de réputation qui prétendent filtrer l'accès (KYC, résistance aux sybil, restrictions géographiques) sont encore pires. Ils ne peuvent pas réellement vérifier l'identité sur une blockchain publique, ils dissuadent précisément les traders légitimes dont le pool a besoin, et ils attirent des ennuis réglementaires qu'aucun développeur de hook anonyme ne souhaite.

Une mathématique d'AMM inédite cachée dans les hooks

Une deuxième catégorie cosmétique regroupe les hooks qui enveloppent une « nouvelle courbe d'AMM » autour de la mathématique classique de liquidité concentrée. L'argumentaire consiste généralement à dire qu'un hook implémente un invariant de type stableswap, une courbe à moyenne constante, ou une formule hybride dans une couche de hook. La mathématique est bien réelle, mais le résultat est un pool qui concurrence en termes de volumes des venues stableswap établies comme Curve etBalancer, et qui perd, parce que ces venues cumulent des années de liquidité et d'intégrations.

Les hooks sont un moyen puissant d'étendre un réseau de liquidité existant. Ils sont un piètre moyen de lancer un réseau concurrent. Les développeurs qui veulent une mathématique véritablement nouvelle devraient publier leur propre AMM audité et attirer la liquidité de manière organique, plutôt que de louer la marque Uniswap pour un hook qui embarque la mauvaise courbe.

Ce que cela implique pour les LP et les builders de la v3

Pour les fournisseurs de liquidité existants de la v3, la question pratique est de savoir s'il faut migrer, et comment. L'équipe Uniswap a indiqué que la v3 resterait prise en charge, et que la v4 fonctionne en parallèle plutôt qu'en mise à niveau forcée. Il n'y a aucune date limite officielle pour migrer, et les pools v3 génèrent encore des frais aujourd'hui. La réponse honnête est qu'un LP de la v3 ne devrait pas migrer vers un pool v4 simplement parce que la v4 existe. Il ne devrait migrer que lorsqu'un pool v4 spécifique offre démontré de meilleurs rendements attendus pour sa tolérance au risque, que ce soit via une courbe de frais dynamiques adaptée à sa paire, un hook anti-MEV qui réduit ses pertes face au sandwiching, ou un rééquilibreur automatique qui lui épargne un travail manuel.

Pour les builders, la v4 réduit le coût d'essai d'idées qui exigeaient auparavant un fork. C'est là l'avantage et le piège. La plupart des idées de hooks ne trouveront pas leur marché. Le test économique est simple : le hook rend-il le pool meilleur pour la personne qui y route réellement ses trades, par rapport à un pool v4 vanille au même niveau de frais ? Sinon, le hook est une fonctionnalité pour une page marketing, pas pour les utilisateurs.

Le calcul d'audit compte plus que pour à peu près n'importe quelle autre primitive DeFi. Un hook qui touche aux transferts de tokens ou modifie l'exécution des swaps dispose d'un accès privilégié aux fonds des utilisateurs. La réputation du développeur du hook, la qualité du rapport d'audit, le fait que le code soit open source, et le fait que l'adresse du déployeur ait un historique de lancements propres sont autant de signaux qu'un LP doit peser avant de déposer.

Comment suivre les hooks Uniswap v4 de manière intelligente

Le développement des hooks v4 évolue vite, tout comme l'actualité qui les entoure : annonces d'audits, lancements de hooks, exploits et expérimentations de niveaux de frais tombent chaque semaine. Zippfeed met en avant les titres les plus pertinents sur UNI, Uniswap v4, et plus largement la DeFi et les AMM, avec un scoring de sentiment (bullish, neutral ou bearish) et une note d'importance, afin que vous puissiez distinguer le signal du bruit et suivre les hooks qui modifient réellement la donne économique pour les LP et les traders.