MICHAEL MOORE

D’accord, celui-ci m’a carrément stoppé pendant que je faisais défiler. Le testnet de DuskEVM a été mis en ligne le 10 août, selon l’annonce officielle. Solidity et Hardhat sont pris en charge, les frais de gaz sont payés en DUSK, et le règlement est renvoyé vers DuskDS.

Je suis retourné lire des publications plus anciennes pour voir comment s’empile la partie confidentialité. Hedger, le moteur derrière l’argumentaire de Dusk pour ses smart contracts confidentiels, a ouvert des tests alpha le 6 novembre 2025. Ces tests tournaient sur Sepolia, un réseau de test Ethereum distinct, et non sur la propre chaîne de Dusk.

Je ne pense pas que cet écart soit un problème en soi. Construire la couche d’exécution et la couche de confidentialité sur des pistes séparées est une approche normale pour tester une cryptographie complexe avant de la fusionner dans un environnement en production.

Ce que j’ai remarqué est différent : l’annonce du 10 août concerne entièrement des outils EVM génériques. Elle ne mentionne pas Hedger, et je n’ai pas trouvé de source officielle confirmant quand, ou si, les deux se rejoignent sur le même testnet.

Voici mon estimation. Si le testnet de DuskEVM est en ligne depuis trois jours et que la chronologie publique du moteur de confidentialité n’a pas bougé depuis le mois de novembre dernier, cela représente environ neuf mois pendant lesquels les deux éléments phares d’une blockchain de confidentialité pour des applications financières n’ont pas été montrés en train de fonctionner sur les mêmes rails.

La compatibilité EVM, à elle seule, aide déjà les développeurs. Solidity et Hardhat abaissent la barrière pour quiconque vient d’Ethereum, et c’est une vraie avancée, quel que soit ce qui se passe ensuite avec Hedger.

Je reviendrai vérifier la prochaine mise à jour qui comblera cet écart.

@Dusk #dusk $DUSK

Honnêtement, je me suis arrêté sur un chiffre de 93 $ glissé dans le livre blanc de Babylon.

Ce montant correspond au coût on-chain du parcours de contestation dans TBV, les frais payés lorsque quelqu’un conteste effectivement une revendication sur du Bitcoin verrouillé. D’après le livre blanc, cette transaction a été testée directement sur le réseau principal de Bitcoin.

Ce qui m’a vraiment accroché, c’est ce que le document dit juste après ce chiffre. Il indique que ces frais sont presque jamais payés dans la pratique, parce qu’un système fonctionnant correctement ne devrait jamais avoir de contestations.

Cette phrase m’a stoppé. La plupart des projets listent leurs coûts et passent à autre chose. Celui-ci indique un coût, puis soutient discrètement que ce coût devrait rester théorique si tout fonctionne comme prévu.

En fonctionnement normal, la preuve reste hors chaîne pendant toute la durée. Le chemin à 93 $ ne s’active que lorsqu’une revendication est réellement contestée, et selon le même document, une contestation n’a lieu que si cette revendication n’était pas légitime à la base.

C’est un type de confiance très particulier à consigner par écrit. La plupart des documents techniques décrivent des coûts en scénario catastrophe, sans préciser que ce pire cas doit être rare par conception.

Le livre blanc est clair sur ce que coûtent ces frais. Il ne dit toutefois rien sur la fréquence à laquelle le monde réel a effectivement testé une revendication qui devrait, presque jamais, donner lieu à paiement.

@BabylonLabs_io #baby $BABY

Honnêtement, je me suis arrêté sur un chiffre de 93 $ glissé dans le livre blanc de Babylon.

Ce montant correspond au coût on-chain du parcours de contestation dans TBV, les frais payés lorsque quelqu’un conteste effectivement une revendication sur du Bitcoin verrouillé. D’après le livre blanc, cette transaction a été testée directement sur le réseau principal de Bitcoin.

