Emaan_mx

Je suis revenu sans cesse à une phrase de leur publication d’il y a deux jours.

Tokeniser un actif, c’est la partie facile. Faire tourner le marché autour, en l’exécutant onchain, est le problème le plus difficile.

Ils ont énuméré les étapes qui doivent encore fonctionner : prouver l’éligibilité, appliquer les règles de transfert, protéger les positions, coordonner le règlement et le service. La plupart des projets s’arrêtent une fois que le token existe. Dusk essaie de maintenir toute la séquence sur les mêmes rails.

J’ai relu une fois de plus les notes récentes du testnet DuskEVM. Des contrats Solidity peuvent se régler via DuskDS tandis que Hedger gère les soldes et transferts confidentiels. Citadel est là pour la divulgation sélective afin qu’un investisseur puisse prouver son accréditation sans publier l’enregistrement complet onchain.

C’est cet assemblage qui m’a arrêté. Ce n’est pas une autre couche de confidentialité. C’est une tentative de conserver le contrôle de l’émetteur, les contrôles de conformité et l’exécution privée dans un seul flux, au lieu de les répartir entre des systèmes distincts.

Le lien NPEX rend la mise en perspective moins abstraite. Ils fonctionnent déjà sous des licences AFM et disposent d’un vrai volume de titres. La question ouverte est de savoir si la version onchain peut assurer les mêmes contrôles sans divulguer les données que ces contrôles sont censés protéger.

Je continue d’observer comment les pièces se connectent concrètement dès que davantage de volume est déplacé.

@Dusk #dusk $DUSK

NPEX et Dusk ont déposé une demande dans le cadre du régime pilote UE pour les DLT dès mars 2024. Cette date m’est restée en tête parce que j’avais supposé qu’il s’agissait d’un développement récent, et pas d’une demande en file d’attente depuis plus d’un an.

Je me suis renseigné pour obtenir une mise à jour et j’ai constaté que la même licence restait indiquée comme « en attente » dans les propres documents de Dusk datant de la mi-2025. Rien depuis pour confirmer qu’elle a été approuvée.

Franchement, ma première réaction a été une légère déception. Je voulais une histoire plus simple, où Dusk aurait tout simplement la licence.

Puis j’ai trouvé l’élément « 21X », et ma lecture de l’ensemble a changé. 21X, une entreprise distincte, détient déjà une licence DLT-TSS accordée, et Dusk s’est associé à elle précisément pour y accéder pendant que leur propre dépôt attend encore.

C’est un choix plus malin que ce que je lui avais d’abord attribué. Au lieu d’attendre uniquement leurs propres papiers, ils ont trouvé un raccourci fonctionnel via quelqu’un qui avait déjà franchi la même étape réglementaire.

Je ne pense pas que cela reflète mal non plus sur NPEX. De nouveaux régimes pilotes n’étaient jamais censés avancer au rythme auquel quiconque dans la crypto est habitué.

Ce qui me revient sans cesse, c’est la trajectoire qui pèsera le plus sur le long terme. Celle que Dusk a lancée, ou celle qui leur a permis d’entrer plus vite.

@Dusk #dusk $DUSK

DUSK devient transférable nativement vers Ethereum et Solana grâce à la norme de jetons inter-chaînes de Chainlink. J’ai relu ça deux fois, car ce sont deux des registres les plus transparents du secteur.
La même intégration CCIP emporte aussi les titres tokenisés de NPEX de DuskEVM vers d’autres chaînes : ce n’est donc pas seulement le jeton natif qui circule.
Voici la partie qui m’est restée en tête. La confidentialité sur Dusk provient de la couche de base elle-même : transferts protégés, preuves à connaissance nulle et divulgation sélective intégrées au protocole.
Tout cela ne suit pas l’actif une fois qu’il traverse un environnement qui n’a jamais été conçu pour la confidentialité. Une obligation tokenisée quittant Dusk pour Ethereum y est réglée selon les règles transparentes propres à Ethereum, et non celles de Dusk.
Dusk présente cela comme une extension de la portée et de la composabilité, et c’est bien le cas. Mais chaque étape vers l’interopérabilité est aussi une étape où la garantie de confidentialité devient optionnelle selon la chaîne sur laquelle l’actif se trouve ce jour-là.
Je ne pense pas que cela casse l’argumentaire conformité. Cela signifie simplement que la confidentialité pour laquelle Dusk est connu pourrait finir par être l’exception plutôt que la règle par défaut, une fois que les actifs commenceront à circuler librement.
@Dusk #dusk $DUSK

