Siempre me ha surgido una duda con la frase “reservas en BTC totalmente respaldadas”: aunque en una dirección concreta efectivamente haya BTC, ¿por qué el contrato de la stablecoin en otra cadena puede saber con certeza que ese dinero está realmente bloqueado y además utilizarse para el rescate o la liquidación según las condiciones establecidas?
La arquitectura de stablecoins de Trustless Bitcoin Vaults (TBV) en el whitepaper de Babylon resuelve precisamente primero “cómo se puede ver el hecho del respaldo”. Cuando los usuarios depositan BTC nativa en el Vault de Bitcoin, la cadena de contratos inteligentes verifica el depósito mediante light clients de Bitcoin y, después, acuña tokens vinculados al dólar con una tasa de colateralización predefinida. El BTC no se transfiere a la cadena de contratos inteligentes y tampoco es necesario entregarlo primero a un custodio para convertirlo en un activo “envuelto”.
Lo más importante aquí no es que haya una cantidad de BTC en cadena, sino que el sistema de la stablecoin pueda verificar: a qué Vault pertenece ese BTC, si actualmente sigue bloqueado y cuánto monto acuñable le corresponde. TBV intenta que la prueba de respaldo participe directamente en las reglas de acuñación, en lugar de obligar a los usuarios a confiar en que el emisor publique periódicamente un informe de reservas.
Por supuesto, esta sigue siendo la dirección de aplicación de stablecoins propuesta en el whitepaper, y no una stablecoin de Babylon ya puesta en marcha. Lo que realmente se necesita comprobar es si el light client y la verificación entre cadenas pueden sincronizar de forma continua y correcta el estado del Vault. Si en Bitcoin ocurre algo que difiere de lo que el contrato cree que ocurrió, incluso una dirección de respaldo perfectamente transparente no servirá de nada. Dejar el BTC en la cadena original es solo el primer paso; el paso más difícil y crucial de este esquema es lograr que el hecho del respaldo se identifique de manera correcta y continua desde otra cadena.
@BabylonLabs_io #baby $BABY
La arquitectura de stablecoins de Trustless Bitcoin Vaults (TBV) en el whitepaper de Babylon resuelve precisamente primero “cómo se puede ver el hecho del respaldo”. Cuando los usuarios depositan BTC nativa en el Vault de Bitcoin, la cadena de contratos inteligentes verifica el depósito mediante light clients de Bitcoin y, después, acuña tokens vinculados al dólar con una tasa de colateralización predefinida. El BTC no se transfiere a la cadena de contratos inteligentes y tampoco es necesario entregarlo primero a un custodio para convertirlo en un activo “envuelto”.
Lo más importante aquí no es que haya una cantidad de BTC en cadena, sino que el sistema de la stablecoin pueda verificar: a qué Vault pertenece ese BTC, si actualmente sigue bloqueado y cuánto monto acuñable le corresponde. TBV intenta que la prueba de respaldo participe directamente en las reglas de acuñación, en lugar de obligar a los usuarios a confiar en que el emisor publique periódicamente un informe de reservas.
Por supuesto, esta sigue siendo la dirección de aplicación de stablecoins propuesta en el whitepaper, y no una stablecoin de Babylon ya puesta en marcha. Lo que realmente se necesita comprobar es si el light client y la verificación entre cadenas pueden sincronizar de forma continua y correcta el estado del Vault. Si en Bitcoin ocurre algo que difiere de lo que el contrato cree que ocurrió, incluso una dirección de respaldo perfectamente transparente no servirá de nada. Dejar el BTC en la cadena original es solo el primer paso; el paso más difícil y crucial de este esquema es lograr que el hecho del respaldo se identifique de manera correcta y continua desde otra cadena.
@BabylonLabs_io #baby $BABY