Ce qui m’a vraiment accroché, c’est ce que le document dit juste après ce chiffre. Il indique que ces frais sont presque jamais payés dans la pratique, parce qu’un système fonctionnant correctement ne devrait jamais avoir de contestations.

Cette phrase m’a stoppé. La plupart des projets listent leurs coûts et passent à autre chose. Celui-ci indique un coût, puis soutient discrètement que ce coût devrait rester théorique si tout fonctionne comme prévu.

En fonctionnement normal, la preuve reste hors chaîne pendant toute la durée. Le chemin à 93 $ ne s’active que lorsqu’une revendication est réellement contestée, et selon le même document, une contestation n’a lieu que si cette revendication n’était pas légitime à la base.

C’est un type de confiance très particulier à consigner par écrit. La plupart des documents techniques décrivent des coûts en scénario catastrophe, sans préciser que ce pire cas doit être rare par conception.

Le livre blanc est clair sur ce que coûtent ces frais. Il ne dit toutefois rien sur la fréquence à laquelle le monde réel a effectivement testé une revendication qui devrait, presque jamais, donner lieu à paiement.

@BabylonLabs_io #baby $BABY

Franchement, je me suis arrêté sur un exemple dans le livre blanc de Babylon, trop propre pour être la vraie solution.

Un emprunteur immobilise du BTC pour emprunter à un prêteur sur Ethereum. D’après le livre blanc, les deux parties pré-signent un ensemble de transactions Bitcoin à l’avance, en définissant exactement à quel moment chaque partie peut réclamer les fonds.

Je m’attendais à ce que le document s’arrête là et déclare que c’est réglé. Il n’en est rien. La ligne suivante indique que cette approche de pré-signature ne fonctionne que pour un seul événement déclencheur spécifique, et ne peut pas être généralisée à des conditions DeFi arbitraires.

Ce seul détail m’a interpellé. Un mécanisme conçu pour prouver l’absence de confiance indique immédiatement, dans ses propres mots, qu’il ne couvre qu’une seule sorte d’événement et qu’il ne peut pas être étendu pour gérer des conditions arbitraires.

C’est pourquoi BitVM3 existe tout simplement dans le design. D’après le même document, il généralise cette idée pour fonctionner contre toute preuve d’état hors chaîne, et pas uniquement contre un déclencheur codé en dur, tout en supprimant le besoin pour un contrepartiste de rester en ligne.

J’ai réfléchi pendant un moment à l’ordre de cette explication. La plupart des versions de TBV mènent directement au mécanisme final. Le livre blanc présente la version simple, montre où elle atteint ses limites, puis introduit le vrai correctif.

La plupart des résumés passent directement à BitVM3. Presque aucun ne mentionne ce qu’il a fallu laisser de côté d’abord. Cet ordre me paraît encore être la partie la plus honnête du design.

@BabylonLabs_io #baby $BABY

Honnêtement, je me suis arrêté sur un nom qui m’a complètement induit en erreur au début.

vaultBTC. J’ai supposé que cela fonctionnait comme tous les jetons Bitcoin enveloppés que j’ai déjà vus : un actif que l’on récupère, déplace, échange sur un marché secondaire. D’après le dépôt officiel de Babylon sur le forum de gouvernance d’Aave, cette hypothèse est fausse.

Aave ne reconnaît que les tokens ERC-20 comme collatéral. Le Bitcoin natif verrouillé dans un Taproot UTXO n’est tout simplement pas un token ERC-20 ; Babylon avait donc besoin d’une solution de contournement. Leur réponse a été une représentation un pour un sur Ethereum appelée vaultBTC, frappée uniquement pour que le protocole de prêt puisse confirmer qu’un vault précis existe.

Voici ce qui a modifié ma lecture de l’ensemble du design. Ce jeton ne peut circuler qu’entre trois points fixes définis dans l’intégration elle-même, rien au-delà. J’ai vérifié en quoi cela diffère des actifs wrapped typiques, et l’écart est total : pas de marché ouvert, pas de mouvement non restreint, pas de trading secondaire nulle part.

