Dans le récit de TBV, on insiste fortement sur le fait que le contrôle final appartient à l’utilisateur : « ton BTC reste toujours dans ton adresse Taproot ». Mais en consultant la documentation technique, j’ai découvert une zone grise concernant la « finalité ultime », qui fait que ce « contrôle final », dans la dimension temporelle, n’est peut-être pas aussi absolu qu’on le dit.
Le problème vient des caractéristiques mêmes de la blockchain Bitcoin. Le rachat et la liquidation de TBV dépendent principalement de la confirmation des transactions sur Bitcoin. Selon l’officiel, un peg-in prend environ 3 heures : en coulisse, cela implique d’attendre 6 confirmations de blocs afin de s’assurer que la transaction ne sera pas réorganisée par la blockchain. Cette hypothèse de sécurité tient correctement 99,9 % du temps, mais historiquement, Bitcoin n’a jamais été totalement exempt de réorganisations profondes. En 2010, il y a eu une attaque par valeur ; en 2013, une fourche imprévue. Les probabilités sont extrêmement faibles, mais dès qu’une réorganisation profonde survient, les transactions des utilisateurs qui s’appuient sur « 6 confirmations de blocs » peuvent être annulées.
Imaginons un scénario extrême : l’utilisateur initie un rachat, attend 6 confirmations, puis reçoit le remboursement côté Aave et ferme la position. Une heure plus tard, la blockchain Bitcoin subit une réorganisation profonde : la transaction de rachat est annulée, le BTC revient à l’adresse inter-chaînes, tandis que la dette est déjà soldée côté Aave. Cet écart temporel et cette incohérence d’état — dans un système comme TBV qui dépend de la finalité ultime externe — ne peut pas être totalement évité, ce qui crée un risque de « cygne noir » par nature. Quoi qu’on fasse avec une logique de contrats hors-chaîne parfaitement conçue, on ne peut pas modifier la finalité ultime probabiliste intrinsèque de la blockchain Bitcoin.
Cela m’a amené à repenser le fonds d’assurance ou les mécanismes de gestion des risques du #baby . Si, à l’avenir, un scénario aussi extrême se produisait, le fonds d’assurance ou le mécanisme de gestion des risques de BABY serait-il sollicité ? Si, à l’avenir, un scénario aussi extrême se produisait, le fonds d’assurance ou le mécanisme de gestion des risques de BABY serait-il sollicité ? Si, à l’avenir, un scénario aussi extrême se produisait, le détenteur de $BABY serait-il tenu d’endosser le rôle de dernier prêteur ? Ou bien le protocole dispose-t-il de réserves dédiées ? Le modèle de sécurité de @BabylonLabs_io , dans un récit d’« absolue sécurité », a besoin d’une clarification plus claire pour gérer un risque de queue aussi infime.