Hier soir, je tournais sur ce serveur double-socket EPYC, avec quelques scripts de backtest pour des robots de liquidation. Je regardais des centaines de données de liquidations s’afficher en plein écran, et tout à coup, j’ai eu envie d’en parler à tout le monde : dans la DeFi, il y a une chose qui est vraiment la moins présentable… les créances douteuses.
En général, quand on joue avec ces pools de prêts à taux variable, dès qu’il y a une créance douteuse, les équipes de projet font presque toutes la même chose : elles “font semblant” et disparaissent. Comme il n’y a pas de date d’échéance ferme, les mauvais comptes sont étalés au fil du temps, ou bien on organise un vote de gouvernance pour utiliser l’argent du trésor afin de couvrir la brèche. Mais les vieux joueurs qui ont le réflexe “priorité à la survie” savent tous que ce genre d’opérations qui cachent le risque dans une boîte noire… dès qu’on tombe sur un marché extrême, c’est l’ensemble du dispositif qui saute.
C’est aussi pour ça que, après avoir disséqué les smart contracts sous-jacents de TermMax, je me suis particulièrement intéressé à sa dernière étape pour traiter les liquidations. Comme c’est un protocole axé sur des échéances fixes, une fois le jour venu, il faut régler le capital et les intérêts : impossible de faire semblant ou de tergiverser.
Dans le code, ils découpent le processus de liquidation en deux phases. À l’échéance, si l’emprunteur ne peut pas payer, on ouvre d’abord une fenêtre de liquidation “standard” pour que les robots d’arbitrage du marché vendent les collatéraux à bas prix afin de combler le manque. C’est assez classique, non ? Mais ce qui m’a vraiment donné l’impression que ce projet a “quelque chose en plus”, c’est : si cette fenêtre de liquidation se referme et que le trou n’est toujours pas comblé, qu’est-ce qu’on fait ?
TermMax a tout simplement scellé dans le niveau le plus bas une logique de Physical Delivery (livraison physique). Les actifs sous-jacents restant dans le pool, ainsi que les collatéraux, sont distribués directement selon les parts FT détenues par chaque prêteur. En clair : toi, tu attendais tranquillement de récupérer des stablecoins… et au final, ce qui peut finir entre tes mains, c’est une pile de tokens collatéraux déposés à l’époque.
Ça sonne un peu cruel, non ? Mais pour moi, c’est exactement ce type d’architecture qui écrit les mauvaises nouvelles en tout début de contrat — c’est ça, la vraie infrastructure financière au niveau des fondations. Trop de protocoles aiment traiter les créances douteuses avec une gestion floue : personne ne sait vraiment le volume de risque qui flotte au-dessus de sa tête. Tandis que chez TermMax, leurs règles ne laissent aucun espace discrétionnaire à je ne sais quel “administrateur” : l’ampleur du trou, tout le monde la prend en charge au prorata, et la comptabilité est claire et nette. Personne ne peut prétendre s’être “soustrait”.
Dans ce milieu, en bull market on te vante des taux de rendement élevés… mais ils sont tous factices : ce ne sont que des drogues d’envoûtement en temps de beau temps. Seules des règles solides, capables d’étaler sur la table toutes les cartes de liquidation de la mauvaise météo, méritent qu’on s’y attarde.
#TermMax @TermMax
En général, quand on joue avec ces pools de prêts à taux variable, dès qu’il y a une créance douteuse, les équipes de projet font presque toutes la même chose : elles “font semblant” et disparaissent. Comme il n’y a pas de date d’échéance ferme, les mauvais comptes sont étalés au fil du temps, ou bien on organise un vote de gouvernance pour utiliser l’argent du trésor afin de couvrir la brèche. Mais les vieux joueurs qui ont le réflexe “priorité à la survie” savent tous que ce genre d’opérations qui cachent le risque dans une boîte noire… dès qu’on tombe sur un marché extrême, c’est l’ensemble du dispositif qui saute.
C’est aussi pour ça que, après avoir disséqué les smart contracts sous-jacents de TermMax, je me suis particulièrement intéressé à sa dernière étape pour traiter les liquidations. Comme c’est un protocole axé sur des échéances fixes, une fois le jour venu, il faut régler le capital et les intérêts : impossible de faire semblant ou de tergiverser.
Dans le code, ils découpent le processus de liquidation en deux phases. À l’échéance, si l’emprunteur ne peut pas payer, on ouvre d’abord une fenêtre de liquidation “standard” pour que les robots d’arbitrage du marché vendent les collatéraux à bas prix afin de combler le manque. C’est assez classique, non ? Mais ce qui m’a vraiment donné l’impression que ce projet a “quelque chose en plus”, c’est : si cette fenêtre de liquidation se referme et que le trou n’est toujours pas comblé, qu’est-ce qu’on fait ?
TermMax a tout simplement scellé dans le niveau le plus bas une logique de Physical Delivery (livraison physique). Les actifs sous-jacents restant dans le pool, ainsi que les collatéraux, sont distribués directement selon les parts FT détenues par chaque prêteur. En clair : toi, tu attendais tranquillement de récupérer des stablecoins… et au final, ce qui peut finir entre tes mains, c’est une pile de tokens collatéraux déposés à l’époque.
Ça sonne un peu cruel, non ? Mais pour moi, c’est exactement ce type d’architecture qui écrit les mauvaises nouvelles en tout début de contrat — c’est ça, la vraie infrastructure financière au niveau des fondations. Trop de protocoles aiment traiter les créances douteuses avec une gestion floue : personne ne sait vraiment le volume de risque qui flotte au-dessus de sa tête. Tandis que chez TermMax, leurs règles ne laissent aucun espace discrétionnaire à je ne sais quel “administrateur” : l’ampleur du trou, tout le monde la prend en charge au prorata, et la comptabilité est claire et nette. Personne ne peut prétendre s’être “soustrait”.
Dans ce milieu, en bull market on te vante des taux de rendement élevés… mais ils sont tous factices : ce ne sont que des drogues d’envoûtement en temps de beau temps. Seules des règles solides, capables d’étaler sur la table toutes les cartes de liquidation de la mauvaise météo, méritent qu’on s’y attarde.
#TermMax @TermMax