Hooks Uniswap V4 : cas d’usage DeFi et risques

Ce que les hooks Uniswap V4 changent réellement

Les hooks Uniswap V4 sont des smart contracts qu’un pool peut appeler à des moments précis, par exemple avant ou après un swap, avant l’ajout de liquidité ou après le retrait de liquidité. Un hook peut ajuster des frais, enregistrer des données de prix, rejeter une action qui enfreint une règle ou exécuter une comptabilité personnalisée. La distinction importante est qu’un hook n’est pas un paramètre à l’intérieur d’un pool standard. Il s’agit d’un code séparé, avec sa propre logique et son propre profil de sécurité.

Cette flexibilité répond à une limite de longue date des automated market makers, ou AMMs. Les conceptions Uniswap antérieures offraient aux créateurs de pools un ensemble restreint de choix intégrés, tandis que des conceptions de marché plus spécialisées nécessitaient un protocole séparé. V4 facilite l’expérimentation, mais cela signifie aussi que deux pools détenant les mêmes tokens peuvent avoir un comportement sensiblement différent. Une paire de tokens familière ne signifie pas un profil de risque familier.

V4 regroupe les pools dans une architecture singleton, ce qui signifie qu’un contrat PoolManager central gère de nombreux pools au lieu de déployer un contrat de base distinct pour chacun. Cela peut réduire les coûts de déploiement et de transaction. Cela rend aussi les interactions avec les hooks plus composables, mais un bug dans un hook reste un risque pour les utilisateurs du pool qui y est rattaché, même lorsque le PoolManager sous-jacent est solide.

Pourquoi les hooks augmentent le niveau de risque pour les fournisseurs de liquidité

Un hook est un smart contract supplémentaire sur le chemin d’une transaction ou d’une action de liquidité. Cela crée des risques techniques classiques : la réentrance, lorsqu’un appel externe réintègre du code de manière inattendue ; des contrôles d’accès défaillants ; une comptabilité des tokens incorrecte ; un déni de service ; et de mauvaises hypothèses sur le prix ou le timing. Un audit est la preuve que des examinateurs ont recherché des problèmes, pas une garantie qu’il n’en reste aucun. Les nouveaux modèles de hooks ont été moins éprouvés en conditions réelles que les modèles de pools utilisés depuis longtemps.

L’histoire de la crypto donne peu de raisons de traiter la complexité à la légère. L’exploit Euler Finance de 2023 a touché environ 197 millions de dollars avant qu’une grande partie ne soit ensuite restituée, tandis qu’un problème du compilateur Vyper a contribué à des pertes dans plusieurs pools Curve en 2023. Ces incidents n’étaient pas des défaillances de hooks Uniswap V4, mais ils montrent comment une petite interaction ou une erreur d’implémentation peut mettre en danger des soldes importants. Un pool peut avoir une interface réputée et dépendre tout de même d’un code vulnérable en dessous.

Le risque de contrôle compte autant que le risque lié au code. Un hook peut avoir un propriétaire capable de modifier les frais, de suspendre les swaps, de changer une source d’oracle, de mettre à niveau le code d’implémentation ou de rediriger les frais collectés. Certaines équipes utilisent des multisignatures et des timelocks, ce qui peut réduire le contrôle unilatéral sans l’éliminer. Un administrateur malveillant ou compromis peut transformer un pool apparemment neutre en piège, en particulier si les utilisateurs approuvent des tokens ou déposent des fonds avant de lire les permissions du hook.

Les schémas d’arnaque peuvent aussi être plus subtils qu’un rug pull évident. Un hook peut annoncer des frais faibles mais facturer des frais inhabituels pendant des blocs volatils, bloquer les retraits sous des conditions vagues ou utiliser un proxy de mise à niveau qui pointe ensuite vers un nouveau code. Les fournisseurs de liquidité doivent considérer les hooks non audités, les administrateurs anonymes et les chemins de mise à niveau opaques comme des conditions à haut risque, et non comme de simples informations secondaires.

Cas d’utilisation un : des frais dynamiques qui réagissent aux conditions de marché

Les frais dynamiques font partie des cas d’utilisation les plus évidents des hooks Uniswap V4. Au lieu de prélever un pourcentage fixe sur chaque swap, un hook peut définir des frais plus élevés lorsque la volatilité à court terme augmente et des frais plus faibles lorsque le trading est calme. L’idée économique de base est raisonnable : les fournisseurs de liquidité sont davantage exposés à la sélection adverse lorsque le prix évolue rapidement, car les traders informés sont plus susceptibles de trader contre une liquidité devenue obsolète.

Un hook de frais dynamiques bien conçu peut utiliser comme données d’entrée les mouvements de prix récents, la taille des transactions, le déséquilibre des inventaires ou les conditions de marché externes. Par exemple, un pool peut appliquer des frais de base pendant une activité normale, puis les augmenter lorsque le prix évolue fortement sur plusieurs observations. Cela peut rendre la liquidité passive moins exposée aux flux rapides, même si cela ne peut pas éliminer la perte impermanente, qui est le coût d’opportunité qui apparaît lorsqu’un AMM rééquilibre ses actifs à mesure que leur prix relatif change.

