Je n’arrêtais pas de me demander où se produit, en réalité, la plus grande décision de design dans les Trustless Bitcoin Vaults.
La réponse semble être le moment où un coffre BTC est créé.
Au lieu de construire un seul coffre pouvant évoluer librement entre toutes les intégrations, TBV lie chaque coffre à une application spécifique dès le départ. Sur le testnet public actuel, cette première destination est Aave v4. Une fois activé, le coffre est reconnu via un adaptateur dédié et utilisé dans le flux de prêt de cette intégration.
Ce qui ressort, c’est le modèle de sécurité.
Chaque application fonctionne avec sa propre structure de coffre et ses contrats de support. Cela signifie qu’en cas de problème technique dans une intégration, ou si elle modifie ses règles, l’impact est censé rester circonscrit plutôt que d’affecter toutes les applications propulsées par TBV.
Le compromis évident, c’est la flexibilité.
Un coffre n’est pas conçu pour passer d’un protocole à un autre plus tard. Si une autre intégration propose finalement de meilleures opportunités, les utilisateurs créeraient un nouveau coffre plutôt que de transférer l’existant.
Pour moi, cela ressemble à un choix délibéré : réduire d’abord le risque partagé, puis étendre l’utilité du Bitcoin grâce à des intégrations distinctes plutôt qu’à un collatéral partagé.
Pensez-vous que le renforcement de l’isolation des applications est la bonne direction, ou le futur de la DeFi Bitcoin devrait-il davantage viser à rendre le collatéral portable d’un protocole à l’autre ? #baby $BABY @BabylonLabs_io
La réponse semble être le moment où un coffre BTC est créé.
Au lieu de construire un seul coffre pouvant évoluer librement entre toutes les intégrations, TBV lie chaque coffre à une application spécifique dès le départ. Sur le testnet public actuel, cette première destination est Aave v4. Une fois activé, le coffre est reconnu via un adaptateur dédié et utilisé dans le flux de prêt de cette intégration.
Ce qui ressort, c’est le modèle de sécurité.
Chaque application fonctionne avec sa propre structure de coffre et ses contrats de support. Cela signifie qu’en cas de problème technique dans une intégration, ou si elle modifie ses règles, l’impact est censé rester circonscrit plutôt que d’affecter toutes les applications propulsées par TBV.
Le compromis évident, c’est la flexibilité.
Un coffre n’est pas conçu pour passer d’un protocole à un autre plus tard. Si une autre intégration propose finalement de meilleures opportunités, les utilisateurs créeraient un nouveau coffre plutôt que de transférer l’existant.
Pour moi, cela ressemble à un choix délibéré : réduire d’abord le risque partagé, puis étendre l’utilité du Bitcoin grâce à des intégrations distinctes plutôt qu’à un collatéral partagé.
Pensez-vous que le renforcement de l’isolation des applications est la bonne direction, ou le futur de la DeFi Bitcoin devrait-il davantage viser à rendre le collatéral portable d’un protocole à l’autre ? #baby $BABY @BabylonLabs_io
