Sattar Chaqer

Le marché d’aujourd’hui envoie des signaux mitigés.

$HEMI +27,74%
$CYS -52,75%

L’un est en train d’être propulsé tandis que l’autre se fait littéralement écraser. La crypto peut vraiment changer l’humeur en quelques secondes.

L’identité sur une blockchain n’a pas toujours besoin de signifier la mise à disposition de chaque détail à propos d’un utilisateur dans le domaine public.

C’est pourquoi Citadel a retenu mon attention lorsque je parcourais la documentation de Dusk. Le glossaire décrit Citadel comme la couche d’identité et d’accès de Dusk, construite autour de la divulgation sélective.

L’idée est simple, mais la distinction compte : prouver qui quelqu’un est ou s’assurer qu’il a accès ne signifie pas automatiquement rendre visible à tous chaque élément d’information d’identité.

Pour les applications financières, cela peut devenir important. Un réseau peut avoir besoin de contrôles d’identité et d’accès tout en respectant la confidentialité des informations sensibles. Plutôt que de considérer la transparence comme un choix tout ou rien, la divulgation sélective ouvre la voie à un modèle de visibilité plus contrôlé.

Ce que je trouve intéressant, c’est que Citadel s’inscrit aux côtés de l’architecture plus large de confidentialité de Dusk, plutôt que de la remplacer. Dusk définit aussi le standard Confidential Security Contract comme un cadre capable de s’adapter aux exigences de l’entreprise, comme les contraintes de confidentialité et les règles de conformité.

Ainsi, l’identité ressemble moins à une case KYC séparée et davantage à une partie de l’infrastructure.

La vraie question, pour moi, est jusqu’où la divulgation sélective peut aller tout en gardant les applications financières à la fois privées et utilisables.

@Dusk $DUSK #dusk

La confidentialité sur une blockchain ne signifie pas nécessairement que chaque transaction devienne invisible pour tout le monde, et cette distinction est importante pour les applications financières.

Dusk aborde la confidentialité à travers différents niveaux de visibilité. Moonlight fournit des flux de comptes publics transparents, tandis que Phoenix prend en charge des transferts masqués grâce à des preuves de connaissance zéro. Avec Phoenix, la validité des transactions peut être vérifiée sans exposer publiquement le montant transféré, l’expéditeur ni les notes spécifiques concernées.

La partie intéressante, c’est ce qui se passe lorsqu’une personne a réellement besoin de preuves. La documentation de Dusk décrit la divulgation sélective comme un moyen pour des parties autorisées, telles que les émetteurs, les plateformes, les auditeurs ou les superviseurs, d’accéder aux informations nécessaires sans rendre publiques des données inutiles. Des clés de consultation (viewing keys) peuvent être utilisées lorsque la réglementation ou les audits exigent une visibilité contrôlée.

Cela donne une idée différente de la transparence. Au lieu de supposer que tout doit être public pour qu’une blockchain reste vérifiable, Dusk sépare la visibilité publique de la divulgation contrôlée.

Pour les marchés réglementés, cette distinction peut compter. Un investisseur ne souhaite peut-être pas que chaque solde ou transfert soit exposé à l’ensemble du réseau, tandis qu’un auditeur peut avoir encore besoin de preuves spécifiques pour vérifier une transaction ou un processus financier.

L’objectif n’est donc pas simplement d’avoir des transactions privées. Il s’agit plutôt de préserver de façon plus précise des informations sensibles confidentielles tout en conservant un chemin pour une vérification autorisée lorsque cela est réellement nécessaire.

@Dusk $DUSK #dusk

Les transactions publiques et privées nécessitent généralement des systèmes différents, mais Dusk met les deux modèles dans le même réseau.

Moonlight est le modèle de transaction d’account public de Dusk. Une transaction identifie l’expéditeur et le destinataire via leurs clés publiques, tandis que des champs tels que la valeur, le nonce, la limite de gas, le prix du gas et la signature aident le réseau à vérifier et à traiter la transaction. Le modèle offre également des protections telles que l’inforgeabilité, la prévention des doubles dépenses, la non-malleabilité et la prévention des attaques par rejeu.

