Aave V4 franchit le cap du milliard de dollars de dépôts

Fin mars, Aave a lancé sa V4, une nouvelle version de son protocole de prêt avec une approche simple, ouvrir petit, puis élargir au fil de l’eau. Six mois plus tard, l’adoption semble bien présente. En effet, la V4 du protocole a atteint le milliard de dollars en dépôts.

Sur un protocole comme Aave, on ne dépose pas n’importe quelle quantité de n’importe quel actif. Chaque marché a un plafond et au-delà, les dépôts sont refusés. Ces plafonds démarrent bas exprès et les monter, c’est autoriser la croissance. En effet, Aave V4 introduit une nouvelle approche de la gestion des capacités maximales de ses pools.

Points clés

V4 est live depuis le 30 mars 2026. Selon les compteurs, elle tourne autour du milliard de dollars déposés ; le chiffre exact varie d’une source à l’autre.

Cette montée a suivi une série de relèvements de plafonds, pas une ruée spontanée.

La plupart de ces relèvements n’ont pas été votés un par un par les détenteurs d’AAVE.

Ils ont été exécutés par un petit groupe qui contrôle un coffre à plusieurs clés, après une recommandation publique de risque.

Un vote classique prend de l’ordre de deux semaines. Ce comité peut agir en quelques heures.

Annoncée en 2024 par Stani Kulechov, puis reportée, Aave V4 a été déployée sur Ethereum le 30 mars 2026. Son architecture s’appelle Hub and Spoke. Celle-ci se compose d’une réserve de liquidité centrale (le hub) qui alimente des marchés d’emprunt distincts (les spokes), chacun avec ses règles de collatéral. L’idée est de mutualiser l’argent au lieu de le laisser dormir dans autant de silos qu’il y a de marchés. Une approche axée sur l’efficacité du capital.

Mi-septembre, plusieurs décomptes ont fait passer la V4 au-dessus du milliard de dollars d’actifs déposés. Ce sont les calculs présentés par Sumcap.xyz, qui a suivi de près l’évolution de la V4 depuis son déploiement. La V3, elle, dépasse toujours les 30 milliards fournis.

Cette croissance a une manette bien identifiée. Sur la V4, les anciens « supply caps » et « borrow caps » deviennent à peu près des add caps (ce qu’un spoke a le droit de déposer dans le hub) et des draw caps (ce qu’il a le droit d’en emprunter). Un plafond saturé refuse les nouveaux dépôts. Il borne aussi l’exposition d’Aave à un actif. Ainsi, si son prix décroche ou si sa liquidité s’évapore, le volume de créances irrécouvrables possibles reste limité.

Pas un vote à chaque hausse

Jusqu’à la V4, les relèvements de plafond, concrètement, autoriser le protocole à accepter davantage d’un actif, étaient décidé via un vote de gouvernance. Désormais, c’est LlamaRisk, un prestataire de risque mandaté par la DAO, qui publie les « rounds » de relèvements sur le forum. Les changements eux, sont désormais appliqués via le Security Council, un multisig, qui n’exécute une transaction que si plusieurs clés signent. Les détenteurs d’AAVE n’ont pas voté « oui » ou « non » à chaque passage d’un cap de 10 000 à 15 000 ETH. Ils votent les actes lourds : allumer V4, lister un marché, déployer une chaîne, accorder un mandat. Au quotidien les plafonds, eux, sont à la charge de LlamaRisk et du Security Council.

Ainsei, la majorité des hausses qui ont rendu cette croissance possible ont été signées par un multisig plutôt qu’adoptées par un vote on-chain. Autrement dit, ce n’est pas l’assemblée des tokenholders qui a ouvert les vannes une à une.

Les Risk Stewards

Le régime que la DAO a voté dès la V3 s’appelle les Risk Stewards. Il autorise un comité de risque à ajuster certains paramètres sans convoquer tous les détenteurs d’AAVE. Le périmètre est verrouillé par le code : amplitude maximale par update, délai avant de retoucher le même actif, interdiction de lister un nouvel actif ou de sortir des bornes. Ça, c’est le modèle « la DAO fixe le corridor, le comité conduit dedans ».

Sur V4, ce n’est pas encore l’outil qui a fait le gros du chemin. Un ARFC d’août 2026, puis un Snapshot et un AIP (proposition 523), visent à brancher les Stewards sur Ethereum et Avalanche. Fin septembre, LlamaRisk indiquait encore que les ajustements Ethereum et Avalanche passaient par le Security Council, sauf sur Arc, déjà traité via les Stewards.

Les recommandations viennent aujourd’hui surtout de LlamaRisk, avec Aave Labs. Chaos Labs a quitté le dispositif au printemps 2026.

Le gain est principalement temporel. Forum, Snapshot d’environ cinq jours, vote on-chain, délai d’exécution, l’ensemble de la procédure prenait avant environ deux semaines. Le Council ou Steward ramènent ça à quelques heures.

La tension reste la même, le contrat n’est pas le même

Une poignée de clés qui arbitre l’exposition d’un marché qui vise le milliard colle mal à l’image d’un protocole gouverné de manière décentralisée. Historiquement, l’Aave Chan Initiative, longtemps l’un des principaux délégués, fondée par Marc Zeller, a défendu cette division du travail. ACI a annoncé en mars 2026 qu’elle ne renouvelait pas et s’est mise en retrait. L’argument, lui, n’est pas parti avec l’équipe. Les partisans du vote systématique répondent qu’un mandat trop large finit par vider l’urne de sa substance.

La délégation a aussi un coût de sécurité. Un multisig, ce sont des clés privées. Un Steward borné par le code limite la casse, même compromis, il ne peut ni lister un actif fantôme ni multiplier un plafond par dix d’un seul geste. Le Security Council de la phase de lancement a un mandat plus large, parce que la V4 ouvrait ses portes à vide et qu’il fallait pouvoir ouvrir vite. C’est un autre profil de risque, même si chaque hausse reste une transaction publique, précédée d’une reco datée sur le forum.

Dans une banque, ce genre de comité relève ses limites à huis clos. Chez Aave, on peut relire la transaction. Les détenteurs d’AAVE peuvent révoquer un mandat par un vote. Depuis V3, ils l’ont plutôt élargi. Sur V4, ils commencent seulement à le transposer dans le contrat prévu pour ça.