J’ai réfléchi à cette différence pendant un moment. Un jeton enveloppé normal tire sa valeur de son utilité en circulant entre des portefeuilles et des plateformes, sans restrictions. Babylon a délibérément bloqué ce chemin ici, en choisissant un design plus difficile précisément pour que le jeton ne puisse jamais devenir une alternative négociable à la “vraie” chose.

C’est cette contrainte qui impose en réalité la self-custody à un niveau mécanique, pas seulement comme une promesse dans un document. Il aurait été bien plus simple de laisser vaultBTC se comporter comme n’importe quel autre actif.

Je n’ai toujours vu personne se demander ce qui se passe pour la composabilité une fois qu’un token est verrouillé aussi étroitement. Cela ressemble à la prochaine vraie question.

@BabylonLabs_io #baby $BABY

Honnêtement, je me suis arrêté à un chiffre qui paraît encore presque irréel.

Neuf mille satoshis.

En octobre 2025, deux mois après la publication du livre blanc des Trustless Bitcoin Vaults, David Tse a publié le premier véritable test depuis son propre compte. Pas un testnet. Pas une simulation. Une transaction Bitcoin en direct et une transaction Ethereum correspondante, toutes deux visibles dans des explorateurs publics pour que chacun puisse vérifier.

Neuf mille satoshis verrouillés dans un coffre. Exactement un USDC emprunté sur Morpho. Du Bitcoin natif qui n’est jamais sorti de la chaîne Bitcoin, qui n’a jamais été wrapped, qui n’est jamais passé par un dépositaire.

Je suis allé vérifier moi-même les deux liens de transaction. Ce petit montant a été la première fois que du BTC natif devenait utilisable comme garantie de prêt sur Ethereum, sans les compromis habituels de confiance.

Ce qui revient sans cesse à moi, c’est la distance entre ce moment-là et l’endroit où TBV se trouve aujourd’hui. Le même mécanisme fonctionne actuellement sur le testnet public Aave V4 et se trouve derrière une intégration GoMining planifiée qui évoque jusqu’à mille BTC.

Ce premier essai était délibérément minuscule. Le travail actuel vise clairement quelque chose de beaucoup plus grand. La question de savoir si les hypothèses de confiance initiales tiennent quand la taille passe d’un dollar à une échelle significative, c’est encore la partie que je n’ai pas vue suffisamment mise à l’épreuve en public.

@BabylonLabs_io #baby $BABY

Je regardais l’historique de la gouvernance propre à Babylon, et un détail a changé la façon dont je lis désormais chaque date de déblocage.

En septembre 2025, le forum de la Fondation Babylon a porté une proposition visant à réduire l’inflation BABY de 8 % à 5,5 %, en répartissant les récompenses vers une nouvelle conception de co-staking BTC-BABY. Depuis, cette proposition a été adoptée. Ce qui m’a marqué, c’est la phrase que l’équipe y a jointe publiquement : elle était présentée comme la première de plusieurs ajustements de tokenomics prévus spécifiquement parce que Trustless Bitcoin Vaults était en préparation.

Cette formulation m’a poussé à chercher comment TBV est censé réinjecter vers $BABY . Selon la feuille de route « Vault First » de Babylon, les revenus générés via les intégrations DeFi, les charges d’intérêt et les primes de liquidation doivent permettre d’acheter et de brûler BABY de manière programmatique.

Le livre blanc de TBV le décrit directement : lors de cette vente aux enchères, l’enchérisseur gagnant reçoit du BTC, et le BABY dépensé est brûlé, sans étape discrétionnaire supplémentaire côté trésorerie.

Dans le récapitulatif de l’appel des fondateurs de Babylon, l’équipe a insisté sur le fait que la création de valeur passe d’abord, avec des tokenomics conçues pour capter un usage réel plutôt que de le fabriquer.

C’est cette phrase avec laquelle je continue de rester.

