Hooks Uniswap v4 : cas d’usage classés par risque

Ce que les hooks d’Uniswap v4 transforment réellement un pool en

Les hooks d’Uniswap v4 sont des contrats intelligents qui peuvent s’exécuter à des points définis du cycle de vie d’un pool. Un hook peut s’exécuter avant ou après l’initialisation d’un pool, un changement de liquidité, un swap ou un don. Cela permet à un développeur d’ajouter une logique comme des frais dynamiques, des ordres de type limite, des transactions découpées dans le temps, des contrôles d’accès, des mises à jour d’oracle ou une activité de prêt externe sans modifier le cœur d’Uniswap v4.

Cette description peut faire penser que les hooks sont des plug-ins. Sur le plan financier, ils ressemblent davantage à des moteurs de règles programmables. Un pool Uniswap de base suit des règles comptables connues, tandis qu’un pool doté de hooks peut imposer des règles supplémentaires, déplacer des actifs, calculer ses propres deltas ou interagir avec un autre protocole. Deux pools détenant les mêmes tokens peuvent donc avoir des profils de sécurité et de liquidité complètement différents.

La vraie question n’est pas de savoir si les hooks sont bons ou mauvais. Elle consiste à mesurer l’autorité qu’un hook particulier détient, le nombre d’hypothèses externes qu’il introduit et ce qui se passe lorsque ces hypothèses échouent. Le classement ci-dessous considère les hooks plus simples avec des permissions limitées comme relativement moins risqués, sans pour autant les considérer sûrs, et place la garde, l’effet de levier, le crédit, la comptabilité complexe ou les pouvoirs de mise à niveau du côté le plus risqué.

Comment fonctionne le système de hooks et où le risque apparaît

Uniswap v4 utilise une architecture singleton, ce qui signifie que de nombreux pools sont gérés via un seul contrat central PoolManager plutôt que chaque pool soit déployé comme un contrat distinct. La comptabilité flash enregistre les obligations nettes de tokens pendant une transaction et les règle avant la fin de l’opération. Cela peut réduire les frais de gas et rendre les opérations multi-pools plus efficaces, mais cela signifie aussi que les développeurs de hooks doivent comprendre avec précision les règles de verrouillage, de règlement et de delta de solde.

Un pool choisit son contrat de hook lors de sa création. L’adresse du hook encode les callbacks activés, et ces autorisations ne peuvent pas être considérées comme de simples étiquettes descriptives. Le code exécuté dans les callbacks peut rejeter une action, modifier les frais, renvoyer des deltas de tokens personnalisés, mettre à jour des enregistrements internes ou appeler un autre contrat. Une erreur dans l’un de ces chemins peut affecter les swaps, les retraits de liquidité ou le règlement.

Les hooks peuvent aussi utiliser une comptabilité personnalisée pour modifier le résultat économique fourni par le PoolManager. C’est suffisamment puissant pour reproduire des fonctionnalités associées à d’autres conceptions d’AMM, mais cela élargit la base de code de confiance. Si un hook maintient des soldes virtuels, des frais accumulés, des droits d’ordre, des positions de dette ou des parts de récompense, les utilisateurs dépendent à la fois du fait que la comptabilité d’Uniswap et celle du hook restent cohérentes.

Le modèle singleton ne signifie pas qu’un hook malveillant peut automatiquement réécrire tous les pools Uniswap v4. Les pools restent séparés logiquement, et les permissions de callback limitent les moments où le code du hook s’exécute. Malgré cela, les intégrations qui regroupent des appels, réutilisent des routers, accordent de larges autorisations de tokens ou supposent que tous les pools v4 se comportent de la même façon peuvent créer des voies de défaillance communes. Les développeurs doivent modéliser le chemin complet de la transaction, pas seulement la fonction de callback du hook.

Les risques que les développeurs et les LPs devraient examiner en premier

La réentrance des hooks est une préoccupation majeure. La réentrance se produit lorsqu’un appel externe revient dans un contrat avant que l’opération d’origine ait fini de mettre à jour son état. Uniswap v4 dispose de règles de verrouillage et de règlement, mais un hook peut appeler des tokens, des routers, des lending markets ou d’autres hooks avec leur propre comportement de callback. Un garde local contre la réentrance ne suffit pas si la conception autorise des changements d’état inter-fonctions ou inter-protocoles dans un ordre inattendu.

Le risque lié au singleton-pool est en partie un risque d’intégration. Le PoolManager audité peut faire respecter ses invariants tandis qu’une application calcule mal ce qu’elle doit pendant un lock, confond l’état d’un pool avec celui d’un autre, ou accepte un pool configuré de manière malveillante. Les routers et les position managers doivent valider les currencies, les paramètres de fee, les adresses de hooks, les senders des callbacks et les deltas retournés. Un hook ne devrait jamais faire confiance aux identifiants de pool fournis par l’utilisateur simplement parce qu’un appel provient de quelque part dans le système v4.