Les contrats XSC sur Dusk peuvent annuler une transaction après qu’elle a eu lieu. Cette seule ligne m’a dérangé plus que tout le reste que j’ai lu cette semaine.

À chaque blockchain dans laquelle je me suis lancé au départ, on m’a vendu une seule idée. Une transaction, une fois confirmée, était censée être définitive.

Puis j’ai réfléchi au raisonnement, et ma position a réellement changé. Les titres tokenisés ont un poids juridique réel. Les ordonnances de justice et les allégations de fraude ne se soucient pas de savoir si un actif vit sur une base de données ou sur une blockchain.

Des chambres de compensation traditionnelles comme la DTCC corrigent ou inversent les opérations en permanence. Personne n’appelle cela un scandale. Une chaîne de titres entièrement immuable serait peut-être honnêtement la version qui échoue à la check-list d’un régulateur, plutôt que la version réversible.

Pour autant, je n’arrive pas totalement à chasser l’inconfort, et le fork du DAO Ethereum est exactement la raison. C’était un pouvoir de renversement utilisé une fois, sous pression, a posteriori. Il a divisé toute une communauté sur la question de savoir si le faire était même légitime.

Dusk ne cherche pas à atteindre ce pouvoir en cas d’urgence. Il l’intègre au contrat dès le premier jour, et honnêtement, cela me semble plus honnête, même si cela met mal à l’aise.

Là où je me positionne réellement, c’est ceci. Je préférerais que le pouvoir de renversement soit déclaré dès le départ dans le code, plutôt que de découvrir qu’il existe, à la dure, pendant une crise.

@Dusk #dusk $DUSK

Je parcourais le tableau de distribution des récompenses de Dusk et la clause de “burn” m’a pris de court.
Le générateur de blocs obtient d’emblée 70 % de chaque récompense de bloc, plus jusqu’à 10 % supplémentaires liés à quelque chose appelé des crédits de certificat. Toute partie de ces 10 % supplémentaires restée non réclamée est brûlée au lieu d’être redistribuée.
La documentation ne définit jamais ce qui est considéré comme un crédit. J’ai vérifié deux fois en supposant que j’avais manqué une page liée, mais la section le mentionne simplement puis passe à autre chose.
Ce manque me dérange plus que ça ne devrait. Un burn lié à une métrique de participation non définie n’est pas la même chose que les burns déclenchés par la gouvernance ou planifiés dont la plupart des projets parlent.
Le reste du partage est simple en comparaison. Dix pour cent pour un fonds de développement, cinq pour la validation, cinq pour la ratification.
Les émissions suivent un calendrier de décroissance sur 36 ans, avec un halving toutes les quatre années, plafonné à 500 millions de nouveaux DUSK en plus des 500 millions d’offre initiale déjà émis. Face à cette courbe, tout ce qui est brûlé par bloc paraît dérisoire.
Pourtant, sur des milliers de blocs avec une complétude des certificats incohérente, cela cesse de sembler négligeable.
Rien ici ne change ma position. Cela ne fait que changer ce que je surveille désormais dans les données de récompense.
@Dusk #dusk $DUSK

Monero, Zcash, Dash. Mentionnés directement dans le manuel de conformité publié par un groupe de défense des cryptomonnaies au niveau de l’UE, les trois ont été signalés comme exclus d’ici 2027 en vertu des nouvelles règles AML.

Dusk n’est pas sur cette liste. Je me suis attardé sur cette absence plus longtemps que je ne l’avais prévu.

La réglementation elle-même, l’article 79, ne cite aucune pièce. Elle interdit les comptes qui permettent « une opacification accrue des transactions ». Cette expression est plus large que trois symboles boursiers.

Les transactions protégées de Dusk masquent les montants et les contreparties au moyen de preuves à divulgation nulle de connaissance (zero-knowledge). Les données sont toujours vérifiées, mais elles ne sont pas diffusées publiquement. Il n’a pas encore été testé, jusqu’à présent, si un régulateur qualifierait cela d’opacification ou de divulgation sélective.

Ce qui m’a le plus marqué, c’est l’accord NPEX. Une licence de courtage, une licence MTF, une licence de financement participatif, intégrées directement dans la couche protocolaire.

Ce n’est pas une posture de projet visant à passer entre les mailles des régulateurs. C’est un projet qui parie l’ensemble de son modèle sur une lecture bienveillante une fois que les règles d’application auront été rédigées.