Phoenix adopte une approche différente. Il s’appuie sur l’architecture UTXO, similaire à celle de Bitcoin, mais y ajoute des mécanismes de confidentialité. Au lieu de révéler quel note précis a été dépensé, le réseau suit des nullifiants pour empêcher les doubles dépenses sans identifier publiquement la note exacte au sein de l’arbre de Merkle.

Il existe aussi une différence importante dans la vérification. Les transactions Phoenix incluent une preuve de connaissance nulle permettant au réseau de vérifier que la transaction respecte les règles, sans s’appuyer sur le même type de contrôles directs utilisés par Moonlight.

Ainsi, Moonlight et Phoenix ne sont pas des versions concurrentes de Dusk. Elles fournissent différents modèles de transaction selon des exigences de visibilité différentes.

@Dusk $DUSK #dusk

Les blockchains publiques et la finance réglementée semblent souvent vouloir des choses opposées. L’une privilégie la visibilité ouverte tandis que l’autre a besoin de confidentialité, d’auditabilité et de conformité.

Dusk est conçu pour combler cet écart.

Le livre blanc de Dusk décrit une blockchain prête pour la conformité, axée sur la confidentialité, destinée à relier des plateformes décentralisées aux marchés financiers traditionnels. Au lieu de traiter la confidentialité et la réglementation comme des couches distinctes, Dusk intègre l’auditabilité des transactions confidentielles et la conformité dans le cœur de son infrastructure.

Le modèle de transaction fait partie intégrante de cette conception. Dusk prend en charge Moonlight, son modèle public basé sur des comptes, ainsi que Phoenix, son modèle UTXO protégé. Cela offre au réseau différentes façons de gérer la visibilité des transactions en fonction du cas d’usage.

C’est important pour les applications financières, car la confidentialité ne signifie pas nécessairement que l’information disparaît. L’approche de Dusk consiste à contrôler ce qui est visible et par qui, tout en préservant la capacité de répondre aux exigences des marchés réglementés.

Pour moi, cela rend la proposition de Dusk plus intéressante que de la qualifier simplement de blockchain de confidentialité. Elle cherche à faire fonctionner ensemble, au niveau du protocole, la confidentialité, la conformité et l’infrastructure financière.

@Dusk $DUSK #dusk

Le marché d’aujourd’hui était rempli de surprises.

$CYS +95,27 %
$UAI -33,33 %

Un token s’envole tandis qu’un autre prend une grosse claque. C’est ça, la crypto. Je faisais juste le point sur les graphiques aujourd’hui.

Les gens supposent souvent que deux blockchains doivent se comprendre avant de pouvoir travailler ensemble. Plus j’étudiais l’architecture de Babylon, moins cette hypothèse me semblait convaincante.

Le Bitcoin n’a jamais été conçu pour interpréter l’exécution d’Ethereum ou conserver une copie de son état. Tenter de le faire en changerait les principes mêmes qui rendent le Bitcoin prévisible. Au lieu de cela, Babylon aborde le problème par un autre angle. Plutôt que d’apprendre à Bitcoin à comprendre une autre blockchain, il lui donne quelque chose qu’il sait déjà évaluer : une preuve cryptographique. L’objectif n’est pas une compréhension partagée. Il s’agit d’une vérification indépendante.

Cette nuance a changé ma façon de penser l’interopérabilité. Deux systèmes n’ont pas nécessairement besoin de parler le même langage pour parvenir à la même conclusion. Ils ont seulement besoin d’une preuve qui peut être vérifiée selon leurs propres règles. En ce sens, les preuves ressemblent moins à des messages et davantage à des témoins mathématiques que chaque partie n’a pas besoin d’interpréter en faisant confiance.

