Una sola BTC, de principio a fin, no se salió de Bitcoin; sin embargo, Aave pudo tomarla como garantía para prestar. Más contradictorio aún: en el medio no hubo ninguna “BTC fantasma” que se pudiera comerciar.
Revisé de principio a fin la integración de Aave v4 en @BabylonLabs_io y descubrí que el Adapter se comporta más como un traductor que domina dos idiomas. En el peg-in, el BTC nativo entra en el Taproot Vault de Bitcoin; al activarse, el AaveAdapter despliega para el usuario un Position Proxy, crea un registro interno de garantía 1:1, preciso hasta el satoshi, según la cantidad de BTC, y luego lo suministra al Babylon Core Spoke.
Este registro utiliza una interfaz estilo ERC-20, solo para que Aave pueda entender el colateral. No entra en la cartera del usuario, no se puede transferir a direcciones normales y tampoco existe un mercado secundario. El BTC real sigue en el mismo UTXO original; en el lado de Ethereum, únicamente se registra cuánto colateral de ese Vault respalda cada posición.
Las órdenes de préstamo entran desde el Adapter al Proxy y al Core Spoke, y luego extraen los activos desde el Hub de Aave v4; el reembolso vuelve en sentido inverso al Hub. En la red de pruebas pública actual, el USDC, el USDT y el WBTC son monedas de simulación sin valor real. Después de poner a cero la deuda, el usuario retira el Vault: el registro de garantía se cierra, y el lado de Bitcoin inicia la provisión de pruebas, el desafío y el Payout.
Así que no es “mover” la BTC a Aave, sino hacer que dos libros contables concilien alrededor del mismo estado de la garantía. Aave no puede tocar el BTC nativo, pero la ruta agrega Adapter, Proxy, Spoke y oráculos. La criptografía protege la salida de BTC; si los préstamos son correctos o no, todavía depende de los contratos de aplicación y de los parámetros de control de riesgos.
Tras el despliegue en la red principal, lo más importante que se debe verificar no es solo si se puede prestar dinero, sino si este “traductor” cometería un error al traducir una frase clave en situaciones de alta concurrencia y condiciones de mercado extremas.
#baby $BABY
Revisé de principio a fin la integración de Aave v4 en @BabylonLabs_io y descubrí que el Adapter se comporta más como un traductor que domina dos idiomas. En el peg-in, el BTC nativo entra en el Taproot Vault de Bitcoin; al activarse, el AaveAdapter despliega para el usuario un Position Proxy, crea un registro interno de garantía 1:1, preciso hasta el satoshi, según la cantidad de BTC, y luego lo suministra al Babylon Core Spoke.
Este registro utiliza una interfaz estilo ERC-20, solo para que Aave pueda entender el colateral. No entra en la cartera del usuario, no se puede transferir a direcciones normales y tampoco existe un mercado secundario. El BTC real sigue en el mismo UTXO original; en el lado de Ethereum, únicamente se registra cuánto colateral de ese Vault respalda cada posición.
Las órdenes de préstamo entran desde el Adapter al Proxy y al Core Spoke, y luego extraen los activos desde el Hub de Aave v4; el reembolso vuelve en sentido inverso al Hub. En la red de pruebas pública actual, el USDC, el USDT y el WBTC son monedas de simulación sin valor real. Después de poner a cero la deuda, el usuario retira el Vault: el registro de garantía se cierra, y el lado de Bitcoin inicia la provisión de pruebas, el desafío y el Payout.
Así que no es “mover” la BTC a Aave, sino hacer que dos libros contables concilien alrededor del mismo estado de la garantía. Aave no puede tocar el BTC nativo, pero la ruta agrega Adapter, Proxy, Spoke y oráculos. La criptografía protege la salida de BTC; si los préstamos son correctos o no, todavía depende de los contratos de aplicación y de los parámetros de control de riesgos.
Tras el despliegue en la red principal, lo más importante que se debe verificar no es solo si se puede prestar dinero, sino si este “traductor” cometería un error al traducir una frase clave en situaciones de alta concurrencia y condiciones de mercado extremas.
#baby $BABY