Je suis aussi retourné vérifier l’exploit de pont de janvier. Des millions de jetons ont disparu via un portefeuille de signature compromis : rien à voir avec la couche de zero-knowledge.

Les contrats confidentiels ont tenu bon. La garde (custody) autour d’eux n’a pas.

Cela me fait penser que le risque réel n’a jamais opposé anonymat et conformité. Il s’agissait toujours de savoir quelles parties de la pile logicielle sont auditées et lesquelles sont considérées comme dignes de confiance par défaut.

Je continue quand même à lire les actes d’exécution avant de me faire un avis concret sur la façon dont l’article 79 s’applique en pratique.

@Dusk #dusk $DUSK

Un cofondateur de Babylon s’est tenu dans une salle remplie de maximalistes du Bitcoin et a admis que la demande émanant de ce public précis avoisinerait zéro.

Fisher Yu l’a dit clairement à CryptoSlate, en balayant du regard les inconditionnels du Bitcoin présents à l’un des plus grands événements annuels de leur communauté. Ni sur la défensive, ni enjolivé : simplement honnête.

Je me suis attardé sur cette confession plus longtemps que je ne l’aurais cru. La plupart des fondateurs atténuent ce genre de réponse au lieu de nommer à voix haute leur public le plus fragile.

Cela renvoie à quelque chose de réel au cœur de la culture du Bitcoin. Le maximalisme a toujours eu pour axe de conserver le BTC intact, résistant à toute couche supplémentaire ou à toute dépendance, si minime soit-elle.

Le produit complet de Babylon demande précisément aux détenteurs d’accepter l’inverse de cette intuition. Yu n’a pas non plus esquivé la question du risque : il a expliqué clairement le slashing, en précisant que votre Bitcoin reste en sécurité tant que vous n’attaquez pas vous-même le réseau et que vous ne déléguez pas à un validateur qui le ferait.

C’est un véritable arbitrage formulé en termes simples, sans être enfoui dans la documentation. La sécurité ici dépend en partie de la confiance dans le comportement de quelqu’un d’autre, pas seulement du fait de conserver sa propre clé.

Ce qui m’a le plus marqué, c’est le timing du commentaire. Cap-2 avait déjà attiré environ vingt-quatre mille BTC, soit près de deux milliards et demi de dollars : ce n’était donc pas un fondateur cherchant à écarter une demande faible.

C’était un fondateur qui précise quel segment de détenteurs de Bitcoin achetait réellement, et lequel, d’après son propre aveu, achetait surtout… pas. Je ne pense pas que cela rende le produit inadapté aux utilisateurs actuels ; je pense seulement que cela dit quelque chose de vrai sur le public pour lequel il a été conçu.

@BabylonLabs_io #baby $BABY

Cent trente-cinq mille personnes ont verrouillé du Bitcoin réel dans Babylon avant même que le protocole n’ait un jeton. Mettre de l’argent réel en jeu pour quelque chose appelé des points.

Pour être honnête, ma première réaction a été le scepticisme. Verrouiller du Bitcoin pour une récompense non définie ressemblait davantage à du jeu qu’à un investissement.

Au 25 novembre 2024, juste avant l’ouverture de Cap-3, il n’y avait toujours pas de token BABY, ni d’actif confirmé qui le garantisse. Cap-2 à lui seul avait déjà attiré 23 857 BTC, soit près de deux milliards de dollars, remplis en seulement quelques heures.

À mon avis, cette rapidité en dit plus long que le chiffre en dollars. Les gens ne délibéraient pas lentement : ils ont agi vite sur la base d’une promesse sans étiquette de prix pour l’instant.

J’ai essayé de déterminer si c’était réellement imprudent avant de juger trop vite. EigenLayer a fait exactement la même chose un an plus tôt : elle a attiré plus de seize milliards de dollars en dépôts ETH via un système de points, avant même que EIGEN ne soit lancé.

Donc je ne pense pas que ce soit de la foi aveugle. Je pense que c’était un pari calculé, fondé sur la réputation de l’équipe et sur ce que des protocoles similaires avaient déjà livré.

Mais honnêtement, EigenLayer est aussi la partie de cette histoire qui m’empêche de me sentir pleinement convaincu. EIGEN a chuté de 91 % d’ici décembre 2025, et l’airdrop du propre token a suscité de vraies réactions en raison de la façon dont les points ont fini par être pondérés.

C’est cette pièce qui me reste en tête. Le même scénario a permis de récolter une fois seize milliards de dollars, et pourtant cela n’a pas empêché les gens de subir un résultat plutôt rude ensuite.