Le compromis est facile à sous-estimer. Une règle de frais fondée sur un prix spot manipulable peut être exploitée par un attaquant qui déplace d’abord le prix, déclenche un nouveau niveau de frais, puis trade dans des conditions plus favorables. Des frais qui se mettent à jour trop lentement peuvent ne pas protéger les fournisseurs de liquidité, tandis que des frais qui se mettent à jour trop agressivement peuvent rendre l’exécution imprévisible et pousser les traders ailleurs. Les bons paramètres dépendent de la paire d’actifs, de la profondeur de marché et du comportement des utilisateurs, dont aucun ne reste stable.

Les développeurs doivent divulguer les données d’entrée exactes, la cadence de mise à jour, les frais maximaux et l’autorité pouvant modifier ces règles. Les fournisseurs de liquidité doivent comparer les résultats nets réels après frais, divergence de prix et coûts de gas. Un rendement de frais affiché élevé ne prouve pas qu’un pool est meilleur s’il compense principalement un flux d’ordres inhabituellement toxique.

Cas d’utilisation deux : oracles TWAP on-chain et ordres limités

Un prix moyen pondéré dans le temps, ou TWAP, calcule une moyenne des prix sur une période définie au lieu de s’appuyer sur la dernière transaction. Un hook peut enregistrer des observations et mettre à disposition d’autres contrats un TWAP on-chain propre à un pool. Cela peut prendre en charge des règles de règlement, des frais dynamiques ou des applications qui ont besoin d’une référence de prix moins instable que le prix spot d’un seul bloc.

Les TWAP réduisent la sensibilité à un mouvement de prix sur un seul bloc, mais ils ne créent pas la vérité à partir de rien. Si un pool a une faible liquidité, un attaquant peut maintenir un prix manipulé suffisamment longtemps pour influencer la moyenne. Plus la fenêtre de moyenne est longue, plus la manipulation peut devenir difficile et coûteuse, mais plus l’oracle réagit lentement à un véritable mouvement de marché. Les protocoles utilisant un TWAP basé sur un hook doivent indiquer quel pool le fournit, à quelle fréquence les observations sont écrites et ce qui se passe si le trading s’arrête ou si les données deviennent obsolètes.

Les hooks peuvent aussi approximer des ordres limités. Dans un ordre limité classique, un utilisateur demande à acheter ou vendre uniquement à un prix choisi ou meilleur. Dans un AMM, les utilisateurs peuvent fournir une liquidité concentrée dans une fourchette de prix. Un hook peut suivre une position, appliquer des conditions autour de sa fourchette et gérer ou régler automatiquement le comportement lorsque le marché atteint un déclencheur. Cela peut rapprocher l’expérience d’un carnet d’ordres sans nécessiter de moteur centralisé d’appariement.

Mais les hooks de type ordre limité comportent des réserves importantes. L’exécution n’est pas garantie simplement parce que le marché touche brièvement un prix affiché. La liquidité doit être disponible, les transactions doivent être incluses et la logique de déclenchement du hook doit fonctionner comme prévu. Les frais, les exécutions partielles, les écarts de prix et le MEV peuvent modifier le résultat réalisé. Les utilisateurs doivent comprendre si le hook conserve les fonds, si les positions sont transférables et comment l’annulation ou le règlement fonctionne avant de le traiter comme un ordre de bourse traditionnel.

Cas d’utilisation trois : hooks capturant le MEV et leurs coûts cachés

Le MEV, abréviation de maximal extractable value, est la valeur obtenue en contrôlant l’ordre ou l’inclusion des transactions. Dans les AMM, les arbitragistes capturent souvent de la valeur lorsqu’un prix de marché externe change et que le prix du pool se réajuste. Certaines conceptions de hooks V4 visent à rediriger une partie de cette valeur vers les fournisseurs de liquidité au moyen d’enchères, d’exécution par lots ou de règles qui facturent plus directement certains flux d’arbitrage.

C’est une véritable opportunité de conception, pas une amélioration gratuite. Un hook peut organiser une enchère périodique pour le droit de rééquilibrer un pool, utiliser un arrangement de flux d’ordres privé ou imposer une surtaxe aux transactions identifiées comme toxiques. S’il fonctionne comme prévu, davantage de valeur peut rester entre les mains des fournisseurs de liquidité. Pourtant, identifier les flux nuisibles est difficile, et un mécanisme d’enchères peut favoriser des searchers sophistiqués, des validateurs ou un réseau de solveurs privilégié.

La préoccupation liée à la centralisation est particulièrement importante. Un hook qui dépend d’un seul opérateur off-chain pour soumettre des prix, choisir des gagnants ou séquencer des ordres a introduit un intermédiaire de confiance, même si le pool lui-même est on-chain. Une interface d’apparence décentralisée peut dissimuler un relayer privilégié ou un petit groupe d’électeurs de gouvernance. La question pertinente n’est pas de savoir si le code utilise la blockchain, mais qui peut influencer l’exécution et quels recours les utilisateurs ont en cas d’échec.