Plus je réfléchis à ce design, plus je pense que l’infrastructure inter-chaînes posait peut-être la mauvaise question. Au lieu de se demander comment les blockchains peuvent se comprendre, peut-être devrait-on plutôt se demander comment elles peuvent vérifier la même réalité tout en restant totalement indépendantes.

Peut-être que le futur de l’interopérabilité n’appartiendra pas aux réseaux qui communiquent le plus. Il appartiendra à ceux qui ont le moins besoin de faire confiance à la communication.

@BabylonLabs_io $BABY #baby

Depuis 2 jours, je ne reçois pas de points de trading pour 2026/07/31 et 2026/08/01. Voici les captures d’écran

Beaucoup de gens supposent que si Bitcoin doit participer ailleurs, Bitcoin lui-même doit d’abord bouger. Cette hypothèse a façonné la conception des échanges inter-chaînes pendant des années. Je commence à penser que le mouvement n’est pas la partie la plus importante.

Ce qui m’a frappé en lisant la documentation de Babylon, c’est que l’architecture sépare la propriété de la participation économique. Le BTC natif reste verrouillé sur le réseau Bitcoin, selon ses hypothèses de sécurité d’origine, tandis que sa valeur économique peut soutenir le prêt, des stablecoins, des perpétuels et d’autres applications financières via des Trustless Bitcoin Vaults. L’objectif n’est pas de déplacer Bitcoin. Il s’agit d’étendre ce que Bitcoin peut apporter sans changer ce qu’est Bitcoin.

Cette distinction a changé ma façon de voir l’interopérabilité. Peut-être avons-nous passé trop de temps à concevoir de meilleures façons de transférer des actifs entre écosystèmes et pas assez de temps à concevoir des systèmes qui peuvent fonctionner avec des actifs là où ils existent déjà.

Si cette idée continue de mûrir, le rôle de Bitcoin dans la finance décentralisée pourrait ne plus dépendre du nombre de chaînes qu’il peut atteindre. Il pourrait dépendre de la quantité d’activité économique qui peut se développer pendant que Bitcoin ne quitte jamais son domicile.

Peut-être que le futur du BTCFi ne consiste pas à déplacer Bitcoin. Peut-être que c’est plutôt à déplacer tout le reste, sauf Bitcoin.

@BabylonLabs_io $BABY #baby

On suppose souvent que, dès que Bitcoin entre dans la DeFi, il doit cesser d’être Bitcoin. Les tokens enveloppés — des actifs synthétiques — et les gardiens (custodians) ont rendu cette hypothèse presque inévitable. Je commence à penser que l’hypothèse elle-même mérite davantage d’examen.

Ce qui m’a frappé dans l’architecture de Babylon, c’est qu’elle aborde le problème à l’inverse. Au lieu de créer une nouvelle représentation du BTC, elle se demande si le Bitcoin natif peut rester sur son propre réseau tout en prenant en charge, via des Trustless Bitcoin Vaults, le prêt, les stablecoins, les perpetuals et d’autres applications financières. Le défi n’est pas de donner à Bitcoin une nouvelle identité. Il s’agit de prouver que son identité actuelle suffit.

Cette distinction a changé ma façon de penser le collatéral. Peut-être que la véritable innovation n’est pas d’inventer une meilleure version de Bitcoin. Peut-être qu’il s’agit de concevoir une infrastructure qui s’adapte à Bitcoin, plutôt que d’exiger que Bitcoin s’adapte d’abord.

Si cette approche réussit, la conversation autour du BTCFi pourrait être complètement différente. La question ne sera plus de savoir comment recréer Bitcoin ailleurs. Elle sera de mesurer jusqu’où le Bitcoin natif peut participer sans jamais devenir un autre actif.

Peut-être que l’avenir de Bitcoin dans la DeFi n’est pas défini par la représentation. Peut-être qu’il est défini par la préservation de l’authenticité tout en élargissant l’utilité.

@BabylonLabs_io $BABY #baby

