Un choix de conception dans les Babylon Trustless Bitcoin Vaults se démarque pour moi : chaque coffre est créé pour une application spécifique au lieu de devenir une réserve réutilisable de collatéral. Cela peut sembler restrictif au premier abord, mais cela limite aussi l’impact si une application rencontre un bug ou modifie ses paramètres de risque.
D’après la documentation TBV actuelle, le Bitcoin reste verrouillé dans son script côté Bitcoin tandis que l’emprunt spécifique à l’application, la logique de liquidation et le comportement de l’oracle restent séparés du protocole lui-même. Cette séparation est importante car elle évite de considérer chaque risque comme un problème de garde du Bitcoin.
Ce qui m’intéresse n’est pas le mot « trustless » à lui seul, mais la façon dont les limites de confiance sont définies avec soin. Réduire la dépendance envers les dépositaires est utile, mais les utilisateurs dépendent néanmoins des contrats intelligents de l’application choisie, des hypothèses opérationnelles et de la gouvernance le cas échéant. Il s’agit de risques différents, pas de risques qui auraient disparu.
TBV est aussi encore présenté publiquement comme un système de testnet plutôt qu’un déploiement éprouvé en production. Je pense donc que la question la plus pertinente est de savoir comment ces choix de conception se comportent dans des conditions réelles plus larges au fil du temps. Si l’architecture continue de mûrir sans brouiller ces limites de confiance, elle pourrait devenir une base intéressante pour un collatéral natif en Bitcoin au-delà des modèles d’encapsulation conventionnels. @BabylonLabs_io
#baby $BABY
D’après la documentation TBV actuelle, le Bitcoin reste verrouillé dans son script côté Bitcoin tandis que l’emprunt spécifique à l’application, la logique de liquidation et le comportement de l’oracle restent séparés du protocole lui-même. Cette séparation est importante car elle évite de considérer chaque risque comme un problème de garde du Bitcoin.
Ce qui m’intéresse n’est pas le mot « trustless » à lui seul, mais la façon dont les limites de confiance sont définies avec soin. Réduire la dépendance envers les dépositaires est utile, mais les utilisateurs dépendent néanmoins des contrats intelligents de l’application choisie, des hypothèses opérationnelles et de la gouvernance le cas échéant. Il s’agit de risques différents, pas de risques qui auraient disparu.
TBV est aussi encore présenté publiquement comme un système de testnet plutôt qu’un déploiement éprouvé en production. Je pense donc que la question la plus pertinente est de savoir comment ces choix de conception se comportent dans des conditions réelles plus larges au fil du temps. Si l’architecture continue de mûrir sans brouiller ces limites de confiance, elle pourrait devenir une base intéressante pour un collatéral natif en Bitcoin au-delà des modèles d’encapsulation conventionnels. @BabylonLabs_io
#baby $BABY