Les affirmations de capture du MEV doivent donc être testées par rapport à des résultats mesurables. Le hook publie-t-il les enchères et les offres ? Les utilisateurs obtiennent-ils une meilleure exécution après tous les frais ? N’importe qui peut-il participer en tant que solveur ? Les règles sont-elles appliquées par des contrats ou par la promesse d’un opérateur ? Tant que ces réponses ne sont pas claires, des rendements projetés plus élevés pour les fournisseurs de liquidité ne sont qu’une hypothèse.

Comment le système de permissions et l’architecture singleton façonnent la sécurité

Uniswap V4 ne permet pas à un hook de choisir arbitrairement chaque callback après son déploiement. Son système de permissions de hooks utilise des bits de permission désignés associés à l’adresse du hook pour préciser quelles fonctions du cycle de vie le contrat peut utiliser. Les déployeurs utilisent couramment CREATE2, une méthode permettant de déployer un contrat à une adresse prévisible, afin d’obtenir une adresse compatible avec les permissions demandées. Cette contrainte contribue à rendre plus explicite la surface de callbacks autorisée d’un hook.

Les bits de permission sont utiles, mais ils ne constituent pas un certificat de sécurité. Un hook avec seulement quelques callbacks peut tout de même contenir une logique dangereuse, et un hook doté de permissions étendues peut être adapté à une conception complexe. Les lecteurs doivent distinguer la portée des permissions de la qualité du code. La première indique où un hook peut agir. La seconde détermine s’il agit correctement, équitablement et sans pouvoirs d’administrateur cachés.

L’architecture singleton modifie l’économie du déploiement et peut rendre les interactions entre plusieurs pools plus efficaces grâce à une comptabilité partagée. Cela ne signifie pas que chaque pool partage le même hook ou la même gouvernance. La diligence raisonnable au niveau du pool reste importante : identifiez le contrat du hook, lisez son code source vérifié s’il est disponible, vérifiez s’il est évolutif, inspectez les privilèges et recherchez des évaluations indépendantes couvrant la version déployée plutôt qu’un commit antérieur du dépôt.

Ce que les builders, traders et fournisseurs de liquidité devraient faire

Les builders devraient commencer avec l’ensemble d’autorisations de hook le plus restreint et la machine à états la plus simple possible. Séparez la comptabilité principale des fonctionnalités optionnelles, testez les scénarios adverses et divulguez chaque rôle privilégié. Des audits indépendants, des bug bounties, des simulations sur des données de marché volatiles et une liquidité de lancement plafonnée peuvent tous réduire le risque, même si aucun ne remplace une conception rigoureuse. Un hook qui nécessite des contrôles d’urgence devrait aussi définir qui peut les utiliser, combien de temps ils durent et si les utilisateurs peuvent sortir pendant une urgence.

Les fournisseurs de liquidité ne devraient pas évaluer une pool avec hook uniquement selon son niveau de frais ou son rendement annualisé. Vérifiez les actifs, le code source et le statut d’audit du hook, sa possibilité de mise à niveau, les pouvoirs du propriétaire, les dépendances aux oracles, les conditions de retrait et si la stratégie repose sur des acteurs off-chain. De petites positions de test peuvent révéler des problèmes d’interaction de base, mais elles ne peuvent pas révéler tous les risques extrêmes. N’engagez jamais dans un hook expérimental des fonds que vous ne pouvez pas vous permettre de perdre.

Les traders devraient comparer l’exécution proposée avec celle des pools standards et rester attentifs aux frais ou restrictions personnalisés. Si un hook utilise un TWAP ou une enchère, comprenez si le prix final est déterministe au moment de la soumission ou s’il dépend d’un règlement ultérieur. Pour des éléments de contexte connexes, comparez la perte impermanente dans les pools de liquidité, le fonctionnement de la liquidité concentrée et le MEV dans les exchanges décentralisés. Il s’agit d’éducation, pas de conseils financiers, et aucune conception de pool ne rend la DeFi sans risque.

Lisez les actualités sur les hooks Uniswap V4 avec esprit critique

Les hooks Uniswap V4 évoluent rapidement, tout comme les affirmations sur les nouveaux modèles de pools. Suivre manuellement les audits, les mises à niveau, les changements de gouvernance, les variations de liquidité et les rapports d’exploit est difficile. Zippfeed fait ressortir les gros titres liés à Uniswap et UNI avec une notation de sentiment bullish, neutral ou bearish ainsi qu’une note d’importance, ce qui vous aide à distinguer une mise à jour d’implémentation utile d’un marketing non étayé.

Utilisez les signaux d’actualité comme point de départ, pas comme substitut à l’examen des contrats. Une annonce bullish peut décrire une fonctionnalité prometteuse tout en laissant sans réponse la portée de l’audit, les privilèges d’administration et l’usage réel. Pour l’argent exposé au risque, ces détails sans réponse comptent davantage que le titre.