Comprendre la mauvaise dette d'Aave : des restes aux…

Le fonctionnement de la mauvaise dette d'Aave est simple dans son résultat et compliqué dans son exécution : une liquidation peut vendre tous les collatéraux et laisser une dette impayée. Dans Aave v3.3, ce reste est immédiatement cristallisé en brûlant les jetons de dette variable restants de l'emprunteur et en enregistrant le déficit comme un déficit de réserve.

Points clés

• La mauvaise dette d'Aave est un état spécifique post-liquidation où un compte a zéro collatéralmais a encore une dette restante.
• Aave v3.3 empêche les passifs « zombies » de s'accumuler en brûlant les jetons de dette variable restants de l'emprunteur et en enregistrant le déficit comme un déficit par réserve.
• Les déficits de réserve sont suivis par actifdans ReserveData et exposés via un getter de Pool, rendant les pertes mesurables au lieu de dériver de manière invisible.
• Les déficits peuvent être réduits par une entité Umbrella autorisée brûlant des aTokens, et le staking Umbrella est conçu pour réduire les coffres spécifiques aux actifs une fois que la mauvaise dette dépasse des seuils.

Ce que signifie « mauvaise dette » sur Aave (définition en termes simples)

« Comment fonctionne la mauvaise dette d'Aave » commence par une définition précise, pas une impression. Sur Aave, la mauvaise dette n'est pas « un emprunteur risqué » ou « une liquidation qui a mal tourné ». C'est un état comptable final après une liquidation où le collatéral de l'emprunteur est entièrement épuisé et une partie de la dette reste impayée. À ce stade, le protocole détient une obligation non couverte.

Cela importe car Aave est un protocole de prêt surcollatéralisé par conception. Le principe est que la valeur du collatéral doit suffire à couvrir la dette par le biais de la liquidation DeFi lorsque une position devient malsaine. La mauvaise dette est ce qui reste lorsque ce mécanisme ne peut pas entièrement boucler la boucle en raison des écarts de prix, des limites de liquidité ou du rythme de liquidation.

La documentation d'Aave v3 reconnaît explicitement le cas limite inconfortable : certains scénarios de liquidation peuvent se terminer avec un collatéral nul et une dette restante, et cette dette est peu susceptible d'être remboursée. Le problème pratique n'est pas seulement la perte. C'est la dérive.

Si le système continue de traiter ce reste comme une dette variable normale, les intérêts continuent de s'accumuler sur un IOU qui n'a aucun collatéral derrière lui, gonflant ainsi la responsabilité apparente du protocole au fil du temps. C'est le mode de défaillance de la "mauvaise dette defi" dont les traders devraient réellement se soucier.

comment fonctionne la mauvaise dette d'Aave

En pratique, le fonctionnement de la mauvaise dette aave est une séquence d'entrées → processus → sorties.

Entrées : un emprunteur dépose une garantie, emprunte un actif, et la position devient sous-garantie à mesure que les prix évoluent. Aave suit cela avec un facteur de santé. Lorsque le facteur de santé tombe en dessous du seuil de liquidation, des liquidateurs tiers peuvent rembourser une partie de la dette de l'emprunteur et recevoir la garantie à un prix réduit grâce au bonus de liquidation.

Processus : la liquidation n'est pas un événement unique et propre. C'est une série de transactions on-chain en concurrence avec des mises à jour d'oracle, l'inclusion de blocs,gazles coûts et la liquidité du marché disponible pour obtenir l'actif de remboursement et vendre le collatéral saisi. Aave v2 utilisait un facteur de clôture fixe qui limitait le montant de la dette pouvant être remboursé par liquidation.

Aave v3 a introduit un facteur de clôture variable qui peut permettre un remboursement allant jusqu'à 100 % dans des conditions de détresse plus profondes, ce qui vise à réduire les "poussières" restantes qui deviennent non économiques à liquider.

Sorties : si les liquidations remboursent toutes les dettes, le système va bien. La mauvaise dette apparaît lorsque les liquidations consomment tous les collatéraux et ne peuvent toujours pas rembourser la totalité de la dette. Cela produit l'état définissant : le collatéral est égal à zéro, la dette est toujours non nulle.

Avant la v3.3, ce reste pouvait continuer à accumuler des intérêts, transformant un manque ponctuel en un problème comptable croissant. Dans la v3.3, le protocole traite ce reste comme une perte au niveau du protocole immédiatement après la liquidation en brûlant les tokens de dette variable restants et en enregistrant un déficit de réserve pour cet actif.

