Aave V4 : Du marché fragmenté à la liquidité modulaire

Article : Tia, Techub News

Dans le domaine du prêt DeFi, Aave a toujours été un phare d’innovation et de référence sectorielle. Avec l’augmentation du nombre d’utilisateurs et la diversité des actifs, Aave V3 a progressivement révélé des problèmes liés à la fragmentation de la liquidité, à la gestion des risques et à la mécanique de liquidation, souvent approximatives. Pour relever ces défis, Aave V4 a subi une refonte systémique : la organisation de la liquidité a été repensée en un architecture unifiée Hub et modulaire Spoke, permettant le partage de liquidités entre multi-actifs et multi-stratégies tout en maintenant l’isolement des risques ; le système comptable a été mis à niveau vers un modèle de parts de style ERC-4626, rendant l’état global de la liquidité clair et contrôlable ; la mécanique de liquidation est passée d’un mode à proportion fixe à une logique dynamique centrée sur le facteur de santé, avec une liquidation minimale nécessaire. Dans l’ensemble, V4 ne se limite pas à une simple optimisation paramétrique, mais représente une évolution architecturale et mécaniste synergique, faisant évoluer Aave d’un protocole de prêt fragmenté multi-marchés vers une infrastructure modulaire plus évolutive, efficace en capital et contrôlable en risque.

Du « marché » centré de V3, à la réalité de la fragmentation de la liquidité

Dans Aave V3, le protocole adopte une approche de déploiement basée sur un « marché » central. Sur différents réseaux, voire même au sein d’un même réseau, Aave divise ses activités en plusieurs marchés indépendants, par exemple entre Core et Prime sur le réseau principal Ethereum. Chaque marché dispose de pools de liquidités, de portefeuilles d’actifs supportés et de paramètres de risque entièrement distincts, formant ainsi des profils de risque propres.

Lorsque l’utilisateur fournit des actifs à Aave V3, il dépose en réalité ses actifs dans un marché spécifique, et non dans une pool globale partagée. Cela signifie que les actifs déposés sur le marché Ethereum Core ne peuvent être utilisés que par les emprunteurs de ce même marché, et ne sont pas accessibles par Prime ou d’autres réseaux.

Ce design offre un avantage clair en termes d’isolement des risques : les marchés ne se transmettent pas mutuellement leurs risques. En revanche, le coût est aussi évident : la liquidité est fragmentée. Même pour un même actif, la dispersion sur plusieurs marchés complique la gestion centralisée, impactant l’utilisation globale du capital, la profondeur des marchés et la capacité à déployer de nouvelles fonctionnalités.

Hub et Spoke : la réorganisation de la liquidité dans Aave V4

La réponse d’Aave V4 à cette problématique est une reconstruction profonde de l’architecture sous-jacente, introduisant un nouveau modèle appelé Hub and Spoke (rayons). Cette conception vise précisément à résoudre les problèmes de fragmentation de la liquidité et de limitations d’expansion présents depuis V3.

Dans V4, la liquidité n’est plus liée à un seul marché, mais chaque réseau intègre un Hub de liquidité unifié, servant de centre pour toutes les fonds. Les actifs fournis par les utilisateurs ne sont plus déposés dans un marché spécifique, mais dans ce Hub central du réseau, responsable de la gestion globale de la liquidité et de la comptabilité essentielle. Par exemple, il veille à ce que le total prêté ne dépasse pas la somme fournie, et enregistre l’utilisation de la liquidité par différents modules.

Ce Hub n’est pas destiné à une interaction directe avec l’utilisateur. Toutes les opérations visibles par l’utilisateur sont regroupées dans une couche hautement modulaire appelée Spoke.

Spoke : une interface modulaire où le risque est localisé

Les Spoke constituent la couche frontale avec laquelle l’utilisateur interagit concrètement avec le protocole. Chaque Spoke est connecté au même Hub de liquidité, mais peut disposer de règles, paramètres et hypothèses de risque totalement différents. Le Spoke gère localement les positions, la structure des collatéraux, l’intégration des oracles et la mécanique de liquidation, tandis que le Hub fournit en arrière-plan une capacité de liquidité limitée, en respect des quotas.

L’intérêt de cette division de responsabilités est : le risque est strictement contenu dans chaque Spoke, sans se propager à l’échelle du système. Les besoins en prêt pour différents types d’actifs ou comportements ne partagent plus les mêmes paramètres de risque, mais peuvent partager la liquidité tout en séparant la logique de risque.

C’est aussi pourquoi plusieurs fonctionnalités, auparavant lourdes à mettre en œuvre dans V3, deviennent plus naturelles dans V4. Par exemple, l’E-Mode ne se limite plus à une configuration paramétrique, mais peut exister comme un Spoke dédié à un portefeuille d’actifs fortement liés. Le mode d’isolement peut aussi être réalisé via un Spoke dédié, avec un plafond clair sur la liquidité qu’il peut utiliser. Pour les RWA ou structures de collatéral plus complexes, V4 permet d’introduire des Spoke personnalisés avec des règles d’accès et de risque renforcées, sans complexifier l’ensemble du protocole.