Je ne sais pas à quelle version de cette histoire les 57 290 BTC de Babylon finiront par ressembler davantage. Je sais juste qu’une conviction réelle et un bon résultat ne sont pas la même chose, même quand ils commencent par se ressembler.

@BabylonLabs_io #baby $BABY

Deux protocoles que je considérais comme des concurrents étaient en réalité co-auteurs sur le même article. Ça m’a arrêté net en plein défilement aujourd’hui.

Les origines de Babylon remontent à un article de sécurité rédigé par David Tse, Fisher Yu et Sreeram Kannan, avec quelques autres chercheurs. Kannan a ensuite fondé EigenLayer.

J’ai dû prendre une seconde pour assimiler. Les deux plus grands noms du restaking à l’heure actuelle n’ont pas commencé comme des rivaux ; ils ont commencé comme des collaborateurs autour de la même idée.

Ce qui m’a encore plus surpris, c’est que le lien n’a jamais vraiment cessé. Kannan siège encore aujourd’hui au conseil consultatif de Babylon, tout en dirigeant le protocole que la plupart des gens considèrent comme le concurrent direct de Babylon.

À mon avis, cela change complètement la lecture de la rivalité. Ce n’est pas deux camps opposés qui se disputent les mêmes utilisateurs ; on dirait plutôt une seule et même intuition partagée qui s’est divisée en deux implémentations, en restant faiblement connectée tout au long du parcours.

J’ai vérifié la structure de direction après ça, surtout par curiosité. Babylon n’a pas de PDG : Tse est chercheur scientifique, Yu est directeur technique (CTO), et c’est toute la structure au sommet.

Tse l’a dit clairement dans une interview : les articles de recherche ne touchent qu’une poignée de personnes, et une startup était sa manière de transformer cette idée en quelque chose d’utilisable par plus que quelques universitaires.

Je ne pense pas que des origines communes rendent la rivalité technique moins réelle. Je pense simplement qu’il vaut la peine de se rappeler qu’avant d’être une compétition, c’était une conversation entre des personnes qui ont vu le même manque au même moment, et qui apparemment continuent encore à parler.

@BabylonLabs_io #baby $BABY

Ten Bitcoin Secured Networks a rejoint Babylon dans une seule annonce, et je vais être honnête : ma première réaction a été du scepticisme, pas de l’enthousiasme.

Sui a porté 1,23 milliard de dollars de TVL au moment où le rapport Q1 2025 de Messari est sorti. Corn, un réseau conçu spécifiquement autour du Bitcoin DeFi, a porté 1,3 million.

Je ne pense pas que cet écart doive rester tranquillement dans le même titre. Regrouper ces deux éléments sous une seule étiquette BSN fait que l’annonce paraît plus uniforme qu’elle ne l’était en réalité.

Osmosis m’a le plus dérangé parmi tous. Présenté comme le DEX phare et le lieu de trading de premier plan pour les actifs de Babylon, son volume de trading historique à ce moment-là était pourtant juste au-dessus de 38 millions de dollars.

Cette mise en récit donnait l’impression d’avoir été écrite pour le titre, et non pour quelqu’un qui irait réellement vérifier le chiffre.

J’ai examiné le trimestre suivant en espérant voir la tendance se corriger. Au lieu de cela, le propre TVL de staking en bitcoin de Babylon a chuté de 12,6 % d’un trimestre sur l’autre d’ici le T2 2025, pour atteindre 45 600 BTC.

À mon avis, cette baisse compte davantage que le moindre nombre de partenaires. Une base qui se rétrécit pendant que davantage de noms sont ajoutés n’est pas une contradiction : c’est un schéma qui mérite d’être observé de près plutôt que d’être célébré.

Je n’essaie pas de soutenir que le projet échoue, car ce n’est clairement pas le cas. Je pense simplement que le titre « dix BSN » aplatit une image beaucoup plus confuse en dessous, et je préférerais regarder la version plus chaotique avant de décider ce que j’en pense réellement.

@BabylonLabs_io #baby $BABY

Babylon ne détecte pas la fraude des validateurs. Leur propre signature s’en charge à la place.

Le mécanisme s’appelle des Signatures Traçables et À Usage Unique (Extractable One-Time Signatures). Si un Fournisseur de Finalité signe deux blocs contradictoires à la même hauteur, les mathématiques elles-mêmes exposent sa clé privée au réseau.