Les premiers déploiements basés sur des hooks ont déjà montré que de vraies pertes ne nécessitent pas de faille dans le cœur d’Uniswap v4. Cork Protocol, qui utilisait une logique de marché personnalisée et une machinerie AMM reliées à l’écosystème v4, a subi un exploit signalé à environ 12 millions de dollars en 2025 après qu’un attaquant a abusé de la comptabilité propre au protocole et de la logique de marché. Bunni v2, un système de liquidité basé sur des hooks, a ensuite subi une perte signalée d’environ 8,4 millions de dollars liée à une comptabilité personnalisée de la liquidité et des retraits. Les classifications exactes et les montants récupérés peuvent évoluer au fil des analyses post-mortem, mais ces deux cas renforcent le même point. Une logique financière personnalisée peut échouer alors que le PoolManager sous-jacent se comporte comme prévu.

D’autres modes de défaillance récurrents incluent des erreurs d’arrondi qui peuvent être répétées à des fins de profit, des entrées d’oracle obsolètes ou manipulables, des dénis de service qui bloquent les opérations normales, des calculs de fees qui dépassent les attentes économiques, des clés privilégiées qui peuvent modifier des paramètres, et des tokens au comportement de transfert inhabituel. Le risque d’arnaque reste aussi très concret. Un déployeur peut publier un code de hook copié, annoncer un audit qui portait sur un commit différent, conserver une clé d’upgrade, ou créer un pool dont les conditions de retrait sont volontairement hostiles.

Schémas à moindre risque, fees, ranges et automatisation limitée

Risque relatif, faible à moyen. Hooks à fee dynamique. Un hook à fee dynamique modifie le fee de swap selon une règle annoncée, par exemple la volatilité récente, la taille d’un trade, le déséquilibre des stocks ou un oracle externe. Ce schéma a des précédents dans des automated market makers hors de v4, et une mise à jour de fee n’exige pas en soi que le hook conserve les actifs des utilisateurs. Une formule simple et bornée utilisant des observations onchain fait partie des cas d’usage de hooks Uniswap v4 les plus défendables.

La nuance est importante. Un fee dynamique peut encore être manipulé si un attaquant peut fausser l’observation utilisée par la formule, et un fee mal calibré peut rendre l’exécution inattendument coûteuse. Les règles de fee devraient avoir des minimums et maximums explicites, des intervalles de mise à jour prévisibles, une protection contre la manipulation sur un seul bloc, et des tests pour les marchés inactifs ou peu liquides. Les LPs doivent aussi savoir si un administrateur peut remplacer la formule ou outrepasser le fee.

Risque relatif, moyen. Liquidité concentrée et hooks de range-order. La liquidité concentrée permet à un LP de fournir des actifs uniquement dans des plages de prix sélectionnées. Un hook de range-order peut automatiser l’ajout, le retrait ou la réclamation de liquidité lorsqu’une borne de prix est franchie, ce qui produit un comportement proche d’un limit order onchain. Cela peut réduire la gestion manuelle, mais cela ne garantit pas une exécution à un prix choisi, car le prix peut traverser une plage puis repartir, les transactions peuvent être réordonnées, et les fees ou le slippage peuvent changer le résultat.

Les versions les plus sûres utilisent des permissions limitées, évitent l’effet de levier, gardent les claims entièrement collatéralisés, et rendent l’annulation et le retrait disponibles même en cas d’échec de l’automatisation. Les versions plus complexes rééquilibrent en continu les positions, capitalisent les fees, émettent des parts de vault, ou dépendent d’un keeper offchain. Ces ajouts rapprochent la conception d’un vault géré et augmentent son risque. Les lecteurs qui comparent ce schéma devraient aussi examiner les risques de liquidité concentrée pour les LPs, notamment la perte impermanente, la liquidité inactive et la sélection adverse.

Schémas à risque plus élevé, anti-MEV, TWAMMs et lending

Risque relatif, moyen à élevé. Schémas de hooks à fee dynamique et anti-MEV. MEV, ou maximal extractable value, est la valeur obtenue en contrôlant l’ordre des transactions. Un hook anti-MEV peut utiliser des batch auctions, des ordres chiffrés, un flux d’ordres privé, des étapes commit-and-reveal, des speed bumps, ou des fees qui augmentent lorsque le comportement de trading semble prédateur. Ces mécanismes peuvent réduire une attaque particulière sous certaines hypothèses, mais aucun callback générique ne peut éliminer tout le MEV.

Une conception anti-MEV peut simplement déplacer la confiance ailleurs. Un relay privé peut censurer des ordres, un séquenceur peut conserver le pouvoir d’ordonnancement, une batch auction peut dépendre d’un solver, et une formule de détection peut pénaliser un arbitrage légitime tout en manquant un attaquant sophistiqué. Les hooks de capture du MEV vont plus loin en essayant de rediriger la valeur d’arbitrage vers les LPs ou un autre destinataire. Cela soulève des questions sur la précision de l’oracle, la concurrence dans l’auction, l’inclusion des transactions, la comptabilité des rebates et qui contrôle les revenus capturés. Ces conceptions ont besoin de tests économiques adversariaux ainsi que d’un audit de code conventionnel.

