La primera vez que aposté BTC nativa en Aave v4 dentro de la red de pruebas y luego pedí prestados activos de prueba, estuve todo el tiempo pendiente del factor de salud. Me equivocaba pensando que, mientras no tocara la línea de liquidación, esa posición era segura. Solo cuando avancé hasta el reembolso y el rescate, descubrí que solo había entendido la mitad.

En los @BabylonLabs_io Trustless Bitcoin Vaults (TBV), en realidad hay varias “manecillas” funcionando al mismo tiempo: en el lado de Aave se vigila si la posición ahora mismo está en situación de insolvencia; la ventana de prueba y desafío debe confirmar que los estados de préstamos, reembolsos y liquidaciones no se hayan falsificado; el orden de confirmación de Bitcoin, en cambio, es el que fija los resultados ya ocurridos. La primera capa evita hacer cualquier “desorden” en el momento; la segunda evita que luego se den vuelta los hechos. No es algo que se solucione simplemente apalancando más activos.

Esto también explica por qué los TBV resultan más atractivos para mí que el BTC envuelto o los préstamos con custodia. Las soluciones tradicionales suelen requerir que primero entregues $BTC y luego confiar en el libro mayor de custodia o en pruebas de saldo de activos entre cadenas; en los TBV no se mueve el UTXO nativo: en lugar de eso, usan condiciones de gasto predefinidas y pruebas criptográficas para responder: en este momento, ¿quién puede gastar este BTC y en qué estado?

$ETH

Pero la red de pruebas también dejó al descubierto un problema muy práctico: durante la espera, si la página solo muestra “procesando”, el usuario no sabe si está esperando la confirmación de Bitcoin, la generación de la prueba, o si está en plena fase de desafío. Recomiendo mostrar por separado los tres pasos, el tiempo restante y el riesgo correspondiente. Si no, aunque técnicamente esté todo perfectamente segmentado, para el usuario sigue pareciendo un solo “mismo caldo”.

$BABY #baby

Si usas BTC nativa como colateral para préstamos, ¿qué es lo que más te importa?