J’ai relu ça deux fois, car la plupart des conceptions de slashing fonctionnent différemment. Il faut d’abord qu’un système détecte le mauvais comportement, puis qu’un processus distinct le punisse après coup.

Ici, la fraude et la preuve arrivent au même moment. Une fois la clé exposée, le protocole peut déclencher le slashing directement, sans oracle, sans rapport hors chaîne, et sans comité qui décide ce qui constitue une preuve.

J’ai supposé que la pénalité ne touchait que le fournisseur jusqu’à ce que je lise la suite. Tout le Bitcoin délégué à ce fournisseur devient également sujet au slashing, pas seulement ce que le fournisseur a misé lui-même.

Cela change totalement le niveau de risque. Un Fournisseur de Finalité a souvent peu de capital à lui-même en jeu : l’exposition réelle repose donc sur celui qui a choisi de lui déléguer.

Il y a aussi une deuxième conséquence que j’avais manquée. Un fournisseur pris en flagrant délit de double signature est « tombstoné », définitivement empêché de regagner le pouvoir de vote, et pas seulement sanctionné une fois avec une amende, puis autorisé à continuer.

J’ai comparé cela à l’approche d’EigenLayer par habitude. Ce système s’appuie sur la logique des smart contracts Ethereum, tandis que celui-ci se situe plus près du schéma de signature lui-même, directement lié à Bitcoin.

Je pense néanmoins que la réserve en faveur du comportement honnête est ce qui compte le plus ici. Une cryptographie élégante n’élimine pas le risque de concentration : elle modifie simplement qui paie effectivement pour l’erreur de quelqu’un d’autre si la délégation n’est pas répartie avec soin.

@BabylonLabs_io #baby $BABY

Le pitch entier n’a pas enveloppé le Bitcoin. Puis j’ai lu le document sur la liquidation dans la proposition d’Aave de Babylon lui-même, et j’ai trouvé WBTC au beau milieu.

Les coffres Bitcoin sans confiance de Babylon verrouillent le BTC dans un UTXO Taproot sur Bitcoin lui-même, sans ponts, sans dépositaires. Sur ce point, le pitch tient bien.

Les liquidations sont des événements courants dans n’importe quel marché de prêt, pas des urgences, et la vitesse de règlement de Bitcoin ne peut pas suivre le rythme des opérations habituelles. Ainsi, les liquidateurs sans autorisation échangent la voûte saisie contre du WBTC avec une petite prime afin de régler la dette immédiatement.

Un groupe distinct d’arbitragistes autorisés rembourse ensuite le véritable Bitcoin, selon le calendrier propre à Bitcoin. Deux actifs, deux vitesses, qui fonctionnent en séquence plutôt qu’en opposition.

J’ai vérifié pourquoi ils l’ont conçu de cette façon au lieu d’éviter totalement le WBTC. La proposition le dit clairement : il s’agit de stimuler la demande d’emprunt pour les cinq milliards de dollars en WBTC déjà fournis à Aave, mais sous-utilisés du côté des emprunts.

Je voulais voir si quelqu’un, au sein d’Aave, avait fait pression en sens inverse sur cette dépendance avant de me faire mon propre avis. Un prestataire de services techniques chez Aave Labs a déclaré que la conception est cohérente avec l’architecture V4 Hub and Spoke, et le propre fondateur d’Aave a publiquement soutenu la proposition sans signaler l’étape de WBTC comme un sujet de préoccupation.

Cela m’a appris quelque chose. Les personnes plus proches des mécanismes que je ne le suis interprètent cela comme un arbitrage raisonnable, pas comme un défaut caché.

Je pense toutefois que la manière dont c’est présenté mérite d’être examinée une seconde fois. « Pas de Bitcoin enveloppé » est le titre, et « pas de Bitcoin enveloppé, sauf pendant le règlement » est le mécanisme réel : ce sont deux affirmations différentes, même si la seconde est défendable.

@BabylonLabs_io #baby $BABY

Quatorze mille dollars. Voilà ce que pourrait coûter un seul litige contesté sur Bitcoin, avec la méthode d’authentification plus ancienne BitVM2, dans son parcours malheureux.

BitVM3 a corrigé cela en déplaçant la vérification hors chaîne vers un circuit à garbling. Moins coûteux sur la chaîne, mais chaque circuit fait quarante-deux gibioctets : assez lourd pour exclure discrètement les participants plus modestes.

