Salut les gars, bonne soirée. À la fin de l'année dernière, j'ai uploadé une donnée concernant "les trois signaux d'alerte avant le décrochage des stablecoins". À l'époque, je pensais que c'était plutôt utile, donc je l'ai partagé, et je ne m'attendais pas à ce que ça devienne le meilleur échantillon pour observer ce système. Aujourd'hui, je vais dérouler la courbe de rendement de cette donnée sur les six derniers mois, avec des hausses, des baisses et des retournements, c'est encore plus réel que de regarder des velas.

Cette donnée fait un peu moins de quatre cents mots. Le premier signal est "la profondeur du Curve 3pool qui tombe en dessous d'un certain seuil", le deuxième est "le taux d'intérêt des stablecoins prêtés d'un certain protocole de prêt qui s'envole", et le troisième est "le volume de stablecoins sortant d'un pont inter-chaînes qui est anormal". Chacun a un seuil numérique spécifique. Au début, les deux premiers mois, les rendements étaient moyens, environ cinq ou six $OPEN par mois. C'est vraiment décollé au troisième mois, quand le marché a connu une petite panique de décrochage, ma donnée a été massivement appelée par divers bots de gestion des risques, atteignant plus de trente en un mois.

Mais à partir du quatrième mois, le rendement s’est mis à baisser. Au quatrième mois, c’était un peu plus de vingt ; au cinquième, douze ; et au sixième mois, c’est-à-dire le mois dernier, il n’en restait plus que sept. J’ai relu les historiques d’appels, et j’ai constaté deux raisons. Premièrement, certains seuils dans mes signaux d’alerte sont devenus obsolètes : par exemple, sur Curve, le niveau de référence de la profondeur du pool a changé ; l’ancien « inférieur à 100 millions de dollars » n’est plus dangereux et c’est désormais « inférieur à 200 millions ». Deuxièmement, plusieurs concurrents ont uploadé des données d’alerte similaires ; certaines sont plus détaillées que les miennes, et les poids d’attribution ont été répartis, ce qui m’a redirigé une partie des appels.

Ce processus de décroissance m’a fait comprendre à fond une règle implicite de la preuve d’attribution d’OpenLedger. Les données ne sont pas une ressource acquise une fois pour toutes : comme un bien physique, elles vieillissent et perdent de la valeur. Même si l’année dernière tu écrivais la meilleure chose du monde, si le marché change cette année, il faut s’adapter. Ceux qui fournissent des données et continuent d’encaisser des dizaines de revenus chaque mois, je suppose qu’ils assurent un entretien et des mises à jour continus en coulisses. Les paresseux ne survivent pas dans ce système.

Alors, j’ai fait deux choses. La première : récupérer cette vieille base de données et la refaire, en mettant à jour les seuils numériques des trois signaux d’alerte avec les derniers critères statistiques de cette année. La seconde : j’ai affiné un petit modèle avec ModelFactory, spécialisé dans la question : « Y a-t-il un risque de perte d’ancrage (depeg) sur le marché actuellement ? ». Les données d’entraînement, ce sont plus d’une cinquantaine de scénarios questions-réponses générés à partir de mes trois signaux. Déployé depuis deux semaines, le volume d’appels est déjà à 70 % du pic de l’ancienne base. Et surtout, le modèle a l’avantage de pouvoir recevoir des données temps réel fournies par l’utilisateur pour faire des jugements, ce qui le rend plus flexible que des entrées statiques.

Je l’ai aussi essayé pour le module RLHF écrit dans le livre blanc. Le modèle affiné au départ jugeait trop prudemment : il classait tout bruit normal comme un risque. Je lui ai alors donné manuellement un retour à une vingtaine de reprises : « ce n’est pas un dépeg ». Petit à petit, le modèle s’est calibré. Après calibration, le volume d’appels a nettement augmenté : les utilisateurs ont l’impression qu’il ne fait plus de réactions excessives. En gros, ce mécanisme de feedback consiste à corriger la machine avec le jugement humain : c’est bien plus efficace que d’empiler des paramètres.

Le risque, il faut le mettre clairement sur la table. À l’heure actuelle, il n’y a pas encore beaucoup de données dynamiques de haute qualité sur OpenLedger : la plupart sont des entrées statiques. Cela veut dire que ceux qui entrent en premier profitent d’une prime, mais la fenêtre de cette prime se rétrécit à mesure que la concurrence s’intensifie. L’explosion de ma donnée au troisième mois contenait en réalité une part de chance : elle tombait justement au moment où le marché paniquait. Si tu comptes sur une explosion chaque mois, tu risques d’être déçu. Ma stratégie consiste à maintenir simultanément sept ou huit jeux de données dans des directions différentes afin de diversifier le risque. Quand une devient obsolète, les autres peuvent prendre le relais.

Pour le moment, ma position reste autour de 3 % du capital total. Je n’ai pas augmenté mes avoirs de manière impulsive à cause de l’explosion de cette donnée. Parce que je sais que la décroissance est inévitable ; l’essentiel, c’est de regarder si le volume total d’appels de toute la plateforme est en hausse. Au cours des six derniers mois, le nombre d’appels quotidiens on-chain sur OpenLedger est passé de quelques centaines à plus de deux mille. Cette tendance est plus importante que les hausses ou baisses de ma donnée prise isolément.

Le récit selon lequel le Bitcoin a mis dix ans à convaincre tout le monde qu’il s’agit de « l’or numérique » ; Ethereum, lui, a mis cinq ou six ans pour faire entrer les smart contracts dans le courant principal. Quant au modèle d’OpenLedger, qui consiste à répartir les données directement on-chain, la possibilité de le faire tourner dépend de ce qui se passe dans les deux prochaines années. Mon choix, c’est de mettre un peu d’argent de côté et de m’y atteler, en validant sans cesse avec mes propres données uploadées pour vérifier si ce grand livre sait vraiment faire les comptes. Pour l’instant, le grand livre est exact ; la décroissance est réelle ; et les mises à jour rapportent. Ça suffit.#OpenLedger