Dans le système actuel Aave V3, le protocole fonctionne selon un modèle de déploiement multi-instance organisé autour de « marchés ». Le marché principal sur le réseau principal Ethereum détient environ 60 milliards de dollars de liquidité, tandis que le marché Prime—conçu pour les utilisateurs ayant une tolérance au risque plus faible—dispose d’environ 2 milliards de dollars. Ces deux marchés opèrent de manière indépendante. Cela signifie que, même si un même actif, tel que l’USDC, dispose de milliards de réserves sur le marché principal, les utilisateurs du marché Prime ne peuvent pas accéder à cette liquidité. Fondamentalement, cette architecture lie étroitement l’allocation du risque à la profondeur de la liquidité propre à chaque marché, obligeant chaque nouveau marché à relever le défi de « constituer sa liquidité à partir de zéro ».
Aave V4 répond directement à cette limitation structurelle. En introduisant une architecture Hub-and-Spoke, elle dissocie complètement le stockage de la liquidité de la logique de marché, permettant ainsi aux nouveaux marchés d’accéder dès le premier jour aux pools de liquidité existants.
Comment la séparation Hub et Spoke permet d’unifier la liquidité tout en isolant le risque
L’architecture Hub-and-Spoke redéfinit fondamentalement les rôles. Le Hub de Liquidité agit comme un pool centralisé, gérant l’ensemble de la réserve d’actifs, les autorisations d’emprunt et les contraintes comptables, garantissant que le volume total des prêts ne dépasse jamais le plafond de liquidité. Les modules Spoke servent d’interfaces utilisateur dédiées. Chaque Spoke peut définir indépendamment les types d’actifs supportés, les paramètres de risque, les règles de liquidation et les configurations d’oracle, tout en puisant la liquidité auprès du Hub dans des limites prédéfinies. Le point clé ici est que la liquidité n’est plus confinée aux frontières d’un marché spécifique. Elle existe désormais comme un « pool partagé » au niveau du Hub, auquel plusieurs Spokes peuvent accéder en parallèle selon les limites de crédit fixées par la gouvernance. Parallèlement, le risque reste strictement circonscrit à chaque Spoke. Même si un Spoke enregistre une dette irrécouvrable en raison de la volatilité d’un actif ou d’une liquidation échouée, cela n’impacte ni le Hub ni les autres Spokes.
Le coût de l’unification : compromis d’efficacité et complexité de la gouvernance dans une architecture modulaire
Toute refonte architecturale implique des compromis. Si le modèle Hub-and-Spoke résout la fragmentation de la liquidité, il introduit de nouveaux coûts structurels. Premièrement, le Hub doit assumer des responsabilités comptables globales plus complexes. V4 abandonne le mécanisme de rebase des aTokens de V3 au profit d’un modèle de parts de type ERC-4626. Chaque part représente une valeur sous-jacente qui croît avec les intérêts accumulés, permettant un suivi précis de l’utilisation des quotas de chaque Spoke au sein du pool unifié. Deuxièmement, la gouvernance devient plus complexe. La DAO définit les paramètres de risque pour chaque Spoke, mais l’allocation des limites de crédit, la coordination des taux d’intérêt et la gestion des liquidations entre Spokes nécessitent un cadre de gouvernance plus sophistiqué. Troisièmement, des controverses sur la trajectoire de migration ont déjà émergé au sein de la communauté. Aave Labs avait proposé de suspendre l’optimisation de V3 pour inciter les utilisateurs à migrer vers V4, proposition qui a rencontré une forte opposition des contributeurs principaux. Elle a finalement été retirée, avec l’engagement de ne pas imposer la migration. Cela souligne que les mises à niveau techniques doivent aussi garantir une transition fluide de l’écosystème existant.
Du protocole à l’infrastructure : ce que cela implique pour le paysage du prêt DeFi
L’évolution vers V4 fait passer Aave d’un « protocole de prêt multi-marchés parallèles » à une « infrastructure modulaire capable de supporter des logiques financières diversifiées ». Ce changement aura plusieurs impacts à l’échelle du secteur. Premièrement, une meilleure efficacité du capital redéfinira les standards de compétitivité dans le prêt. Les nouveaux marchés n’ont plus à rivaliser avec les marchés existants pour attirer les dépôts. Les développeurs peuvent se concentrer sur des logiques de prêt personnalisées pour de nouveaux actifs comme Pendle PT, les positions Uniswap LP ou Ethena sUSDe, sans avoir à constituer la liquidité depuis zéro. Deuxièmement, la tarification du risque passe d’une approche « universelle » à un modèle plus granulaire. V4 introduit une prime de liquidité, ajustant dynamiquement les taux d’emprunt selon le profil de liquidité des actifs en garantie. Les actifs de référence comme l’ETH conservent une prime nulle, tandis que les actifs plus volatils supportent des primes plus élevées. Troisièmement, l’intégration renforcée du stablecoin GHO consolide davantage la boucle interne du protocole. Le mécanisme de liquidation douce (LLAMM) permet au système de convertir progressivement la garantie en GHO lorsque les prix baissent, puis de racheter la garantie lorsque les prix remontent, améliorant ainsi l’efficacité et la stabilité des liquidations.
Perspectives après V4 : évolutions possibles pour la couche de liquidité, le prêt inter-chaînes et l’expansion de l’écosystème
L’architecture de V4 ne se contente pas de résoudre les défis actuels, elle ouvre également la voie à de futures extensions. D’abord, la couche de liquidité unifiée se prête naturellement au prêt inter-chaînes. Les utilisateurs peuvent déposer des actifs sur une chaîne et emprunter sur une autre, la couche de liquidité servant de hub abstrait pour la compensation et la comptabilité inter-chaînes. Ensuite, la composabilité des Spokes permet l’émergence de marchés secondaires de dette, de marchés de crédit à terme fixe ou de lignes de crédit dynamiques pour les positions AMM—des primitives financières complexes deviennent envisageables. Les développeurs n’ont plus qu’à se concentrer sur la logique métier au niveau du Spoke, tandis que les cadres sous-jacents de liquidation et de gestion du risque peuvent s’appuyer sur les modules éprouvés d’Aave. Par ailleurs, l’écosystème Aave explore une « couche réseau indépendante », prévoyant de lancer un réseau dédié comme infrastructure centrale pour GHO et les opérations de prêt. Bien que ce concept en soit encore à ses débuts, il traduit la volonté stratégique des principaux protocoles DeFi de tendre vers une pile technologique plus complète.
Risques et limites : dangers potentiels non résolus par la nouvelle architecture
Malgré les avancées majeures de V4 sur le plan architectural, certains volets de risque restent à traiter. Premièrement, même si la liquidation est passée d’un « ratio fixe » à une « liquidation minimale nécessaire », elle repose toujours sur des liquidateurs externes tiers. Comparé à des modèles comme Fluid, qui intègrent profondément le prêt à la liquidité DEX, ce choix présente des écarts en termes de structure de coûts et d’efficacité d’exécution. Deuxièmement, dans un environnement multi-Spoke, la surveillance globale du risque entre Spokes n’est pas encore mature. Lorsque plusieurs Spokes accèdent simultanément à la liquidité du Hub avec des modèles de risque différents, les mécanismes d’identification et d’alerte de risque systémique restent à prouver. Troisièmement, si le mécanisme de liquidation douce de GHO s’inspire du modèle LLAMM de crvUSD, ses performances réelles en conditions de marché extrêmes manquent encore de données de tests de résistance à grande échelle. Enfin, les différends de gouvernance—comme le renouvellement des contrats des contributeurs principaux ou les conflits d’allocation des ressources entre V3 et V4—soulignent le risque de division communautaire lors des mises à jour majeures.
Résumé
Le lancement sur le réseau principal d’Aave V4 marque un changement de paradigme pour les protocoles de prêt DeFi—passant d’un modèle « multi-marchés parallèles » à une architecture « couche de liquidité unifiée + unités de risque modulaires ». Le design Hub-and-Spoke résout le problème historique de la fragmentation de la liquidité et pose un cadre fondamental pour l’intégration de nouveaux types d’actifs, le prêt inter-chaînes et la tarification granulaire du risque. Toutefois, des défis subsistent concernant la complexité de la gouvernance, les lacunes de la surveillance globale du risque et la coordination communautaire lors de la migration. Pour le secteur du prêt DeFi, V4 n’est pas seulement une mise à jour de version—c’est une expérimentation structurelle sur la façon dont les protocoles évoluent vers l’infrastructure.
FAQ
Q1 : Quelle est la différence fondamentale entre Aave V4 et V3 en matière de gestion de la liquidité ?
V3 fonctionne selon un modèle de marchés indépendants, chaque marché conservant son propre pool de liquidité et les actifs n’étant pas partagés entre marchés. V4 introduit l’architecture Hub-and-Spoke, où toute la liquidité est centralisée dans le Hub de Liquidité. Plusieurs Spokes partagent le même pool, tout en gérant indépendamment leurs paramètres de risque.
Q2 : Comment l’architecture Hub-and-Spoke empêche-t-elle la propagation du risque dans le système ?
Le risque est contenu au sein de chaque Spoke. Chaque Spoke dispose de sa propre liste d’actifs, de règles de liquidation et de limites de quotas. Même si un Spoke accumule une dette irrécouvrable, cela n’affecte ni le Hub ni les autres Spokes. Le Hub se limite à la comptabilité globale et à la gestion des quotas, sans assumer directement le risque de crédit des Spokes.
Q3 : Quelles sont les principales évolutions apportées par V4 au stablecoin GHO ?
Les évolutions majeures incluent : l’introduction d’un mécanisme de liquidation douce (LLAMM), qui liquide progressivement la garantie en cas de volatilité des prix au lieu d’une liquidation forcée en une seule fois ; la prise en charge du paiement des intérêts sur les stablecoins en GHO ; et l’ajout d’un mécanisme de rachat d’urgence pour faire face à des cas extrêmes de perte d’ancrage du GHO.
Q4 : Les utilisateurs de V3 doivent-ils migrer après le lancement de V4 ?
Aave Labs a retiré la proposition de migration forcée et s’est engagé à faire fonctionner V3 et V4 en parallèle, si bien qu’aucune migration n’est imposée aux utilisateurs. Le déploiement initial de V4 s’effectuera avec des paramètres prudents et une liste d’actifs restreinte pour privilégier la sécurité.
Q5 : En quoi le mécanisme de liquidation de V4 diffère-t-il de celui de V3 ?
V3 utilise un facteur de clôture à ratio fixe pour les liquidations, ce qui peut entraîner des liquidations excessives. V4 adopte une logique de liquidation dynamique basée sur le facteur de santé, où le système calcule le montant minimal de liquidation nécessaire—ne remboursant que la dette suffisante pour ramener la position en zone de sécurité.