On décrit souvent Babylon Genesis comme un simple autre blockchain. Après avoir lu la documentation, je ne pense pas que ce soit la manière la plus intéressante de la voir.

La plupart des blockchains se préoccupent avant tout de produire leurs propres blocs. Babylon Genesis le fait certainement, mais la documentation décrit à plusieurs reprises quelque chose de plus large. Elle agit comme une couche de coordination pour le staking Bitcoin, l’horodatage, la sécurité et la distribution des récompenses. Plutôt que d’entrer en concurrence avec Bitcoin, elle organise la manière dont la sécurité de Bitcoin peut être appliquée à d’autres systèmes.

Cette distinction a changé ma façon de penser le réseau. La valeur de Babylon Genesis ne vient peut-être pas du fait d’être une autre destination pour les actifs. Elle tient au fait d’aider des participants indépendants à parvenir à la même vision de la sécurité et de l’état, tout en ancrant des événements importants dans le registre de Bitcoin grâce à l’horodatage et au pointage.

Plus je réfléchissais à cette conception, moins cela me semblait être une couche 1 traditionnelle. J’avais plutôt l’impression qu’il s’agissait d’une infrastructure qui coordonne la confiance plutôt que d’essayer de la capter. La production de blocs n’est qu’une seule responsabilité. Le rôle plus large consiste à faire fonctionner ensemble, en tant qu’un système unique, les récompenses de sécurité et la coordination adossée à Bitcoin.

Peut-être que Babylon Genesis n’est pas définie par les blocs qu’elle produit. Peut-être qu’elle est définie par tout ce qu’elle coordonne discrètement entre eux.

@BabylonLabs_io $BABY #baby

On suppose souvent que si un protocole comporte un opérateur, cet opérateur doit aussi être la partie en qui vous faites confiance pour vos actifs. Plus j’ai étudié la conception du coffre (vault) de Babylon, plus j’ai compris que ces deux responsabilités sont volontairement séparées.

Un Fournisseur de coffre a un rôle important. Il coordonne le travail hors chaîne nécessaire pour créer puis récupérer un coffre, y compris la génération de preuves, la gestion de transactions pré-signées et la coordination avec les Gardiens de Coffre d’Application. Mais d’après la documentation, il ne détient jamais et ne contrôle jamais le Bitcoin du déposant. Les conditions de dépense sont fixées lors de la création du coffre, ce qui fait que le rôle du fournisseur est opérationnel plutôt que dépositaire.

Cette distinction a changé la façon dont je pense l’infrastructure. La coordination est nécessaire car les systèmes complexes ont besoin de participants pour maintenir les processus en mouvement. La confiance est différente. La confiance détermine qui peut finalement décider du sort de vos actifs.

L’architecture de Babylon semble tracer une frontière délibérée entre ces idées. Un Fournisseur de coffre aide le protocole à fonctionner, mais il ne gagne pas d’autorité sur le BTC lui-même. Même si plus tard un fournisseur devient indisponible, la documentation décrit un parcours de réclamation (self claim) du déposant, conçu pour permettre aux utilisateurs de récupérer leur Bitcoin de manière indépendante.

Peut-être qu’un signe d’une conception de protocole mûre n’est pas de supprimer complètement les rôles opérationnels. C’est de s’assurer que ces rôles ne deviennent jamais des positions de dépositaire.

@BabylonLabs_io $BABY #baby

Les gens supposent souvent que si vous avez du Bitcoin en garantie, le fait de tout conserver au même endroit est le choix le plus simple. Plus j’examinais la conception des coffres de Babylon, moins j’étais convaincu.

La documentation recommande de fractionner le Bitcoin en deux coffres plutôt que de s’appuyer sur un seul. Au début, cela m’a semblé comme une complexité supplémentaire. Puis j’ai compris que cette conception ne vise pas à créer davantage de coffres. Elle vise à créer davantage de contrôle. Au sein d’une position d’emprunt, les coffres peuvent être ordonnés de façon à ce que la liquidation en atteigne un avant les autres, permettant ainsi au coffre sacrificiel désigné d’absorber les pertes tandis qu’un coffre protégé reste intact si les conditions s’améliorent avant qu’une nouvelle liquidation soit nécessaire.