La BABE de Babylon est la prochaine tentative dans cette même lignée, en conservant les économies sur la chaîne tout en réduisant le stockage et le coût de configuration d’environ trois ordres de grandeur, selon le véritable article eprint.

L’article a été accepté à la CCS 2026, un vrai lieu de sécurité évalué par des pairs. Cela signifie que les calculs ont été vérifiés, pas qu’il a encore été testé avec de l’argent adversarial en conditions réelles.

Chaque version de cette lignée a corrigé un goulot d’étranglement et a discrètement déplacé le coût ailleurs. Je ne pense pas que BABE soit la dernière version de ce schéma non plus.

@BabylonLabs_io #baby $BABY

Dix pour cent m’ont stoppé aujourd’hui, pas comme un mouvement de prix, mais comme un nombre codé en dur intégré dans une proposition de mise à niveau.

Babylon Genesis a ajouté un module de limitation du taux IBC qui plafonne la quantité de BABY pouvant quitter la chaîne via des transferts inter-chaînes sur une fenêtre glissante de vingt-quatre heures. Dix pour cent de l’offre totale, appliqués par le code, et non comme une politique que quelqu’un doit se rappeler d’appliquer.

J’ai lu attentivement la raison invoquée. Elle existe pour empêcher des sorties à grande échelle en période de volatilité du marché ou lors d’une exploitation de pont ailleurs dans l’écosystème, ce type de contagion qui a frappé d’autres chaînes sans prévenir.

Cela m’a rappelé quelque chose qui n’a rien à voir avec la crypto. Les coupe-circuits du NYSE ont été déclenchés quatre fois sur une période de neuf jours en mars 2020, à chaque fois après que le S&P 500 ait chuté de sept pour cent peu après l’ouverture, les premiers arrêts généralisés en plus de deux décennies.

Personne ne débat du fait que ce mécanisme soit parfait. Il existe parce que quelqu’un a décidé qu’un nombre précis valait mieux que de laisser la réponse au jugement humain au milieu d’une crise.

La version de Babylon fonctionne de la même manière dans l’esprit : un nombre choisi à l’avance plutôt qu’une décision prise sous pression plus tard.

Cependant, j’ai regardé plus attentivement ce que cela couvre réellement, et le périmètre est plus étroit qu’il n’en a l’air au premier abord. Cela protège contre les sorties via les transferts IBC spécifiquement ; une exploitation de contrat intelligent qui drainerait des fonds à l’intérieur même de la chaîne ne serait donc pas stoppée par le même mécanisme.

Cette distinction compte. Un coupe-circuit visant une porte de sortie ne sécurise pas toutes les portes du bâtiment.

Étendre une protection similaire à d’autres actifs nécessite un vote effectif de gouvernance ; le périmètre actuel reste donc volontairement étroit plutôt que large par défaut.

Je ne sais pas si dix pour cent est le bon chiffre, ni même si cette catégorie de protection est la plus importante à avoir. Je sais seulement que le choix d’encoder à l’avance un nombre précis dit quelque chose sur la façon dont une équipe pense l’échec avant qu’il ne se produise, même si cela ne couvre qu’une partie de l’ensemble.

@BabylonLabs_io #baby $BABY

Babylon l’a qualifié de moment historique. Le bassin derrière ce moment contenait quatorze dollars.

Pas quatorze millions : quatorze dollars. C’était la liquidité réelle sur le marché lorsque Babylon a annoncé son premier test de Trustless Bitcoin Vaults sur le réseau principal Ethereum via Morpho.

Le mécanisme lui-même était réel. Le BTC natif utilisé comme garantie pour emprunter un USDC réel, sans wrapper, sans pont : le Bitcoin était verrouillé sur sa propre chaîne pendant toute la durée.

J’ai continué à lire au-delà du titre, pour voir comment la partie « trustless » fonctionne réellement. Le Bitcoin ne vérifie pas la logique du prêt ni la preuve sous-jacente elle-même : l’exécution se fait hors chaîne via un circuit brouillé, un vérificateur chiffré qui ne détecte la fraude que si quelqu’un l’exécute réellement et soumet la preuve à temps.

C’est une hypothèse de vivacité (liveness), pas une garantie. Si personne ne conteste rapidement une fausse preuve de remboursement, la tricherie réussit.

Cela dit, voici mon contrepoint. Cette compensation existe déjà au sein du propre réseau Lightning de Bitcoin, et elle a plutôt bien résisté dans la pratique.

