Plus j’étudie @BabylonLabs_io , plus je pense que sa plus grande contradiction se cache dans le mot « Trustless ».
La documentation officielle dit : staking natif BTC, auto-custodie, sans dépendre d’un tiers pour exécuter. Mais si l’on continue à lire, la voie de pénalisation nécessite toujours que le Covenant Committee atteigne le seuil de signatures ; BTCVault doit faire entrer le BTC natif dans des opérations d’emprunt et de prêt, et le schéma le plus récent doit aussi s’intégrer à Aave v4 et Aegis.
Le risque de garde a bien diminué d’une couche, mais il ne disparaît pas : il change simplement de forme—qui peut signer, qui peut effectuer une mise à niveau, qui fixe les règles de liquidation, et qui fournit les prix et la liquidité.
Ce qui mérite encore plus d’attention, c’est que le prêt à taux fixe annoncé en juin est toujours au stade du plan : l’objectif est un lancement au quatrième trimestre 2026, après le développement et les tests. Le framework SCRIPT publié par Babylon lui-même liste aussi, comme risques centraux, l’audit, la cession des collatéraux, la couverture des règles, la ré-caution et les créances irrécouvrables.$BTC
Cela montre que l’officiel sait où se situe le problème, mais dans la diffusion vers le marché, les trois mots « se passer de confiance » sont présentés bien trop facilement.
Ce que j’aimerais vraiment voir, c’est une carte publique des permissions : ce que le comité peut faire, à qui appartiennent les clés de mise à niveau, que se passe-t-il si Aave ou Aegis tombe en panne, qui couvre les anomalies d’un oracle, et en cas de créances irrécouvrables, quel rang occupent les détenteurs de BTC.$NVDAB
Babylon a déjà prouvé qu’il pouvait faire entrer une grande quantité de BTC dans le protocole ; l’étape suivante, c’est de prouver, dans des situations extrêmes, à qui ces BTC sont réellement soumis.
Tant que cette question n’est pas expliquée clairement, Trustless ressemble davantage à un slogan de marque, et il est difficile d’en déduire une limite de sécurité vérifiable par les utilisateurs.
#baby $BABY @BabylonLabs_io
La documentation officielle dit : staking natif BTC, auto-custodie, sans dépendre d’un tiers pour exécuter. Mais si l’on continue à lire, la voie de pénalisation nécessite toujours que le Covenant Committee atteigne le seuil de signatures ; BTCVault doit faire entrer le BTC natif dans des opérations d’emprunt et de prêt, et le schéma le plus récent doit aussi s’intégrer à Aave v4 et Aegis.
Le risque de garde a bien diminué d’une couche, mais il ne disparaît pas : il change simplement de forme—qui peut signer, qui peut effectuer une mise à niveau, qui fixe les règles de liquidation, et qui fournit les prix et la liquidité.
Ce qui mérite encore plus d’attention, c’est que le prêt à taux fixe annoncé en juin est toujours au stade du plan : l’objectif est un lancement au quatrième trimestre 2026, après le développement et les tests. Le framework SCRIPT publié par Babylon lui-même liste aussi, comme risques centraux, l’audit, la cession des collatéraux, la couverture des règles, la ré-caution et les créances irrécouvrables.$BTC
Cela montre que l’officiel sait où se situe le problème, mais dans la diffusion vers le marché, les trois mots « se passer de confiance » sont présentés bien trop facilement.
Ce que j’aimerais vraiment voir, c’est une carte publique des permissions : ce que le comité peut faire, à qui appartiennent les clés de mise à niveau, que se passe-t-il si Aave ou Aegis tombe en panne, qui couvre les anomalies d’un oracle, et en cas de créances irrécouvrables, quel rang occupent les détenteurs de BTC.$NVDAB
Babylon a déjà prouvé qu’il pouvait faire entrer une grande quantité de BTC dans le protocole ; l’étape suivante, c’est de prouver, dans des situations extrêmes, à qui ces BTC sont réellement soumis.
Tant que cette question n’est pas expliquée clairement, Trustless ressemble davantage à un slogan de marque, et il est difficile d’en déduire une limite de sécurité vérifiable par les utilisateurs.
#baby $BABY @BabylonLabs_io