D’après les documents propres à Babylon, le pool combiné « Team, Advisor et Early Investor » totalise 4,9 milliards de BABY, libérés en tranches mensuelles égales depuis le 10 mai 2026. En divisant sur 36 mois, la prochaine tranche, due le 10 août 2026, s’élève à environ 136,11 millions $BABY , en respectant le calendrier quoi qu’il arrive.

Le mécanisme de burn dépend du volume réel des transactions TBV, qui se forme encore sur testnet. Le déblocage n’attend pas que ce chiffre existe.

Quelle horloge rattrape l’autre en premier ?

#baby @BabylonLabs_io #baby

PAS DE DÉPOSITAIRE. PAS DE COMITÉ. JUSTE VOUS.

Hé, je cherchais le groupe externe qui surveille la fenêtre de défi de la TBV pour les allégations frauduleuses. Il n’y en a pas.

Le Temp Check officiel de Babylon, soumis au forum de gouvernance d’Aave le 25 mai 2026, décrit ce qui se passe lorsqu’une personne tente de racheter un coffre TBV avec une preuve invalide. Cette allégation peut être contestée pendant une période définie. Ce qui m’a particulièrement frappé, c’est qui a le droit de soulever ce défi.

Le déposant lui-même peut toujours agir en tant que challenger. Pas une option de secours. Pas un plan B si un groupe désigné ne se présente pas. C’est le paramètre par défaut, intégré dès le départ à la conception.

La plupart des systèmes qui connectent Bitcoin à la DeFi s’appuient sur une autorité déléguée pour ce travail précis : une fédération, un multisig, ou un ensemble de signataires disposant d’un pouvoir discrétionnaire. D’après le même document, rien de tout cela n’existe ici. Aucun dépositaire ne détient une clé. Aucun comité n’a de vote sur le BTC.

Cette absence relie directement à ce que signifie réellement la self-custody dans ce contexte. Détenir ses propres clés en est une moitié. Défendre personnellement sa propre réclamation, sans dépendre de l’honnêteté ou de la disponibilité de qui que ce soit, en est l’autre moitié, que la plupart des explications omettent entièrement.

Je continue cependant à observer le côté pratique. Agir en tant que votre propre challenger implique que quelqu’un doit réellement surveiller la fenêtre pendant qu’une réclamation est traitée. Qu’il faille un logiciel dédié ou que cela fonctionne via quelque chose de plus simple n’a pas été détaillé publiquement.

La vraie conséquence est simple. Toute personne qui dépose dans TBV et ne vérifie jamais son propre coffre choisit discrètement de revenir à la même dépendance que cette conception a précisément été conçue pour supprimer.

$BABY #baby @BabylonLabs_io

Écoutez, j’ai remarqué quelque chose dans l’annonce du Ledger de Babylon du 10 mars 2026 que la plupart des analyses ont complètement manqué.

Tous les titres que j’ai vus se concentraient sur le chiffre de 8 millions d’appareils. Je me suis demandé à quoi servent réellement ces appareils au moment où un coffre-fort est configuré.

Quand quelqu’un crée un TBV, les règles se verrouillent définitivement : l’adresse du demandeur, le protocole cible, les conditions de libération. Je ne peux pas revenir en arrière et modifier l’une de ces valeurs après la création. C’est l’engagement.

Sans le Clear Signing de Ledger, je définirais ces paramètres via un navigateur et je ferais confiance à l’interface pour m’afficher ce à quoi j’accepte. Avec lui, tout ce que j’approuve apparaît sur l’écran de mon appareil dans un langage clair avant que je signe. La vérification et le verrouillage permanent constituent la même action.

La promesse de self-custody dans le TBV, c’est que mon BTC ne quitte jamais mon contrôle. Le Clear Signing étend cette logique à la configuration elle-même. Je peux lire exactement ce à quoi je m’engage, sur un appareil que je possède, avant que cela ne devienne permanent.