Cela change ma façon de penser la garantie. Au lieu de traiter chaque satoshi comme exposé de manière équivalente, Babylon introduit des limites à l’intérieur même de la position. L’objectif n’est pas seulement de survivre à une liquidation. Il s’agit d’éviter de transformer chaque revers du marché en un événement « tout ou rien ».

Peut-être que la bonne conception d’une garantie ne se mesure pas à la quantité de Bitcoin que vous immobilisez. Peut-être qu’elle se mesure plutôt par la manière dont vous décidez avec intention quel Bitcoin doit supporter la première couche de risque.

@BabylonLabs_io $BABY #baby

La plupart des gens supposent que le fait de regrouper des actifs rend un système plus efficace. Cela semble raisonnable tant qu’on ne commence pas à réfléchir à ce qui se passe quand quelque chose tourne mal.

Les coffres Bitcoin sans confiance de Babylon empruntent un chemin nettement différent. Au lieu de déposer les BTC de nombreux utilisateurs dans une réserve commune, chaque coffre est rattaché à son propre UTXO. Au premier abord, cela peut sembler être un simple détail de mise en œuvre. Plus je l’examinais, plus cela ressemblait à une approche délibérée de la gestion du risque, plutôt qu’à un simple stockage de Bitcoin.

Quand une garantie est mise en commun, le problème d’un participant peut progressivement devenir la préoccupation de tout le monde. Des coffres isolés modifient cette relation. Chaque coffre suit son propre cycle de vie, son propre processus de vérification et son propre chemin de remboursement. Le risque reste lié au Bitcoin spécifique utilisé, au lieu de se répartir entre des dépôts sans lien.

Cela m’a fait me demander si l’isolation concerne vraiment la garde. Peut-être qu’il s’agit plutôt de préserver des limites claires. Un protocole ne devient pas plus robuste parce qu’il regroupe tout. Parfois, la résilience consiste à s’assurer que des positions indépendantes restent indépendantes, même lorsqu’elles participent au même système.

Peut-être que la partie la plus importante de la conception des coffres de Babylon n’est pas que le Bitcoin reste sur Bitcoin. C’est que chaque coffre ne porte que sa propre responsabilité.

@BabylonLabs_io $BABY #baby

On décrit souvent les systèmes inter-chaînes comme si la partie la plus difficile consistait à envoyer des informations d’un réseau à un autre. Je ne suis pas convaincu que ce soit là le vrai défi.

Bitcoin n’a aucun moyen natif de comprendre ce qui se passe sur Ethereum. Il n’a pas été conçu pour interpréter l’historique d’une autre blockchain, et lui demander de le faire modifierait les hypothèses mêmes qui le rendent fiable.

Ce qui a attiré mon attention dans l’architecture de Babylon, c’est qu’elle ne cherche pas à apprendre à Bitcoin un nouveau langage. Au contraire, elle traite les preuves cryptographiques comme la seule chose qui mérite d’être présentée. L’objectif n’est pas une meilleure communication entre les chaînes. Il s’agit plutôt de donner à Bitcoin une preuve qu’il peut vérifier, sans dépendre de l’interprétation de quelqu’un d’autre.

Cette perspective m’a amené à repenser l’interopérabilité. Peut-être que des réseaux indépendants n’ont pas besoin de se comprendre du tout. Ils doivent simplement disposer d’un moyen fiable pour valider la même réalité au moyen d’une preuve cryptographique.

Si c’est le cas, la vérification des preuves n’est pas seulement un composant technique caché sous la surface. Elle devient silencieusement le socle qui permet à des systèmes distincts de se coordonner tout en préservant leurs propres modèles de sécurité.