Comment la mauvaise dette est créée : mécanismes de liquidation et cas limite de "collatéral insuffisant"

La liquidation est souvent décrite comme "facteur de santé < 1, donc la dette est remboursée." Le flux de liquidation dans le monde réel est plus proche d'une enchère contrainte avec des limites strictes. Les liquidateurs n'agissent que lorsque la transaction est rentable après les frais de gaz et le risque d'exécution, et les règles de facteur de clôture du protocole limitent combien peut être remboursé par transaction.

Le guide de Bitget capture les mécanismes de base : la liquidation se déclenche lorsque le facteur de santé tombe en dessous du seuil, et les liquidateurs remboursent la dette en échange de collatéraux à un prix réduit.

Il note également la différence de facteur de clôture entre les versions, avec Aave v2 permettant jusqu'à 50 % de remboursement par liquidation et Aave v3 permettant jusqu'à 100 % de remboursement lorsque le facteur de santé se détériore davantage (un seuil d'exemple autour de 0,95 est cité).

La mauvaise dette est créée lorsque le moteur de liquidation fait son travail, mais le marché évolue plus rapidement que le moteur ne peut gérer le risque. Les écarts de prix peuvent faire en sorte que le collatéral vaille moins que prévu entre les mises à jour de l'oracle. Une liquidité faible peut rendre coûteux l'approvisionnement de l'actif à rembourser ou de se débarrasser du collatéral saisi sans glissement.

Les mécanismes de facteur de clôture peuvent forcer la liquidation à se produire par morceaux, ce qui est acceptable dans des marchés lents et dangereux dans des mouvements discontinus.

La documentation d'Aave v3.3 est explicite sur le cas limite : la liquidation peut entraîner un collatéral total liquidé insuffisant pour couvrir le remboursement de toutes les dettes, laissant un collatéral nul et une dette restante. C'est à ce moment que le problème de l'emprunteur devient un problème comptable du protocole.

Gestion de la mauvaise dette dans Aave v3.3 : brûler la dette restante de l'emprunteur, enregistrer un déficit de réserve

Le changement clé d'Aave v3.3 n'est pas "prévenir la mauvaise dette." C'est "stopper la mauvaise dette de muter." Le protocole introduit une étape de vérification post-liquidation conçue pour atténuer la création de nouveaux comptes de mauvaise dette après liquidation et arrêter l'accumulation d'intérêts supplémentaires sur ces passifs.

Mécaniquement, le protocole vérifie le compte après liquidation et remboursement. Si le compte se termine avec un collatéral nul et une dette non nulle, la dette restante est brûlée et le manque résultant est comptabilisé dans la réserve pertinente comme un déficit. Les documents décrivent ce nettoyage comme se produisant conceptuellement après la liquidation réelle, ce qui est le bon modèle mental pour les traders. La liquidation est la transaction. Le nettoyage est la réconciliation.

C'est la thèse v3.3 sous forme de code : la mauvaise dette n'est plus autorisée à rester sur un utilisateur et à s'accumuler indéfiniment. Elle est cristallisée en un déficit au niveau de la réserve qui peut être suivi par actif. La v3.3 introduit le suivi des déficits à l'intérieur de ReserveData en réutilisant le stockage de stableBorrowRate obsolète, et l'expose via un getter de Pool getReserveDeficit. Cela rend le trou pointable, réserve par réserve, au lieu d'être enfoui dans des mathématiques d'intérêts dérivants.

Il y a également un traitement spécial pour GHO. La v3.3 divise la liquidation en une combustion de dette variable et un gestionnaire de remboursement aGHO qui applique des remises sur les frais.

Lors de la combustion de la mauvaise dette en GHO, le protocole réinitialise le stockage des frais accumulés sur vGHO et accepte effectivement la perte sur les frais accumulés pour la portion de mauvaise dette afin de maintenir la comptabilité cohérente. Ce détail est important car il montre l'intention.

L'objectif est un nettoyage déterministe, sans laisser de revendications de frais obsolètes attachées à un compte qui n'a plus de jetons de dette.

comment fonctionne le module de sécurité d'aave

Le module de sécurité hérité est mieux compris comme un filet de sécurité médié par la gouvernance plutôt qu'un moteur d'assurance toujours actif. Blockworks le décrit comme un filet de sécurité où les positions stkAAVE et AAVE-ETHpourrait théoriquement être réduites, mais la réduction n'est jamais survenue car elle nécessitait des votes de gouvernance et les incitations politiques rendaient l'activation peu probable.

En termes de risque pratique, cela signifie que la valeur du module de sécurité était la crédibilité, pas l'automatisation. Cela signalait qu'un groupe aligné sur un jeton de gouvernancepouvait recapitaliser les pertes, mais cela ne garantissait pas une absorption rapide et déterministe des pertes pendant un marché rapide.

C'est pourquoi la comptabilité de la mauvaise dette de la v3.3 est importante même s'il existe un filet de sécurité. Si la mauvaise dette est autorisée à rester sur les comptes des utilisateurs et à accumuler des intérêts, le protocole ne peut même pas mesurer proprement la perte, ce qui rend toute décision de filet de sécurité plus difficile.

En transformant le déficit en une réserve déficitaire, Aave rend la question du module de sécurité plus concrète : combien de déficit existe-t-il, sur quel actif, et quel mécanisme est autorisé à le neutraliser.

qui paie lorsque aave a une mauvaise dette

Une fois que la mauvaise dette est reconnue dans v3.3, le montant impayé n'est plus « dû par l'emprunteur » dans un sens économique significatif. L'emprunteur n'a plus de garantie, et le protocole a brûlé les tokens de dette variable restants pour arrêter l'accumulation d'intérêts. La perte est enregistrée comme un déficit sur la réserve spécifique.

Cette formulation répond à la question de qui paie en pratique : la réserve est insuffisante, et le système a besoin d'une recapitalisation pour restaurer un soutien complet. v3.3 introduit eliminateReserveDeficit, où une entité autorisée, l'Umbrella enregistrée sur le PoolAddressesProvider, peut brûler des aTokens pour diminuer le déficit de cette réserve.

La fonction est limitée à brûler jusqu'au déficit existant et valide que l'appelant n'a pas de positions d'emprunt ouvertes.

Ce n'est pas un vague « le fonds d'assurance pourrait le couvrir ». C'est une action spécifique sur la chaîne qui réduit un déficit suivi en détruisant des droits sur la réserve (aTokens). La conséquence économique est directe. Quelqu'un détenant les actifs de couverture subit la perte afin que les déposants de cette réserve soient à nouveau remboursés.

La description d'Umbrella staking par Blockworks ajoute la couche opérationnelle. Umbrella est présenté comme un filet de sécurité automatisé lié à des actifs individuels, avec une réduction en temps réel une fois que la mauvaise dette sur cet actif dépasse un seuil prédéfini, après un offset de première perte configurable qui était rapporté comme 100 000 unités par actif à l'époque.

C'est la réponse pratique à « qui paie » dans un système conçu : les stakers dans le coffre de l'actif concerné, au-dessus du tampon d'offset, plutôt qu'un pool généralisé nécessitant un vote de gouvernance.

aave a-t-il déjà eu de la mauvaise dette auparavant

Oui, et l'événement CRV de 2022 est l'illustration la plus claire de pourquoi « il suffit de le liquider » n'est pas une garantie. L'étude de cas d'EigenPhi décrit un short CRV qui a entraîné environ 2,456 millions de CRV impayés après liquidations, évalués autour de 1,6 million de dollars au prix CRV cité.

L'activité de liquidation n'était pas triviale. EigenPhi rapporte 385 liquidations par 21 adresses uniques. Le point n'est pas que les liquidateurs étaient absents. Le point est que le débit de liquidation et le timing des oracles peuvent encore laisser un résidu de dette lorsque les marchés évoluent par à-coups.

EigenPhi note également un retard de prix oracle d'environ 10 minutes par rapport à Binance et décrit un comportement de liquidation qui arrivait par lots. Cette combinaison est exactement l'environnement où la garantie peut être épuisée avant que la dette ne soit entièrement remboursée. La définition de la mauvaise dette par Aave v3.3 comme « garantie épuisée avant que la dette ne soit entièrement remboursée » n'est pas théorique. C'est un état qui s'est déjà produit sous pression.

qu'est-ce que le module umbrella d'aave

Umbrella est le nouveau design de sécurité d'Aave qui essaie de rendre l'absorption des pertes à la fois automatique et spécifique aux actifs. Blockworks décrit l'Umbrella staking comme un filet de sécurité automatisé sur la chaîne lié directement à des actifs individuels, mis en œuvre sous forme de coffres isolés.

En cas de déficit, le protocole peut brûler le même actif de son coffre après un offset de première perte configurable, rapporté comme 100 000 unités par actif à l'époque.

La partie « spécifique à l'actif » est le véritable changement de conception. Au lieu de socialiser le risque à travers un large soutien de jetons de gouvernance, Umbrella cible la réserve qui a réellement le déficit. Cela s'aligne avec le suivi des déficits par réserve de la v3.3.

Si le protocole peut mesurer un déficit sur USDC par rapport à ETH par rapport à GHO, un soutien qui est également segmenté par actif est opérationnellement plus clair.

Umbrella change également la dimension temporelle. Blockworks souligne qu'il n'y a pas de vote de gouvernance, pas d'enchères et pas de délai pour le slashing une fois que les seuils sont dépassés. Cela compte car la mauvaise dette naît généralement dans des marchés rapides. Un soutien qui ne s'active qu'après un long processus de gouvernance est structurellement mal adapté au problème.

Aave peut-il devenir insolvable

Aave peut faire face à l'insolvabilité au niveau de la réserve lorsque les passifs dépassent les actifs pour un marché donné, ce que représente exactement un déficit de réserve. Aave v3.3 ne prétend pas le contraire. Il formalise le déficit afin qu'il puisse être suivi et potentiellement neutralisé.

La nuance clé est la portée. La v3.3 définit une situation de mauvaise dette de manière étroite comme un compte avec zéro collatéral en monnaie de base et une dette restante en monnaie de base. Les comptes avec un collatéral restant ne sont pas considérés comme une mauvaise dette car ils pourraient redevenir surcollatéralisés. C'est une ligne pratique. L'insolvabilité concerne les passifs non couverts, pas les positions temporairement malsaines.

La v3.3 documente également des limitations qui comptent pour quiconque modélisant le risque de queue. Elle ne corrige pas les positions de mauvaise dette déjà existantes et recommande un nettoyage par le DAO via repayOnBehalf.

L'élimination du déficit suppose qu'Umbrella dispose de jetons à brûler, et des contraintes opérationnelles comme des plafonds et une comptabilité virtuelle peuvent affecter la rapidité avec laquelle les actifs de couverture peuvent être positionnés.

Cela signifie que le système peut reconnaître et arrêter la capitalisation de nouvelles dettes zombies, mais la recapitalisation reste conditionnelle à la configuration du soutien et à la couverture disponible.

Idées reçues courantes

La première idée reçue est que « la mauvaise dette signifie que les liquidations ont échoué. » Les liquidations peuvent s'exécuter exactement comme prévu et se terminer avec zéro collatéral et une dette restante parce que la conception est contrainte par des facteurs proches, l'économie de gaz, la cadence de mise à jour des oracles et la liquidité du marché secondaire. L'étude de cas CRV montre une forte activité de liquidation et pourtant un montant impayé résiduel.

La deuxième idée reçue est que « la mauvaise dette n'est qu'un prêt impayé d'un emprunteur. » Sur Aave v3.3, une fois que le protocole brûle les jetons de dette variable restants de l'emprunteur, l'emprunteur n'est plus l'endroit où vit le passif.

La perte est comptabilisée comme un déficit de réserve, par actif, et la question devient comment ce déficit est réduit par des mécanismes comme eliminateReserveDeficit et le slashing du coffre d'actifs d'Umbrella.

La troisième idée reçue est que « Aave v3.3 élimine toute mauvaise dette. » La v3.3 empêche de nouveaux comptes zombies post-liquidation d'accumuler des intérêts en brûlant la dette restante et en enregistrant un déficit, mais les documents déclarent explicitement qu'elle ne résout pas les positions de mauvaise dette déjà existantes. La conclusion pratique est que la v3.3 améliore le déterminisme et la transparence, pas les lois de l'écart de marché.

Ce sujet s'inscrit dans les mécanismes plus larges de ce qu'est le DeFi, où la surcollatéralisation et la liquidation sont les principales sécurités. Pour les lecteurs qui cartographient le risque des protocoles, la prochaine étape utile est de revenir au guide principal sur ce qu'est le DeFi et de traiter la mauvaise dette comme un problème de déficit de réserve mesurable, et non comme une histoire morale sur des emprunteurs imprudents.

Sources

• Aave DAO (documentation Aave v3.3)
• Blockworks
• EigenPhi
• Bitget Academy