Si une partie d’un canal Lightning se met hors ligne et que son contrepartiste diffuse un état de canal plus ancien et plus favorable, la partie honnête ne conserve ses fonds que si quelqu’un diffuse une transaction de justice avant l’expiration du délai (timelock). Les services de watchtower existent précisément pour combler ce manque, et les utilisateurs qui comprennent le risque exécutent simplement une watchtower ou s’appuient sur un fournisseur qui le fait.

Les hypothèses de vivacité ne sont pas automatiquement fatales : elles exigent simplement que quelqu’un de crédible surveille réellement. La vraie question est de savoir si la version de Babylon a la même densité de surveillants honnêtes, et un test de quatorze dollars ne peut pas y répondre.

Un chercheur indépendant, qui a examiné directement le livre blanc avec l’équipe de Babylon, a détaillé les conditions spécifiques qu’un véritable prêt Bitcoin trustless doit remplir, puis a montré que la conception en satisfait certaines tout en s’appuyant encore sur le comportement de contestation hors chaîne pour le reste.

Je ne le comprends pas comme accablant. Je le vois comme la même question inachevée que tout système minimisant la confiance doit finir par résoudre dès que de l’argent réel apparaît.

$BABY #baby @BabylonLabs_io

Vingt-huit jours contre deux jours m’ont arrêté aujourd’hui.

La plupart des chaînes Cosmos conservent des fonds non misés pendant environ un mois afin que les mauvais validateurs puissent encore être pénalisés. Babylon réduit ce délai à environ deux jours.

Le manque est comblé par le Bitcoin lui-même. Les fournisseurs de finalité font des pointages dans la chaîne de Bitcoin, et revenir sur cet historique signifierait revenir sur celui de Bitcoin aussi.

Mon contrepoint : les rollups optimistes d’Ethereum font face au même compromis et se sont arrêtés à sept jours. Des itinéraires de retrait rapides n’éliminent pas cette attente ; un tiers avance simplement les fonds et attend tranquillement.

Les deux jours de Babylon ne fonctionnent pas ainsi. Cela s’appuie sur la couche de règlement de Bitcoin plutôt que sur une fenêtre de contestation, ce qui constitue un ancrage plus solide, même s’il n’a pas encore été confronté à une véritable réorganisation contestée.

Un autre détail a retenu mon attention. Les BSN reversent une partie de leurs récompenses à Babylon Genesis pour cette coordination ; ainsi, le modèle gagne des frais, il ne fait pas que distribuer du rendement.

Un déblocage plus rapide ici n’est pas prouvé comme étant plus sûr. Il s’appuie simplement sur un autre type de garantie, et cette garantie est encore récente.

@BabylonLabs_io #baby $BABY

Trois millions de dollars ont quitté la trésorerie de Babylon en avril, et ce n’était pour rien de ce que Babylon avait construit.

L’exploitation du Kelp DAO avait déjà vidé du rsETH sa passerelle et laissé Aave avec de mauvaises créances. Babylon a injecté deux millions dans Aave V3 et un million dans Aave V4 dans le cadre de la reprise.

Un détail plus modeste a retenu mon attention plus longtemps que le montant lui-même. Babylon a indiqué que tout intérêt généré par ce dépôt reviendrait à Aave grâce à des incitations liées à une intégration prévue entre les deux protocoles.

Ce n’est pas tout à fait un don. Ça ressemble plutôt à un dépôt assorti d’une relation : un soutien qui sert aussi, en plus, un intérêt futur.

C’est là que j’ai ralenti. La crypto a déjà vu des gestes de sauvetage se révéler être autre chose par le passé.

En novembre 2022, Binance s’est proposé d’acquérir FTX lorsque FTX a fait face à une crise de liquidité, et pendant environ une journée, il a semblé que l’industrie faisait bloc. Moins de vingt-quatre heures plus tard, Binance s’est retiré, invoquant ce qu’elle avait trouvé une fois qu’elle s’était penchée de plus près sur les comptes.

Cet exemple n’accuse pas Babylon de quoi que ce soit. Il me rappelle simplement qu’une offre de sauvetage et un véritable sauvetage ne sont pas toujours la même chose, et que la différence n’apparaît parfois que plus tard.

J’ai examiné d’où venait le capital de Babylon avant de supposer trop. A16z avait investi quinze millions dans Babylon Labs en janvier, pour des coffres de garantie natifs en Bitcoin : un capital qui, manifestement, n’est pas resté confiné à l’objectif initial.