Peut-être que le futur de l’infrastructure inter-chaînes ne sera pas défini par la qualité de la communication entre blockchains, mais par la quantité minimale qu’elles doivent se faire confiance.

@BabylonLabs_io $BABY #baby

Une chose qui ressort particulièrement en étudiant Babylon, c’est que les limites de Bitcoin peuvent en réalité constituer l’une de ses plus grandes forces. Bitcoin Script n’a jamais été conçu comme une plateforme généraliste de contrats intelligents. Sa simplicité a souvent été perçue comme une contrainte, mais l’architecture de Babylon suggère un autre point de vue : au lieu de demander à Bitcoin de devenir autre chose, construire un système qui respecte ces limites.

Cette philosophie de conception a attiré mon attention. Plutôt que d’étendre Bitcoin avec de nouveaux opcodes ou de s’appuyer sur des actifs tokenisés (« wrapped assets »), les Trustless Bitcoin Vaults utilisent les capacités de script existantes de Bitcoin, combinées à une vérification cryptographique au niveau du protocole, afin de coordonner les interactions avec des applications externes. La documentation souligne que le rachat et les transitions d’état entre chaînes sont vérifiés au moyen des primitives de script existantes de Bitcoin, plutôt que d’exiger un fork de Bitcoin.

Plus j’y pense, plus je me dis que les contraintes produisent souvent une meilleure ingénierie. Quand un protocole ne peut pas compter sur une programmabilité illimitée, il doit résoudre les problèmes par une coordination soigneuse, au lieu d’ajouter de la complexité à la couche de base. Cette approche me paraît différente de la tentative de faire fonctionner chaque blockchain de la même manière.

Peut-être que la vraie innovation n’est pas de faire en sorte que Bitcoin se comporte comme une plateforme de smart contract. Peut-être qu’il s’agit de concevoir des systèmes qui comprennent suffisamment bien Bitcoin pour s’intégrer à ses règles, plutôt que de les réécrire.

De fortes contraintes techniques conduisent-elles finalement à une conception de protocole plus résiliente, ou bien ralentissent-elles l’innovation sur le long terme ?

@BabylonLabs_io $BABY #baby

Je me suis surpris à penser à Babylon après avoir réalisé que le verrouillage de Bitcoin est probablement la partie la plus simple du processus. Le vrai défi d’ingénierie commence une fois que le BTC est déjà sécurisé. À ce stade, le protocole doit coordonner des événements entre différents systèmes sans demander à Bitcoin d’abandonner le modèle de sécurité qui le rend précieux en premier lieu.

Ce qui a retenu mon attention en lisant la documentation, c’est que les Trustless Bitcoin Vaults ne se contentent pas de créer un coffre. Ils définissent aussi la façon dont le remboursement est coordonné. Le BTC reste verrouillé dans un script Taproot cosigné, tandis que le protocole s’appuie sur des vérifications cryptographiques documentées et sur un processus de remboursement basé sur un défi, afin que Bitcoin puisse répondre à des événements vérifiés sans dépendre d’un dépositaire pour décider de la suite.

Cela m’a amené à considérer l’interopérabilité autrement. Le fait de transférer des actifs entre écosystèmes est un problème, mais prouver que chaque transition d’état s’est déroulée correctement est un problème de coordination bien plus difficile. Un protocole peut promettre la garde par soi-même, mais il doit encore répondre à une question encore plus grande : comment des réseaux indépendants s’accordent-ils sur ce qui s’est passé sans introduire d’intermédiaire de confiance ?

Plus j’étudie Babylon, plus je pense que sa contribution la plus importante ne réside peut-être pas dans le fait de verrouiller Bitcoin. Il s’agirait plutôt de l’effort visant à coordonner ce qui se passe après le verrouillage d’une manière fidèle aux hypothèses de sécurité originales de Bitcoin.

Verrouiller Bitcoin est-il vraiment la partie difficile, ou est-ce plutôt la preuve de ce qui se passe ensuite qui constitue le véritable défi ?