Risque relatif, élevé. Hooks TWAMM. Un time-weighted average market maker, ou TWAMM, découpe un large order en petites transactions virtuelles exécutées dans le temps. L’idée précède v4 et peut réduire l’impact immédiat sur le prix d’un gros trade. Un hook peut conserver l’état des ordres de long terme et régler des portions de ces ordres lorsque les pools sont touchés, mais il doit gérer une activité clairsemée, les annulations, les claims partiels, les arrondis, la croissance des fees et les mouvements de prix entre les intervalles d’exécution.

Risque relatif, très élevé. Hooks de lending utilisant Uniswap v4 avec Aave ou Compound. Un hook de lending peut déposer des liquidités inutilisées dans un lending market, emprunter contre des actifs LP, router des swaps via des positions collatéralisées, ou ajuster automatiquement la dette. Le gain potentiel en efficacité du capital s’accompagne d’un risque empilé. Le hook, Uniswap v4, le protocole de lending, son oracle, les mécanismes de liquidation, les tokens pris en charge et les contrôles de gouvernance peuvent chacun échouer. Aave ou Compound peuvent faire l’objet d’examens approfondis, mais le code d’intégration peut toujours approuver le mauvais actif, mal lire des soldes portant intérêt, dépasser des limites de collatéral sûres, ou rendre les retraits indisponibles lorsque les prêteurs en ont le plus besoin.

Comment décider si un hook est prêt à être déployé

Commencez par l’autorité, pas par la description du produit. Identifiez chaque callback, chaque appel externe, chaque approbation d’actif, chaque rôle administratif, chaque mécanisme d’upgrade, chaque oracle, chaque keeper et chaque contrôle d’urgence. Déterminez si le hook peut prendre la garde des actifs, créer de la dette, retourner des deltas personnalisés, bloquer les retraits, modifier les fees sans délai, ou rediriger des revenus. Si la documentation ne peut pas répondre à ces questions au niveau de l’adresse déployée, les LPs ne disposent pas d’assez d’informations pour évaluer le pool.

Les labels d’audit exigent une lecture attentive. Le cœur d’Uniswap v4 et les composants officiels de periphery ont reçu des revues de plusieurs équipes de sécurité et des tests approfondis, mais ces revues ne s’étendent pas automatiquement aux hooks tiers. De grandes bibliothèques comme les utilitaires de hooks v4 d’OpenZeppelin peuvent fournir des briques vérifiées, mais l’état du dépôt, le périmètre, la version et les exclusions doivent être vérifiés au moment du déploiement. Les exemples expérimentaux issus de hackathons, d’incubateurs, de dépôts modèles ou de projets de recherche ne devraient pas être présentés comme audités pour la production à moins qu’un rapport publié couvre le commit et la configuration exacts.

Un déploiement crédible devrait fournir la vérification du source, des tests pour les invariants de callback et de settlement, du fuzz testing, un audit indépendant, des preuves de remédiation et un bug bounty significatif. Le fuzzing stateful est particulièrement utile car il génère de longues séquences de swaps, dépôts, retraits, annulations et appels externes pour trouver des états que les tests unitaires ordinaires manquent. Pour les systèmes de lending ou de MEV, la revue devrait aussi inclure les attaques économiques, la manipulation d’oracle, le stress de liquidation et les périodes où l’infrastructure externe cesse de répondre.

Les LPs devraient quand même dimensionner leur exposition en fonction de l’échec, pas du marketing d’audit. Privilégiez des contrôles immuables ou fortement retardés, des dépôts plafonnés pendant la phase initiale, des approbations de tokens isolées et un chemin de sortie clair. Évitez les hooks non audités dotés de capacités significatives de garde ou d’emprunt. La possession de UNI n’offre pas d’assurance directe contre une défaillance d’un hook, et la visibilité de la gouvernance ne doit pas être confondue avec la responsabilité du code tiers. Il s’agit d’un cadre de risque technique, pas d’un conseil financier.

Suivez le risque des hooks Uniswap v4 avec davantage de contexte

Le développement d’Uniswap v4 évolue rapidement, et un titre sur un lancement, un audit, un exploit, une pause ou une intégration indique rarement aux LPs quel contrat et quelle hypothèse sont concernés. Zippfeed organise la couverture liée à Uniswap, UNI, DeFi et aux hooks avec une notation de sentiment bullish, neutral ou bearish, ainsi qu’un niveau d’importance, afin de vous aider à distinguer les mises à jour de sécurité significatives des promotions de routine avant d’examiner vous-même le code source et les rapports.