Le billet de blog du 10 mars de Babylon a présenté le déploiement H2 2026 pour cette intégration. Cette fenêtre est désormais ouverte.

Ce que je n’ai pas trouvé publiquement, c’est de savoir si le Clear Signing couvre la création complète du coffre-fort ou seulement les actions après la configuration. Ce détail du périmètre n’a toujours pas été abordé.

$BABY @BabylonLabs_io #baby

Je regardais la structure réelle du script @BabylonLabs_io utilisé sur Bitcoin, et un choix délibéré à l’intérieur ne figure dans aucune annonce.

Ce choix repose à la base de la manière dont une transaction de staking est construite. Babylon désactive totalement la manière par défaut de dépenser une sortie Taproot, en la remplaçant par une constante mathématique précise qui n’a pas de clé privée. Personne ne la détient. Même pas l’équipe qui l’a créée.

Cela signifie que le BTC verrouillé dans l’une de ces positions ne peut sortir que selon trois conditions écrites directement dans le script. Il n’existe aucune autre sortie.

La première libère les fonds une fois la période de bloc engagée terminée, et ne nécessite que la signature du staker lui-même. La deuxième permet un désengagement anticipé, mais uniquement avec cette même clé, plus un seuil de comité de covenant. La troisième est le slashing, et elle se comporte différemment des deux autres.

Je revenais sans cesse à cette troisième condition. D’après la spécification propre à Babylon, un fournisseur de finalité doit coopérer pour l’empêcher de se produire, mais sa coopération n’est pas nécessaire pour la déclencher. S’ils double-signent, leur clé se révèle automatiquement et la transaction pré-signée s’exécute toute seule.

Ils n’ont aucun moyen de l’arrêter.
Ce qui m’a frappé, c’est que rien de tout cela ne demandait d’inventer quoi que ce soit de nouveau. Babylon a utilisé Taproot exactement comme les développeurs de Bitcoin avaient prévu qu’il soit utilisé.

Ce que je continue d’observer, c’est l’évolution de la couche de comité de covenant. Leur propre documentation évoque le fait de passer à une structure plus avancée une fois que des fonctionnalités natives deviendront disponibles directement sur Bitcoin.

#baby $BABY

J’ai repéré une ligne dans l’article de blog du 25 juin 2026 de Babylon qui a changé ma façon de voir tout le projet.

Elle était enfouie dans l’annonce du partenariat Aegis. Vers la fin : « Beyond the initial product, this integration also shows how applications can build using TBV and Aave v4. »

Cette phrase remet les choses en perspective. TBV plus Aave V4 n’est pas un seul canal de prêt. C’est une couche ouverte sur laquelle d’autres protocoles DeFi peuvent construire directement.

La plupart des échanges restent centrés sur la fonctionnalité d’emprunt d’Aave. Ce que j’ai trouvé plus intéressant, c’est que l’architecture a été conçue pour être réutilisable, et non liée dès le départ à un résultat unique.

Le schéma est déjà visible. Aegis construit un crédit à taux fixe sur cette même pile, le 25 juin 2026. GoMining a structuré un produit de rendement minier en utilisant la même infrastructure, le 5 mai 2026.

Deux résultats complètement différents. À sept semaines d’intervalle.

Je suis retourné vérifier que « first » était intentionnel. Le propre post X de Babylon, au moment où Aave V4 a été lancé, disait : « The first TBV use case is native Bitcoin borrowing on Aave v4. » C’était délibéré.

La feuille de route « Vault First » d’octobre 2025 indiquait où cela mène finalement : lending, stablecoins, PERP DEX. La cadence du début laisse penser que cette liste n’est pas hypothétique.

Ce que je continue d’observer, c’est de savoir si cette couche restera réservée à Ethereum. Les documents officiels indiquent que le protocole de vault fonctionne pour n’importe quelle blockchain. À combien de chaînes l’intégration s’étend réellement, c’est encore une question ouverte.

$BABY #baby @BabylonLabs_io