Comment V4 gère-t-il la comptabilité de la liquidité unifiée ?

Pour supporter cette liquidité centralisée via le Hub, V4 abandonne le mécanisme de rebasage des aTokens, et adopte un système de parts de style ERC-4626.

Concrètement, dans V4, le protocole tourne le dos au rebasage traditionnel des aTokens, pour utiliser un système de comptabilité basé sur des parts (shares). Les utilisateurs ne détiennent plus des aTokens dont la quantité augmente automatiquement avec les intérêts, mais des parts fixes, chaque part correspondant à une valeur d’actif sous-jacent qui croît avec le temps. En d’autres termes, la croissance de l’intérêt ne se traduit plus par une augmentation du nombre de tokens, mais par une augmentation de la valeur d’échange de chaque part. Ce système est plus proche de la logique comptable d’un coffre-fort (vault) traditionnel.

Ce modèle de parts est étroitement lié à la conception de liquidité unifiée dans V4. Tous les actifs fournis sont regroupés dans le Hub, qui utilise un système de parts pour suivre précisément l’état global. Le Hub n’a pas besoin de connaître la stratégie spécifique ou le risque de chaque Spoke : il gère simplement la taille totale de l’actif, le nombre total de parts, et l’utilisation des quotas par Spoke. Cette organisation permet à plusieurs Spoke de partager le même pool d’actifs tout en conservant une comptabilité claire et contrôlable, évitant la complexité et les risques liés au rebasage dans un environnement multi-module.

Si l’on maintenait le rebasage des aTokens, le partage des actifs entre Spoke risquerait de compliquer la synchronisation exponentielle, d’engendrer un risque de déversement et de rendre difficile la gestion précise des quotas. Le système de parts ERC-4626 simplifie ces enjeux, permettant au Hub d’assurer, dans un cadre unifié, une gestion sûre et contrôlée de stratégies multi-actifs et de configurations de risque. Cela optimise non seulement l’efficacité du capital, mais pose aussi une base solide pour la modularité et l’expansion future de V4.

La liquidation : une mécanique affinée pour plus de précision

Au-delà de la refonte de la liquidité, V4 ajuste également la mécanique de liquidation. Contrairement à la logique précédente basée sur un ratio fixe, V4 introduit un moteur de liquidation orienté par le risque.

Dans V3 et versions antérieures, lorsque le facteur de santé d’un position tombait sous un seuil de sécurité, la liquidation permettait une récupération partielle en remboursant une partie de la dette selon un facteur de close, avec confiscation du collatéral. Cette approche était efficace pour la sécurité, mais pouvait conduire à des liquidations excessives lors de fortes volatilités ou de marges proches du risque, dépassant parfois largement ce qui était nécessaire pour rétablir la sécurité.

V4 replace cette logique par une focalisation sur le objectif de sécurité : lorsqu’un positionnement devient liquidable, le système calcule la quantité minimale de dette à rembourser et de collatéral à liquider pour ramener le facteur de santé dans une zone sûre. La liquidation n’est plus conçue pour maximiser la réduction du risque, mais pour minimiser la perte nécessaire, en évitant d’aliéner inutilement les actifs des utilisateurs.

Ce changement transforme le close factor d’un paramètre statique en un résultat dynamique, dicté par la situation de risque de chaque position. La taille de la liquidation variera en fonction de la volatilité, de la structure de collatéral, et des paramètres de risque, rendant la mécanique plus fidèle au risque réel. Elle contribue également à limiter l’impact des liquidations, réduisant les ventes forcées d’actifs et les effets de contagion.

Ce nouveau mécanisme s’évoque souvent avec la logique de Fluid. Techniquement, il améliore considérablement la finesse de la liquidation de l’Aave, évitant l’approche « à la hache » d’autrefois, pour une gestion plus précise et adaptée au risque.

Mais contrairement à Fluid, qui intègre directement la liquidité DEX dans le processus de liquidation pour absorber certains risques, Aave reste basé sur un modèle où la liquidation se fait par des acteurs externes, dans un cadre plus contrôlé. La conception d’Aave privilégie la sécurité et la prévisibilité, même si cela limite parfois la rapidité ou la flexibilité.

En résumé

Dans l’ensemble, Aave V4 n’est pas une révolution totale du modèle existant, mais une évolution mesurée et systémique : en restructurant la liquidité avec l’architecture Hub and Spoke, en modulant la gestion des risques via des Spoke spécialisés, et en affinant la mécanique de liquidation pour plus de précision, Aave se transforme d’un protocole de prêt basé sur un « marché » étendu, en une infrastructure modulaire capable d’accueillir des structures financières plus complexes et diversifiées.