@BabylonLabs_io $BABY #baby

Une chose qui ressort quand on étudie Babylon, c’est que déplacer Bitcoin est en réalité la partie la plus facile. Le laisser exactement là où il se trouve tout en lui permettant de participer ailleurs semble être le défi d’ingénierie beaucoup plus difficile. Pendant des années, la plupart des solutions d’interopérabilité ont résolu le problème en demandant aux utilisateurs de déplacer d’abord leurs actifs, puis d’accepter de nouvelles hypothèses de confiance par la suite.

Ce qui me fait réfléchir à propos de Babylon, c’est que le projet adopte la direction opposée. Au lieu de considérer la garde comme quelque chose à externaliser, il se demande si la coordination elle-même peut être repensée. Les coffres Bitcoin sans confiance ne sont pas intéressants parce qu’ils font aller le BTC plus vite. Ils le sont parce qu’ils permettent de maintenir le Bitcoin verrouillé sur le réseau Bitcoin, tandis que la vérification cryptographique pilotée par le protocole coordonne la manière dont ce BTC peut être utilisé ailleurs, sans recourir à des actifs tokenisés (wrapped) ni à des dépositaires.

En regardant Babylon aujourd’hui, il est facile de se concentrer sur les métriques de tokens. Environ 4,02 milliards $BABY circulent actuellement sur un total de 10,89 milliards, mais ces chiffres ne décrivent le réseau qu’à cet instant. Ce qui me semble plus important, c’est de savoir si l’architecture derrière le protocole peut prouver sa résilience dans le temps. L’offre de tokens nous indique où se situe l’écosystème aujourd’hui, tandis que la conception du protocole peut déterminer où il pourra aller demain.

Peut-être que la prochaine étape pour Bitcoin n’est pas de trouver encore plus de façons de le déplacer entre différents écosystèmes. Peut-être qu’il faut construire des systèmes suffisamment sophistiqués pour permettre à Bitcoin de rester exactement là où il a sa place.

@BabylonLabs_io $BABY #baby

Plus je m’enfonce dans Babylone, plus je réalise que les détenteurs de Bitcoin se sont souvent vu présenter un faux choix : conserver le BTC tel quel pour une sécurité maximale, ou le déplacer ailleurs pour débloquer davantage d’utilité. Ce compromis a façonné la façon dont beaucoup de personnes envisagent le rôle du Bitcoin dans la finance décentralisée.

Ce qui a retenu mon attention avec Trustless Bitcoin Vaults (TBV), c’est qu’ils abordent le problème sous un angle différent. Au lieu d’envelopper le Bitcoin ou de le confier à un dépositaire, les TBV permettent au BTC de rester verrouillé sur le réseau Bitcoin dans un script Taproot co-signé, tandis qu’un protocole parallèle sur Ethereum suit le coffre pour un usage en garantie. La conception s’appuie sur une vérification cryptographique pilotée par le protocole plutôt que sur le transfert de la confiance à un intermédiaire.

À mon avis, la partie intéressante ne tient pas seulement au fait que le Bitcoin puisse participer à la DeFi. Il s’agit du changement de coordination. Au lieu de demander aux utilisateurs de remplacer le modèle de confiance du Bitcoin par un autre, Babylone explore comment les hypothèses de sécurité existantes du Bitcoin peuvent demeurer intactes tout en permettant des applications financières plus larges. Cela ressemble moins à une extension du Bitcoin par la représentation qu’à une extension du Bitcoin par l’architecture.

Pour moi, cela soulève une question plus vaste : celle de l’interopérabilité. Peut-être que le futur ne consiste pas à déplacer le Bitcoin entre les écosystèmes, mais à concevoir des systèmes capables de fonctionner avec le Bitcoin sans lui demander de quitter son domicile.

@BabylonLabs_io $BABY #baby

🟠 Ce qui compte le plus pour le BTCFi ?