Je me suis demandé pourquoi un protocole de staking Bitcoin se soucierait, même, d’une exploitation de restaking sur Ethereum. Aave se situe assez près du cœur de la finance décentralisée pour que l’instabilité, là-bas, se propage vers l’extérieur, qu’un protocole le veuille ou non.

Je ne traite pas ce dépôt comme un simple geste de bonne volonté ou comme une stratégie pure. La plupart des capitaux de sauvetage dans ce secteur combinent les deux, et il faut généralement du temps avant que quiconque puisse dire lequel pilotait réellement l’ensemble.

@BabylonLabs_io #baby $BABY

Je lisais aujourd’hui une divulgation sur GitHub au lieu d’un graphique de prix, et cela m’a arrêté davantage que n’importe quel chiffre ne l’aurait fait.

Un contributeur se faisant appeler GrumpyLaurie55348 a déposé une alerte de sécurité contre Babylon en décembre. Les validateurs pouvaient soumettre un vote en omettant complètement le champ du hachage du bloc.

Protobuf considère ce champ comme optionnel, donc le vote est quand même désérialisé. Le hachage du bloc revient simplement à nil, et Babylon déréférence ce pointeur nil à l’intérieur de la vérification du vote, provoquant un panic d’exécution.

Les bornes d’époque sont déjà un point sensible dans n’importe quelle chaîne Cosmos SDK. Le fait que plusieurs validateurs crashent en même temps pourrait ralentir la production de blocs à l’échelle du réseau, pas seulement pour un nœud.

Personne n’a exploité la faille avant que le correctif ne soit publié. Babylon a corrigé le problème en version 4.2.0 après la publication de l’alerte, et la couverture de la divulgation s’est étendue tout au long de janvier.

L’intervalle entre le dépôt et l’attention publique est la partie qui est restée avec moi.

Cela m’a rappelé Polygon en 2021. Un chercheur a découvert une faille dans le Plasma Bridge qui permettait de soumettre à nouveau un retrait 223 fois, à chaque fois en vidant le même montant, avec environ 850 millions de dollars théoriquement exposés.

Polygon l’a confirmé en moins de trente minutes et a versé deux millions de dollars une fois le correctif déployé en toute sécurité.

Babylon sécurise des milliards de Bitcoin natifs via du code qui est encore aussi jeune. Un champ manquant dans une extension de vote est un petit détail sur le papier, mais il se trouve dans le mécanisme exact qui maintient les validateurs honnêtes.

Je ne pense pas qu’un bug corrigé, à lui seul, me dise grand-chose. En revanche, je pense que la rapidité avec laquelle quelque chose est trouvé et corrigé m’en apprend davantage sur un protocole que n’importe quel chiffre de TVL.

@BabylonLabs_io #baby $BABY

Aujourd’hui, je revenais sans cesse à un détail dans la conception de Babylon, pas au prix : à la partie “custody” (la conservation).

Le BTC ne quitte jamais la chaîne Bitcoin pendant le staking. Aucun wrapping, aucun bridge, aucun tiers ne conserve les clés.

C’est une affirmation plus discrète que celles que font la plupart des protocoles, et il m’a fallu un moment pour comprendre pourquoi cela compte.

Je repensais au piratage du bridge Ronin, il y a quelques années : plus de 600 millions de dollars perdus parce que des actifs BTC et ETH étaient passés via un petit ensemble de clés de validateurs.

Le modèle de Babylon supprime exactement ce point de défaillance, puisque le Bitcoin lui-même ne migre jamais vers une autre chaîne.

Les coffres détiennent désormais plus de 56 000 BTC, soit près de 5,6 milliards de dollars, stakés directement contre la sécurité propre de Bitcoin.

Pour donner un ordre d’idée, c’est plus de BTC verrouillés nativement qu’il n’en existe, au total, sur l’ensemble des wrapped Bitcoin ailleurs.

Mais voilà où j’ai ralenti. Réduire le risque lié aux bridges ne supprime pas tous les risques.

Les conditions de slashing, le comportement des validateurs et les nouveaux contrats de multi-staking portent encore chacun leur propre surface d’attaque, et rien de tout cela n’a encore été testé sur un cycle de marché complet.

Le prix du token reflète une partie de cette incertitude. BABY a chuté fortement plus tôt cette année avant de rebondir, et la courbe semble toujours instable.

Je ne vois toutefois pas cela comme un défaut du mécanisme. Supprimer une catégorie de risque n’est pas la même chose que supprimer tous les risques, et cette distinction compte davantage pour moi que la courbe de prix.

#baby $BABY @BabylonLabs_io