J’ai toujours une question à propos de ces mots : réserve intégrale en BTC. Même si, dans une certaine adresse, il y a bien des BTC, pourquoi le contrat de stablecoin sur une autre chaîne saurait-il avec certitude que cet argent est effectivement verrouillé, et qu’il peut être utilisé pour le rachat ou la liquidation selon les conditions prévues ?
L’architecture de stablecoin des Trustless Bitcoin Vaults (TBV) dans le livre blanc de Babylon résout d’abord précisément le problème suivant : comment « la preuve de nantissement » peut être rendue visible. Une fois que l’utilisateur dépose du BTC natif dans un Vault sur Bitcoin, la chaîne de contrats intelligents vérifie ce dépôt via un client léger Bitcoin, puis émet des tokens adossés au dollar selon un taux de nantissement prédéfini. Le BTC n’est pas transféré vers la chaîne de contrats intelligents, et il n’est pas nécessaire de l’envoyer d’abord à un dépositaire pour le convertir en un actif emballé.
Le plus important n’est donc pas qu’il existe une écriture de BTC on-chain, mais que le système de stablecoins puisse vérifier : à quel Vault appartient ce BTC, si cette réserve est toujours verrouillée à l’instant, et quel montant lui correspond en capacité d’émission. Les TBV tentent de faire participer directement la preuve de nantissement aux règles de frappe, plutôt que de contraindre l’utilisateur à n’avoir confiance que dans le fait que l’émetteur publie régulièrement un rapport de réserves.
Bien sûr, il s’agit encore de l’orientation d’application des stablecoins proposée par le livre blanc, et non d’une stablecoin Babylon déjà lancée. Le véritable besoin est de vérifier si le client léger et la validation inter-chaînes peuvent rester en permanence synchronisés avec l’état du Vault. Dès qu’il y a un écart entre ce qui se passe sur Bitcoin et ce que le contrat pense qu’il s’est passé, même l’adresse de nantissement la plus transparente ne servira plus à grand-chose. Laisser les BTC sur la chaîne d’origine n’est qu’une première étape ; la partie la plus difficile et la plus essentielle de ce dispositif consiste à faire en sorte que la réalité du nantissement reste identifiée correctement et de manière continue par une autre chaîne.
@BabylonLabs_io #baby $BABY
L’architecture de stablecoin des Trustless Bitcoin Vaults (TBV) dans le livre blanc de Babylon résout d’abord précisément le problème suivant : comment « la preuve de nantissement » peut être rendue visible. Une fois que l’utilisateur dépose du BTC natif dans un Vault sur Bitcoin, la chaîne de contrats intelligents vérifie ce dépôt via un client léger Bitcoin, puis émet des tokens adossés au dollar selon un taux de nantissement prédéfini. Le BTC n’est pas transféré vers la chaîne de contrats intelligents, et il n’est pas nécessaire de l’envoyer d’abord à un dépositaire pour le convertir en un actif emballé.
Le plus important n’est donc pas qu’il existe une écriture de BTC on-chain, mais que le système de stablecoins puisse vérifier : à quel Vault appartient ce BTC, si cette réserve est toujours verrouillée à l’instant, et quel montant lui correspond en capacité d’émission. Les TBV tentent de faire participer directement la preuve de nantissement aux règles de frappe, plutôt que de contraindre l’utilisateur à n’avoir confiance que dans le fait que l’émetteur publie régulièrement un rapport de réserves.
Bien sûr, il s’agit encore de l’orientation d’application des stablecoins proposée par le livre blanc, et non d’une stablecoin Babylon déjà lancée. Le véritable besoin est de vérifier si le client léger et la validation inter-chaînes peuvent rester en permanence synchronisés avec l’état du Vault. Dès qu’il y a un écart entre ce qui se passe sur Bitcoin et ce que le contrat pense qu’il s’est passé, même l’adresse de nantissement la plus transparente ne servira plus à grand-chose. Laisser les BTC sur la chaîne d’origine n’est qu’une première étape ; la partie la plus difficile et la plus essentielle de ce dispositif consiste à faire en sorte que la réalité du nantissement reste identifiée correctement et de manière continue par une autre chaîne.
@BabylonLabs_io #baby $BABY
