Hieu_30
1.6k Publicaciones
Hieu_30
112 Siguiendo
193 Seguidores
1.1K+ Me gusta
Publicaciones
PINNED
Falso "Ya lanzado" Reclamo, dijo que ya lo había lanzado
Un vendedor me dijo, a mitad del pedido, que ya había liberado el cripto y que el retraso debía ser de mi parte, quizá mi billetera estaba lenta, quizá debería simplemente cancelar el pedido y lo resolveríamos por chat después. Durante como un minuto, de verdad lo consideré. Las billeteras a veces se retrasan. Sonaba más molesto que deshonesto, y eso, de alguna manera, lo hizo más convincente.
Entonces recordé lo único que no se retrasa: el estado del pedido. Binance P2P no me pide que crea la palabra de nadie sobre una liberación; me lo muestra. Un reclamo es algo que alguien te dice. Un estado es algo que la plataforma te muestra.
Aun así, no me gusta la fricción de insistir en una prueba cuando alguien suena sincero. Se siente casi descortés decir "Revisaré el pedido, no tu mensaje" a una persona que quizá esté genuinamente frustrada. Pero cancelar con la palabra de un vendedor me quita mi única ventaja: una vez que se cancela un pedido, el depósito en garantía se libera y cualquier reclamo que yo tuviera desaparece con él. No hay cómo resolverlo después.
Así que no cancelé. Revisé yo mismo el estado del pedido, vi que no se había movido nada, y abrí una Apelación en lugar de una conversación privada. Soporte podía ver el mismo pedido que yo, para eso sirve mantenerlo ahí.
Si el cripto de verdad se había liberado y solo estaba retrasado, una Apelación cuesta unos minutos. Si no era así, cancelar habría costado todo.
#binancep2pantoan @Binance Vietnam $TUT $MMT $BLUAI
Un vendedor me dijo, a mitad del pedido, que ya había liberado el cripto y que el retraso debía ser de mi parte, quizá mi billetera estaba lenta, quizá debería simplemente cancelar el pedido y lo resolveríamos por chat después. Durante como un minuto, de verdad lo consideré. Las billeteras a veces se retrasan. Sonaba más molesto que deshonesto, y eso, de alguna manera, lo hizo más convincente.
Entonces recordé lo único que no se retrasa: el estado del pedido. Binance P2P no me pide que crea la palabra de nadie sobre una liberación; me lo muestra. Un reclamo es algo que alguien te dice. Un estado es algo que la plataforma te muestra.
Aun así, no me gusta la fricción de insistir en una prueba cuando alguien suena sincero. Se siente casi descortés decir "Revisaré el pedido, no tu mensaje" a una persona que quizá esté genuinamente frustrada. Pero cancelar con la palabra de un vendedor me quita mi única ventaja: una vez que se cancela un pedido, el depósito en garantía se libera y cualquier reclamo que yo tuviera desaparece con él. No hay cómo resolverlo después.
Así que no cancelé. Revisé yo mismo el estado del pedido, vi que no se había movido nada, y abrí una Apelación en lugar de una conversación privada. Soporte podía ver el mismo pedido que yo, para eso sirve mantenerlo ahí.
Si el cripto de verdad se había liberado y solo estaba retrasado, una Apelación cuesta unos minutos. Si no era así, cancelar habría costado todo.
#binancep2pantoan @Binance Vietnam $TUT $MMT $BLUAI
PINNED
Desliza y sigues pasando por 12 ofertas casi idénticas
Mismo precio, mismo método de pago, el mismo distintivo de "en línea"; un libro de órdenes P2P puede hacer que cada oferta parezca intercambiable, así que la mayoría solo toca la primera. Es un hábito en el que casi todos caen, especialmente cuando esperar se siente como perder.
Pero dos traders que publican la misma tarifa pueden ser, aun así, contrapartes muy diferentes. Lo que las separa tarda unos 30 segundos en comprobarse, y está justo ahí en el perfil.
La tasa de finalización importa más que la cantidad de operaciones. Alguien con 40 órdenes completadas y un 99% de finalización tiene un historial; alguien nuevo no es automáticamente inseguro, pero significa que las otras comprobaciones importan más: cuánto tiempo lleva activo, si su historial coincide con el distintivo que está mostrando.
Luego está el detalle que la gente omite más rápido: el nombre en la cuenta de pago tiene que coincidir con el nombre en la orden, no solo parecerse. Una coincidencia casi exacta, o una solicitud de "envíalo a la cuenta de mi colega en su lugar", vale la pena pausar antes de que ocurra cualquier otra cosa.
Nada de esto reemplaza al Escrow: el cripto se mantiene bloqueado hasta la liberación, de cualquier manera. Pero verificar a la persona del otro lado significa que estás detectando un problema antes de que exista, en vez de depender de Escrow para arreglarlo después.
Si un perfil se ve extraño y no sabes por qué, ya es motivo suficiente para elegir otra oferta o preguntar primero a Soporte de Binance.
#binancep2pantoan @Binance Vietnam $BNB #creatorpad
Mismo precio, mismo método de pago, el mismo distintivo de "en línea"; un libro de órdenes P2P puede hacer que cada oferta parezca intercambiable, así que la mayoría solo toca la primera. Es un hábito en el que casi todos caen, especialmente cuando esperar se siente como perder.
Pero dos traders que publican la misma tarifa pueden ser, aun así, contrapartes muy diferentes. Lo que las separa tarda unos 30 segundos en comprobarse, y está justo ahí en el perfil.
La tasa de finalización importa más que la cantidad de operaciones. Alguien con 40 órdenes completadas y un 99% de finalización tiene un historial; alguien nuevo no es automáticamente inseguro, pero significa que las otras comprobaciones importan más: cuánto tiempo lleva activo, si su historial coincide con el distintivo que está mostrando.
Luego está el detalle que la gente omite más rápido: el nombre en la cuenta de pago tiene que coincidir con el nombre en la orden, no solo parecerse. Una coincidencia casi exacta, o una solicitud de "envíalo a la cuenta de mi colega en su lugar", vale la pena pausar antes de que ocurra cualquier otra cosa.
Nada de esto reemplaza al Escrow: el cripto se mantiene bloqueado hasta la liberación, de cualquier manera. Pero verificar a la persona del otro lado significa que estás detectando un problema antes de que exista, en vez de depender de Escrow para arreglarlo después.
Si un perfil se ve extraño y no sabes por qué, ya es motivo suficiente para elegir otra oferta o preguntar primero a Soporte de Binance.
#binancep2pantoan @Binance Vietnam $BNB #creatorpad
Por qué nunca debes renunciar a operar fuera de la plataforma
Un patrón común en P2P: un contrapartista sugiere pasar a Telegram «para terminar más rápido». Suena inofensivo, pero ese movimiento elimina todas las protecciones integradas en una orden de Binance.
El Escrow solo bloquea la criptomoneda vinculada a una orden creada y completada dentro de Binance. Si los términos reales se finalizan en otro lugar, con un monto distinto, una billetera distinta, o la cuenta de pago de otra persona, Escrow ya no cubre lo que realmente ocurrió, porque no existe una orden correspondiente en Binance.
El chat de la orden funciona igual. Cada mensaje dentro de una orden P2P de Binance está registrado con marca de tiempo y se guarda, y eso es exactamente lo que revisa Soporte durante una Apelación. Una conversación de Telegram o WhatsApp no es visible para Soporte; por muy claros que se vean tus pantallazos, Soporte no puede verificar si son auténticos o si fueron editados. En una disputa, te quedas con afirmaciones en lugar de pruebas.
Esto también vuelve inutilizable la propia Apelación. La Apelación resuelve disputas vinculadas a una orden específica de Binance; si la negociación real ocurrió fuera de la plataforma, no hay datos de orden que coincidan con lo que estás impugnando.
Una regla sencilla: si un contrapartista quiere mover la comunicación o el pago fuera de Binance, tómalo como un motivo para ir más despacio, no para acelerar. Los traders legítimos no tienen necesidad operativa de salir de un sistema que protege por igual a ambas partes.
La conveniencia suele ser la justificación habitual, pero muchas veces significa quitar protección para la otra parte. Mantener una operación completamente dentro de Binance no cuesta nada extra y hace que Escrow, los registros del chat y la Apelación funcionen tal como fueron diseñados.
#binancep2pantoan @Binance Vietnam #creatorpad $BNB
Un patrón común en P2P: un contrapartista sugiere pasar a Telegram «para terminar más rápido». Suena inofensivo, pero ese movimiento elimina todas las protecciones integradas en una orden de Binance.
El Escrow solo bloquea la criptomoneda vinculada a una orden creada y completada dentro de Binance. Si los términos reales se finalizan en otro lugar, con un monto distinto, una billetera distinta, o la cuenta de pago de otra persona, Escrow ya no cubre lo que realmente ocurrió, porque no existe una orden correspondiente en Binance.
El chat de la orden funciona igual. Cada mensaje dentro de una orden P2P de Binance está registrado con marca de tiempo y se guarda, y eso es exactamente lo que revisa Soporte durante una Apelación. Una conversación de Telegram o WhatsApp no es visible para Soporte; por muy claros que se vean tus pantallazos, Soporte no puede verificar si son auténticos o si fueron editados. En una disputa, te quedas con afirmaciones en lugar de pruebas.
Esto también vuelve inutilizable la propia Apelación. La Apelación resuelve disputas vinculadas a una orden específica de Binance; si la negociación real ocurrió fuera de la plataforma, no hay datos de orden que coincidan con lo que estás impugnando.
Una regla sencilla: si un contrapartista quiere mover la comunicación o el pago fuera de Binance, tómalo como un motivo para ir más despacio, no para acelerar. Los traders legítimos no tienen necesidad operativa de salir de un sistema que protege por igual a ambas partes.
La conveniencia suele ser la justificación habitual, pero muchas veces significa quitar protección para la otra parte. Mantener una operación completamente dentro de Binance no cuesta nada extra y hace que Escrow, los registros del chat y la Apelación funcionen tal como fueron diseñados.
#binancep2pantoan @Binance Vietnam #creatorpad $BNB
La parte más valiosa de Babylon no es el préstamo.
Es la espera.
Eso probablemente suena al revés hasta que sigues realmente el flujo de redención.
Cuando un Trustless Bitcoin Vault se redime, Bitcoin no libera el colateral inmediatamente. Hay que generar, verificar una prueba criptográfica y, luego, una ventana de desafío de aproximadamente tres días les da tiempo a los participantes para impugnar una reclamación inválida antes de que se mueva cualquier BTC.
Al principio pensé que esos tres días se sentirían como una fricción innecesaria.
En cambio, cambiaron por completo la forma en que miré el sistema.
El retraso no está ahí porque el protocolo sea lento.
Está ahí porque la certeza requiere tiempo.
Mientras exploraba la documentación, también noté otro detalle que no recibe tanta atención. Si un Vault Provider alguna vez deja de estar disponible, el depositante no queda atrapado esperando para siempre. Ya se prepara una ruta de recuperación por auto-reclamación durante la creación del vault, lo que permite al propietario recuperar BTC de forma independiente.
Esa filosofía aparece en todo el diseño.
Los mecanismos de respaldo no son parches de emergencia añadidos más tarde.
Son parte de la arquitectura desde el día uno.
Hoy, Babylon ya asegura más de 56,000 BTC mediante Bitcoin Staking mientras amplía ese modelo de seguridad hacia el préstamo nativo respaldado por Bitcoin con Trustless Bitcoin Vaults y Aave v4.
Después de pasar tiempo tanto con la documentación como con el flujo del testnet, llegué a una conclusión sencilla.
La mayoría de los protocolos compiten por mover activos más rápido.
Babylon parece estar más interesado en asegurarse de que los activos se muevan solo cuando corresponde.
La velocidad crea conveniencia.
La certeza crea confianza.
Para Bitcoin, creo que Babylon eligió bien.
Por eso @BabylonLabs_io has se ha convertido en uno de los proyectos de infraestructura que de verdad me entusiasma seguir observando.
#baby $BABY
Es la espera.
Eso probablemente suena al revés hasta que sigues realmente el flujo de redención.
Cuando un Trustless Bitcoin Vault se redime, Bitcoin no libera el colateral inmediatamente. Hay que generar, verificar una prueba criptográfica y, luego, una ventana de desafío de aproximadamente tres días les da tiempo a los participantes para impugnar una reclamación inválida antes de que se mueva cualquier BTC.
Al principio pensé que esos tres días se sentirían como una fricción innecesaria.
En cambio, cambiaron por completo la forma en que miré el sistema.
El retraso no está ahí porque el protocolo sea lento.
Está ahí porque la certeza requiere tiempo.
Mientras exploraba la documentación, también noté otro detalle que no recibe tanta atención. Si un Vault Provider alguna vez deja de estar disponible, el depositante no queda atrapado esperando para siempre. Ya se prepara una ruta de recuperación por auto-reclamación durante la creación del vault, lo que permite al propietario recuperar BTC de forma independiente.
Esa filosofía aparece en todo el diseño.
Los mecanismos de respaldo no son parches de emergencia añadidos más tarde.
Son parte de la arquitectura desde el día uno.
Hoy, Babylon ya asegura más de 56,000 BTC mediante Bitcoin Staking mientras amplía ese modelo de seguridad hacia el préstamo nativo respaldado por Bitcoin con Trustless Bitcoin Vaults y Aave v4.
Después de pasar tiempo tanto con la documentación como con el flujo del testnet, llegué a una conclusión sencilla.
La mayoría de los protocolos compiten por mover activos más rápido.
Babylon parece estar más interesado en asegurarse de que los activos se muevan solo cuando corresponde.
La velocidad crea conveniencia.
La certeza crea confianza.
Para Bitcoin, creo que Babylon eligió bien.
Por eso @BabylonLabs_io has se ha convertido en uno de los proyectos de infraestructura que de verdad me entusiasma seguir observando.
#baby $BABY
El diseño más seguro no siempre es el que se siente más seguro.
Esa idea se quedó conmigo mientras leía el proceso de redención de Babylon.
La mayoría de las personas se centra en lo que ocurre cuando el BTC se bloquea.
A mí me pareció más interesante la salida.
Redimir una bóveda no es instantáneo. Incluso después de que se produzca un evento de redención válido en Ethereum, Bitcoin no libera el BTC de inmediato.
Una ventana de desafío le da tiempo a otros participantes para impugnar una reclamación inválida antes de que los fondos se muevan.
Esperar tres días suena ineficiente si todo lo que mides es la velocidad.
Pero la seguridad rara vez premia la impaciencia.
Las finanzas tradicionales a menudo cierran operaciones lentamente porque las instituciones se interponen entre cada paso.
Babylon ralentiza las cosas por un motivo diferente.
El retraso no le pide a los usuarios que confíen en otro intermediario.
Es darle tiempo al protocolo para demostrar que no se coló ninguna redención inválida.
Esa distinción parece importante.
Dos sistemas pueden tener el mismo tiempo de espera mientras se basan en supuestos completamente distintos.
Uno retrasa porque la gente necesita aprobar.
El otro retrasa porque las matemáticas necesitan tiempo para ser impugnadas.
Si los usuarios aceptan esa compensación sigue siendo una pregunta abierta.
Cripto ha pasado años compitiendo para ver quién puede hacer que todo ocurra más rápido.
Babylon, en silencio, está preguntando si algunas cosas deberían suceder con más cuidado en lugar de con más prisa.
#baby $BABY @BabylonLabs_io
Esa idea se quedó conmigo mientras leía el proceso de redención de Babylon.
La mayoría de las personas se centra en lo que ocurre cuando el BTC se bloquea.
A mí me pareció más interesante la salida.
Redimir una bóveda no es instantáneo. Incluso después de que se produzca un evento de redención válido en Ethereum, Bitcoin no libera el BTC de inmediato.
Una ventana de desafío le da tiempo a otros participantes para impugnar una reclamación inválida antes de que los fondos se muevan.
Esperar tres días suena ineficiente si todo lo que mides es la velocidad.
Pero la seguridad rara vez premia la impaciencia.
Las finanzas tradicionales a menudo cierran operaciones lentamente porque las instituciones se interponen entre cada paso.
Babylon ralentiza las cosas por un motivo diferente.
El retraso no le pide a los usuarios que confíen en otro intermediario.
Es darle tiempo al protocolo para demostrar que no se coló ninguna redención inválida.
Esa distinción parece importante.
Dos sistemas pueden tener el mismo tiempo de espera mientras se basan en supuestos completamente distintos.
Uno retrasa porque la gente necesita aprobar.
El otro retrasa porque las matemáticas necesitan tiempo para ser impugnadas.
Si los usuarios aceptan esa compensación sigue siendo una pregunta abierta.
Cripto ha pasado años compitiendo para ver quién puede hacer que todo ocurra más rápido.
Babylon, en silencio, está preguntando si algunas cosas deberían suceder con más cuidado en lugar de con más prisa.
#baby $BABY @BabylonLabs_io
Con verificación
Enterrado dentro de las propias suposiciones de seguridad de @BabylonLabs_io hay una línea que se lee muy distinto una vez que te sientas con ella: todo el sistema de puntos de control anclados en Bitcoin requiere "al menos un presentador vigilante honesto" para estar en línea, y eso se enumera como una suposición, no como algo que el protocolo haga cumplir.
El resto de las suposiciones de esa lista necesita una mayoría honesta: la profundidad de confirmación de Bitcoin, el propio conjunto de validadores de Babylon, los conjuntos de validadores de las cadenas conectadas. Las mayorías son difíciles de corromper porque necesitas que la mayor parte de una multitud se vuelva mala al mismo tiempo. La suposición del presentador es distinta en su naturaleza. Solo necesita una instancia honesta en cualquier lugar, lo que suena como el listón más bajo posible para cumplir, y en cierto sentido lo es. Pero también significa que toda la cadena de la seguridad anclada en Bitcoin, la parte que hace que reescribir la historia sea económicamente irracional, depende de si incluso una sola copia de un programa demonio específico se está operando honestamente en cualquier momento dado.
Ejecutarlo es sin permiso: cualquiera puede hacerlo, pero nada de lo que he encontrado describe una recompensa dedicada por hacerlo más allá de una dirección opcional para reclamar incentivos futuros que aún no están activos. El presentador también paga, de su propio bolsillo, tarifas reales de transacciones de Bitcoin cada vez que envía.
Sigo dándome vueltas sobre si el listón de una sola parte honesta es resistente porque es tan fácil de superar, o si es una dependencia más silenciosa que el comité del pacto, dado que al menos la falla del comité sería visible. Si alguna vez la presentación de puntos de control se detuviera de manera silenciosa, ¿lo notarías incluso antes de que afectara tu propio stake?
#baby $BABY
El resto de las suposiciones de esa lista necesita una mayoría honesta: la profundidad de confirmación de Bitcoin, el propio conjunto de validadores de Babylon, los conjuntos de validadores de las cadenas conectadas. Las mayorías son difíciles de corromper porque necesitas que la mayor parte de una multitud se vuelva mala al mismo tiempo. La suposición del presentador es distinta en su naturaleza. Solo necesita una instancia honesta en cualquier lugar, lo que suena como el listón más bajo posible para cumplir, y en cierto sentido lo es. Pero también significa que toda la cadena de la seguridad anclada en Bitcoin, la parte que hace que reescribir la historia sea económicamente irracional, depende de si incluso una sola copia de un programa demonio específico se está operando honestamente en cualquier momento dado.
Ejecutarlo es sin permiso: cualquiera puede hacerlo, pero nada de lo que he encontrado describe una recompensa dedicada por hacerlo más allá de una dirección opcional para reclamar incentivos futuros que aún no están activos. El presentador también paga, de su propio bolsillo, tarifas reales de transacciones de Bitcoin cada vez que envía.
Sigo dándome vueltas sobre si el listón de una sola parte honesta es resistente porque es tan fácil de superar, o si es una dependencia más silenciosa que el comité del pacto, dado que al menos la falla del comité sería visible. Si alguna vez la presentación de puntos de control se detuviera de manera silenciosa, ¿lo notarías incluso antes de que afectara tu propio stake?
#baby $BABY
El endeudamiento a tipo fijo suena como la opción más segura hasta que recuerdas por qué existen los tipos flotantes en primer lugar.
Aegis está construyendo préstamos a tipo fijo sobre Trustless Bitcoin Vaults de @BabylonLabs_io , con una salida prevista para más tarde este año. Así, se fija un tipo en lugar de dejar que se mueva con la utilización, como ya hace el mercado de préstamos de Aave v4 en exactamente esos mismos vaults. El atractivo es evidente: sabes tu coste de antemano, sin subidas repentinas del tipo en medio de la posición. Lo que se comenta menos es qué ocurre cuando la demanda cambia de verdad. Los tipos flotantes existen específicamente para atraer liquidez hacia donde más se necesita en tiempo real. Un tipo fijo no puede hacer eso; simplemente se queda en el número que se estableció.
Eso no es exactamente un fallo: es un intercambio que Aegis elige a propósito, previsibilidad frente a capacidad de respuesta, funcionando en paralelo al modelo flotante de Aave v4 sobre los mismos vaults subyacentes, en lugar de reemplazarlo. Dos apuestas distintas sobre el mismo colateral, viviendo a la vez.
La previsibilidad en mercados tranquilos y la previsibilidad durante una crisis de liquidez son dos promesas muy diferentes, y solo una de ellas se ha probado realmente en DeFi, con tipo fijo o no.
Me gusta saber mi tipo con antelación. ¿Aun así elegirías fijo si el fondo flotante de al lado empezara a pagar en silencio más apenas las cosas se pusieran tensas?
#baby $BABY
Aegis está construyendo préstamos a tipo fijo sobre Trustless Bitcoin Vaults de @BabylonLabs_io , con una salida prevista para más tarde este año. Así, se fija un tipo en lugar de dejar que se mueva con la utilización, como ya hace el mercado de préstamos de Aave v4 en exactamente esos mismos vaults. El atractivo es evidente: sabes tu coste de antemano, sin subidas repentinas del tipo en medio de la posición. Lo que se comenta menos es qué ocurre cuando la demanda cambia de verdad. Los tipos flotantes existen específicamente para atraer liquidez hacia donde más se necesita en tiempo real. Un tipo fijo no puede hacer eso; simplemente se queda en el número que se estableció.
Eso no es exactamente un fallo: es un intercambio que Aegis elige a propósito, previsibilidad frente a capacidad de respuesta, funcionando en paralelo al modelo flotante de Aave v4 sobre los mismos vaults subyacentes, en lugar de reemplazarlo. Dos apuestas distintas sobre el mismo colateral, viviendo a la vez.
La previsibilidad en mercados tranquilos y la previsibilidad durante una crisis de liquidez son dos promesas muy diferentes, y solo una de ellas se ha probado realmente en DeFi, con tipo fijo o no.
Me gusta saber mi tipo con antelación. ¿Aun así elegirías fijo si el fondo flotante de al lado empezara a pagar en silencio más apenas las cosas se pusieran tensas?
#baby $BABY
El endeudamiento en Aave v4 fue lo primero que captó mi atención con Trustless Bitcoin Vaults del @BabylonLabs_io , pero cuanto más tiempo paso con este diseño, más pienso que el préstamo es solo el movimiento inicial, no el techo.
Una vez que el BTC nativo pueda estar como colateral verificable sin salir de Bitcoin, el mismo primitivo deja de ser específico para un caso de uso. Una bóveda no sabe ni le importa si la aplicación que lee su estado es un mercado de préstamos, un emisor de stablecoins, una mesa de derivados que necesita margen o un producto de seguros que requiere capital comprometido. Solo sabe que hay BTC bloqueado bajo condiciones que se fijaron el momento en que se creó la bóveda.
Eso es lo que hace que esto se sienta más grande que un único producto para mí. Aegis ya está construyendo préstamos a tasa fija sobre las mismas vías que usa Aave v4. GoMining está canalizando el capital prestado hacia un rendimiento de minería a través de la misma estructura de bóveda. Ninguno de los dos necesitó un modelo de custodia nuevo por su cuenta: simplemente se conectaron con el que Babylon ya construyó.
Creo que esta es la apuesta real aquí: no una app imprescindible, sino que Bitcoin se vuelva un colateral programable sobre el que cualquier producto financiero serio pueda construir, sin pedir nunca a los titulares de BTC que renuncien a aquello por lo que llegaron a Bitcoin en primer lugar.
#baby $BABY @BabylonLabs_io
Una vez que el BTC nativo pueda estar como colateral verificable sin salir de Bitcoin, el mismo primitivo deja de ser específico para un caso de uso. Una bóveda no sabe ni le importa si la aplicación que lee su estado es un mercado de préstamos, un emisor de stablecoins, una mesa de derivados que necesita margen o un producto de seguros que requiere capital comprometido. Solo sabe que hay BTC bloqueado bajo condiciones que se fijaron el momento en que se creó la bóveda.
Eso es lo que hace que esto se sienta más grande que un único producto para mí. Aegis ya está construyendo préstamos a tasa fija sobre las mismas vías que usa Aave v4. GoMining está canalizando el capital prestado hacia un rendimiento de minería a través de la misma estructura de bóveda. Ninguno de los dos necesitó un modelo de custodia nuevo por su cuenta: simplemente se conectaron con el que Babylon ya construyó.
Creo que esta es la apuesta real aquí: no una app imprescindible, sino que Bitcoin se vuelva un colateral programable sobre el que cualquier producto financiero serio pueda construir, sin pedir nunca a los titulares de BTC que renuncien a aquello por lo que llegaron a Bitcoin en primer lugar.
#baby $BABY @BabylonLabs_io
Ver traducción
I read the isolation rule in Babylon's vault design as a security feature first, one weak app can't drag a vault meant for a different app down with it. Going through the team's own quarterly call, the reasoning behind it turned out to be more specific than I expected.
They were asked directly whether one vault could route to multiple DeFi protocols at once. The answer was no, and the stated reason wasn't capacity or engineering effort, it was that a single vault carrying different liquidation rules and different trust assumptions from multiple apps at the same time was something they didn't want to build, on purpose.
That reframes the boundary as a deliberate refusal, not just a current limitation waiting for a future upgrade. It also means the tradeoff is permanent by design, not a temporary gap someone will close later.
The part I keep sitting with is what this looks like once Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io actually integrate with more than one or two applications. Every new app means a fresh vault, a fresh peg-in, a fresh slice of BTC that cannot follow you if that app's risk profile changes later. Isolation protects you from someone else's failure. It does not protect you from wanting to leave.
Whether that becomes a minor cost of doing this safely or a real drag on capital efficiency probably depends on how many apps actually show up to integrate, and that is something no one can answer yet.
#baby $BABY @BabylonLabs_io
They were asked directly whether one vault could route to multiple DeFi protocols at once. The answer was no, and the stated reason wasn't capacity or engineering effort, it was that a single vault carrying different liquidation rules and different trust assumptions from multiple apps at the same time was something they didn't want to build, on purpose.
That reframes the boundary as a deliberate refusal, not just a current limitation waiting for a future upgrade. It also means the tradeoff is permanent by design, not a temporary gap someone will close later.
The part I keep sitting with is what this looks like once Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io actually integrate with more than one or two applications. Every new app means a fresh vault, a fresh peg-in, a fresh slice of BTC that cannot follow you if that app's risk profile changes later. Isolation protects you from someone else's failure. It does not protect you from wanting to leave.
Whether that becomes a minor cost of doing this safely or a real drag on capital efficiency probably depends on how many apps actually show up to integrate, and that is something no one can answer yet.
#baby $BABY @BabylonLabs_io
Un detalle sobre los Vaults de Bitcoin sin confianza (Trustless) cambió la forma en que pienso sobre el colateral de Bitcoin.
Un vault no es una cuenta.
Es un único UTXO de Bitcoin.
Al principio, eso me pareció una limitación.
¿Por qué no dividir el colateral cada vez que lo necesites?
Luego me di cuenta de que TBV respeta cómo funciona realmente Bitcoin en lugar de fingir que Bitcoin se comporta como una cadena basada en cuentas.
Esa decisión crea un intercambio (trade-off) interesante.
Como un vault no se puede dividir, la liquidación no puede incautar “la mitad” de tu colateral.
O bien se lleva un vault completo, o se deja intacto.
Por eso Babylon recomienda dividir el BTC en varios vaults desde el principio, incluyendo un vault sacrificial más pequeño colocado primero en el orden de liquidación.
Me pareció sorprendentemente elegante.
En lugar de cambiar el modelo contable de Bitcoin, el protocolo adapta su propio diseño a la estructura nativa de Bitcoin.
Es una diferencia sutil, pero importante.
Muchos protocolos intentan forzar a Bitcoin en sistemas diseñados originalmente para otras blockchains.
TBV parece partir de la suposición contraria:
Aceptar primero las limitaciones de Bitcoin.
Luego construir nuevas mecánicas a partir de ellas.
Queda por ver si este enfoque se convierte en el estándar.
Pero creo que los protocolos que respetan las propiedades del activo sobre el que están construidos suelen tener más probabilidades de durar que los que intentan remodelar el activo mismo.
Me pregunto si los futuros proyectos de Bitcoin DeFi seguirán esta filosofía, o si continuarán intentando hacer que Bitcoin se comporte como algo para lo que nunca fue diseñado.
#baby $BABY @BabylonLabs_io
Un vault no es una cuenta.
Es un único UTXO de Bitcoin.
Al principio, eso me pareció una limitación.
¿Por qué no dividir el colateral cada vez que lo necesites?
Luego me di cuenta de que TBV respeta cómo funciona realmente Bitcoin en lugar de fingir que Bitcoin se comporta como una cadena basada en cuentas.
Esa decisión crea un intercambio (trade-off) interesante.
Como un vault no se puede dividir, la liquidación no puede incautar “la mitad” de tu colateral.
O bien se lleva un vault completo, o se deja intacto.
Por eso Babylon recomienda dividir el BTC en varios vaults desde el principio, incluyendo un vault sacrificial más pequeño colocado primero en el orden de liquidación.
Me pareció sorprendentemente elegante.
En lugar de cambiar el modelo contable de Bitcoin, el protocolo adapta su propio diseño a la estructura nativa de Bitcoin.
Es una diferencia sutil, pero importante.
Muchos protocolos intentan forzar a Bitcoin en sistemas diseñados originalmente para otras blockchains.
TBV parece partir de la suposición contraria:
Aceptar primero las limitaciones de Bitcoin.
Luego construir nuevas mecánicas a partir de ellas.
Queda por ver si este enfoque se convierte en el estándar.
Pero creo que los protocolos que respetan las propiedades del activo sobre el que están construidos suelen tener más probabilidades de durar que los que intentan remodelar el activo mismo.
Me pregunto si los futuros proyectos de Bitcoin DeFi seguirán esta filosofía, o si continuarán intentando hacer que Bitcoin se comporte como algo para lo que nunca fue diseñado.
#baby $BABY @BabylonLabs_io
Asumí que Babylon solo necesitaba comprobar Bitcoin en el momento en que ocurriera algo importante: confirmar una apuesta, verificar un checkpoint y luego seguir adelante. Leer el módulo del Cliente Ligero de BTC cambió esa imagen.
Genesis de Babylon mantiene su propia visión continuamente actualizada de la cadena de Bitcoin. Parte de un encabezado base elegido lo bastante profundo como para considerarse final y ubicado exactamente en un límite de ajuste de dificultad; luego se extiende desde ahí aplicando las propias reglas de prueba de trabajo de Bitcoin mediante un mensaje llamado MsgInsertHeaders. Los Reporteros Vigilantes transportan los encabezados, pero no tienen la facultad de decidir qué cuenta como verdadero. Si aparecen ramas en competencia, Genesis simplemente sigue aquella que tenga más trabajo acumulado detrás, la misma regla que usa el propio Bitcoin.
Eso es un tipo distinto de confianza que la de comprobar una única prueba de inclusión y seguir adelante. @BabylonLabs_io no está pidiendo a un operador que confirme si ocurrió un evento de Bitcoin. Está verificando ese evento contra una cadena de encabezados que ha estado construyendo y comprobando por sí mismo todo el tiempo.
El costo es que Genesis ahora tiene un trabajo en curso en lugar de una verificación única. Si los reporteros se atrasan o si una reorg de Bitcoin vuelve a reordenar bloques recientes, Genesis tiene que detectarlo y mantenerse preciso a través de ello, no solo verificar correctamente cada vez que alguien pregunte.
Todavía no tengo una buena idea de cómo se comporta eso durante una reorg real o en un periodo de informes degradados, solo que la regla para resolverlo, seguir el trabajo más acumulado, es lo bastante simple como para confiar en ella sobre el papel.
#baby $BABY
Genesis de Babylon mantiene su propia visión continuamente actualizada de la cadena de Bitcoin. Parte de un encabezado base elegido lo bastante profundo como para considerarse final y ubicado exactamente en un límite de ajuste de dificultad; luego se extiende desde ahí aplicando las propias reglas de prueba de trabajo de Bitcoin mediante un mensaje llamado MsgInsertHeaders. Los Reporteros Vigilantes transportan los encabezados, pero no tienen la facultad de decidir qué cuenta como verdadero. Si aparecen ramas en competencia, Genesis simplemente sigue aquella que tenga más trabajo acumulado detrás, la misma regla que usa el propio Bitcoin.
Eso es un tipo distinto de confianza que la de comprobar una única prueba de inclusión y seguir adelante. @BabylonLabs_io no está pidiendo a un operador que confirme si ocurrió un evento de Bitcoin. Está verificando ese evento contra una cadena de encabezados que ha estado construyendo y comprobando por sí mismo todo el tiempo.
El costo es que Genesis ahora tiene un trabajo en curso en lugar de una verificación única. Si los reporteros se atrasan o si una reorg de Bitcoin vuelve a reordenar bloques recientes, Genesis tiene que detectarlo y mantenerse preciso a través de ello, no solo verificar correctamente cada vez que alguien pregunte.
Todavía no tengo una buena idea de cómo se comporta eso durante una reorg real o en un periodo de informes degradados, solo que la regla para resolverlo, seguir el trabajo más acumulado, es lo bastante simple como para confiar en ella sobre el papel.
#baby $BABY
Con verificación
Esperaba que el paso de pre-firma durante la configuración de la bóveda cubriera los casos obvios: repago, liquidación, quizá redención. Lo que no esperaba era que el caso de fallo ya estuviera firmado también, antes de que se moviera siquiera un solo satoshi.
Configurando una bóveda para Trustless Bitcoin Vaults (TBV) desde @BabylonLabs_io , el BTC permanece temporalmente en una salida de Pre-PegIn mientras llegan las confirmaciones de Bitcoin. Durante esa ventana exacta, antes incluso de que la bóveda se haya activado, ya estás firmando la transacción de reembolso que te permite recuperar tu BTC si el peg-in nunca se completa. No es una promesa de construir una más adelante si algo se rompe. Es una ruta de gasto ya firmada que queda ahí, sin uso, esperando un escenario que en la mayoría de los casos nunca ocurre.
Eso me sorprendió más que las rutas de liquidación y redención, honestamente, porque esas parecían ser las partes de las que todo el mundo habla.
La ruta de reembolso es la que nadie menciona, y está firmada en el mismo momento que todo lo demás, bajo la misma lógica de pre-compromiso; nada se improvisa después, incluido el “salida” para cuando las cosas van mal antes incluso de que vayan bien.
Replantea lo que significa realmente la pre-firma aquí. No es solo fijar cómo se comporta una bóveda saludable. También es fijar cómo se comporta el fallo, en un punto en el que el fallo no ha ocurrido y quizá nunca ocurra.
Aún no tengo una respuesta clara sobre qué sucede si la configuración de firma propia de un depositante se descompone durante esa misma ventana, antes de que existan aún cualquiera de estas rutas pre-firmadas. La documentación cubre lo que pasa después de que se construye el grafo. Lo que pasa si algo falla antes de ese punto me queda menos claro.
#baby $BABY
Configurando una bóveda para Trustless Bitcoin Vaults (TBV) desde @BabylonLabs_io , el BTC permanece temporalmente en una salida de Pre-PegIn mientras llegan las confirmaciones de Bitcoin. Durante esa ventana exacta, antes incluso de que la bóveda se haya activado, ya estás firmando la transacción de reembolso que te permite recuperar tu BTC si el peg-in nunca se completa. No es una promesa de construir una más adelante si algo se rompe. Es una ruta de gasto ya firmada que queda ahí, sin uso, esperando un escenario que en la mayoría de los casos nunca ocurre.
Eso me sorprendió más que las rutas de liquidación y redención, honestamente, porque esas parecían ser las partes de las que todo el mundo habla.
La ruta de reembolso es la que nadie menciona, y está firmada en el mismo momento que todo lo demás, bajo la misma lógica de pre-compromiso; nada se improvisa después, incluido el “salida” para cuando las cosas van mal antes incluso de que vayan bien.
Replantea lo que significa realmente la pre-firma aquí. No es solo fijar cómo se comporta una bóveda saludable. También es fijar cómo se comporta el fallo, en un punto en el que el fallo no ha ocurrido y quizá nunca ocurra.
Aún no tengo una respuesta clara sobre qué sucede si la configuración de firma propia de un depositante se descompone durante esa misma ventana, antes de que existan aún cualquiera de estas rutas pre-firmadas. La documentación cubre lo que pasa después de que se construye el grafo. Lo que pasa si algo falla antes de ese punto me queda menos claro.
#baby $BABY
¿Quién tiene el poder para detener tu retiro?
¿Quién tiene el poder para tomarlo en su lugar?
La mayoría de los sistemas responde ambas preguntas de la misma manera. Quien pueda congelar tus fondos normalmente también puede moverlos.
Los Bóvedas de Bitcoin sin confianza (TBV) de @BabylonLabs_io las responden de manera distinta.
Un Consejo de Seguridad está integrado en el diseño como un respaldo de emergencia.
Puede bloquear un pago.
Puede activar una pausa.
Puede intervenir en la recuperación cuando algo ha salido mal.
Lo que no puede hacer importa más.
No puede mover tu BTC.
No puede cambiar a dónde va.
No puede extraer fondos hacia ningún monedero, incluido el propio.
Puede detener.
No puede dirigir.
Incluso un consejo totalmente comprometido no tiene una vía hacia tu Bitcoin.
Solo una puerta que puede mantener cerrada.
Ese poder tampoco está destinado a durar para siempre. El diseño apunta a reducirlo a medida que el sistema madura, aunque nadie ha fijado la fecha en que ocurrirá.
La mayoría de las personas miden la seguridad por cuáco poco poder existe alrededor de sus activos.
Quizá la mejor medida sea qué forma se le permite tomar a ese poder.
Un consejo que solo puede decir que no no es lo mismo que un consejo que también puede decir dónde.
#baby $BABY
¿Quién tiene el poder para tomarlo en su lugar?
La mayoría de los sistemas responde ambas preguntas de la misma manera. Quien pueda congelar tus fondos normalmente también puede moverlos.
Los Bóvedas de Bitcoin sin confianza (TBV) de @BabylonLabs_io las responden de manera distinta.
Un Consejo de Seguridad está integrado en el diseño como un respaldo de emergencia.
Puede bloquear un pago.
Puede activar una pausa.
Puede intervenir en la recuperación cuando algo ha salido mal.
Lo que no puede hacer importa más.
No puede mover tu BTC.
No puede cambiar a dónde va.
No puede extraer fondos hacia ningún monedero, incluido el propio.
Puede detener.
No puede dirigir.
Incluso un consejo totalmente comprometido no tiene una vía hacia tu Bitcoin.
Solo una puerta que puede mantener cerrada.
Ese poder tampoco está destinado a durar para siempre. El diseño apunta a reducirlo a medida que el sistema madura, aunque nadie ha fijado la fecha en que ocurrirá.
La mayoría de las personas miden la seguridad por cuáco poco poder existe alrededor de sus activos.
Quizá la mejor medida sea qué forma se le permite tomar a ese poder.
Un consejo que solo puede decir que no no es lo mismo que un consejo que también puede decir dónde.
#baby $BABY
A mitad de configurar una bóveda en la testnet de Babylon, la interfaz me pidió que eligiera un Proveedor de Bóveda antes de que pudiera continuar, y mi primera intuición fue la misma que tengo para cualquier exchange centralizado: ¿qué le pasa a mi BTC una vez que se la entrego?
Esa intuición resultó estar equivocada para las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io , pero entender por qué requirió más que simplemente avanzar a través de la pantalla de selección. Un Proveedor de Bóveda coordina el peg-in, recopila las firmas necesarias para construir el grafo de la transacción, genera la prueba de conocimiento cero en el momento del rescate y difunde, en tu nombre, las transacciones de reclamación y de pago. También cobra una pequeña comisión por hacer ese trabajo. Ninguna de esas acciones requiere custodia. El BTC queda en una salida Taproot cuyas rutas de gasto ya estaban fijadas y firmadas antes de que el proveedor haga cualquier cosa, así que no hay un paso en el que ellos estén reteniendo fondos que simplemente puedan abandonar.
Lo que en realidad se parece más a su función es un relay en lugar de un custodio: mueve mensajes y pruebas entre Bitcoin y Ethereum en vez de mover el activo en sí.
Sin embargo, la dependencia no desaparece por completo. Si un Proveedor de Bóveda se desconecta, vuelves a la autogestión del reclamo usando el material de recuperación que se supone que debías guardar al crear la bóveda, y esa ruta existe específicamente porque no se garantiza el tiempo de actividad del proveedor.
También existe un rol separado llamado Application Vault Keeper, ejecutado por la aplicación que hayas elegido, y en testnet sinceramente no pude determinar solo con la interfaz dónde termina el trabajo de un Proveedor de Bóveda y dónde empieza el de un Keeper. Ambos están en esa capa de coordinación fuera de cadena: ninguno custodia nada, y la línea entre ellos solo quedó clara después de que volví a leer la documentación por segunda vez.
Lo que aún no tengo una buena respuesta es cómo se supone que un depositante debe elegir proveedores en primer lugar. La documentación explica lo que el rol puede y no puede hacer, pero no cómo se evalúa la fiabilidad o la reputación antes de bloquear tu BTC con uno de ellos.
#baby $BABY
Esa intuición resultó estar equivocada para las Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io , pero entender por qué requirió más que simplemente avanzar a través de la pantalla de selección. Un Proveedor de Bóveda coordina el peg-in, recopila las firmas necesarias para construir el grafo de la transacción, genera la prueba de conocimiento cero en el momento del rescate y difunde, en tu nombre, las transacciones de reclamación y de pago. También cobra una pequeña comisión por hacer ese trabajo. Ninguna de esas acciones requiere custodia. El BTC queda en una salida Taproot cuyas rutas de gasto ya estaban fijadas y firmadas antes de que el proveedor haga cualquier cosa, así que no hay un paso en el que ellos estén reteniendo fondos que simplemente puedan abandonar.
Lo que en realidad se parece más a su función es un relay en lugar de un custodio: mueve mensajes y pruebas entre Bitcoin y Ethereum en vez de mover el activo en sí.
Sin embargo, la dependencia no desaparece por completo. Si un Proveedor de Bóveda se desconecta, vuelves a la autogestión del reclamo usando el material de recuperación que se supone que debías guardar al crear la bóveda, y esa ruta existe específicamente porque no se garantiza el tiempo de actividad del proveedor.
También existe un rol separado llamado Application Vault Keeper, ejecutado por la aplicación que hayas elegido, y en testnet sinceramente no pude determinar solo con la interfaz dónde termina el trabajo de un Proveedor de Bóveda y dónde empieza el de un Keeper. Ambos están en esa capa de coordinación fuera de cadena: ninguno custodia nada, y la línea entre ellos solo quedó clara después de que volví a leer la documentación por segunda vez.
Lo que aún no tengo una buena respuesta es cómo se supone que un depositante debe elegir proveedores en primer lugar. La documentación explica lo que el rol puede y no puede hacer, pero no cómo se evalúa la fiabilidad o la reputación antes de bloquear tu BTC con uno de ellos.
#baby $BABY
Inicialmente asumí que la parte más difícil de los Bóvedas Bitcoin sin Confianza (TBV, por sus siglas en inglés) era bloquear BTC nativo en Bitcoin mientras se usaba como garantía en Ethereum.
Después de leer con más profundidad, me di cuenta de que el problema más difícil parece estar en la salida.
Bloquear Bitcoin dentro de un script Taproot predefinido es solo el comienzo. El verdadero desafío es demostrarle a Bitcoin que el evento de redención correcto ocurrió en Ethereum antes de que se libere el BTC.
Bitcoin no puede simplemente leer el estado de Ethereum.
Y confiar en un operador de puente para anunciar que la deuda fue saldada o que una liquidación fue válida recrearía el mismo riesgo intermediario que TBV está diseñado para evitar.
Babylon aborda esto mediante un proceso de desafío basado en BABE.
Cuando una bóveda entra en redención, se genera una prueba de conocimiento cero para demostrar que ocurrió el evento correspondiente en Ethereum. Luego, se envía una reclamación en Bitcoin, seguida de un período de desafío durante el cual se pueden impugnar las reclamaciones inválidas.
Solo después de que ese proceso se complete, la ruta de pago previamente firmada puede liberar el BTC al destino fijo establecido cuando se creó la bóveda.
Ese período de espera puede parecer una UX ineficiente.
Pero en realidad es donde el modelo de confianza se vuelve visible.
Un servicio centralizado puede redimir más rápido porque los usuarios confían en que mantendrá el BTC y respetará los retiros. TBV acepta más latencia porque la liberación de Bitcoin está condicionada por evidencia criptográfica y un proceso de disputa, no por la promesa de un operador.
Para mí, esta es la parte que hace que el diseño valga la pena estudiarlo.
La pregunta difícil no es si el BTC nativo puede aparecer como garantía dentro de una aplicación DeFi.
La pregunta es si Bitcoin puede imponer la salida final sin un custodio, una federación de puentes o una bifurcación de Bitcoin.
TBV está intentando resolver exactamente eso.
El depósito crea la oportunidad.
La redención demuestra si el sistema realmente está minimizado en confianza.
Por eso veo el período de desafío no como un simple detalle técnico, sino como una de las partes más importantes del diseño de @BabylonLabs_io .
#baby $BABY
Después de leer con más profundidad, me di cuenta de que el problema más difícil parece estar en la salida.
Bloquear Bitcoin dentro de un script Taproot predefinido es solo el comienzo. El verdadero desafío es demostrarle a Bitcoin que el evento de redención correcto ocurrió en Ethereum antes de que se libere el BTC.
Bitcoin no puede simplemente leer el estado de Ethereum.
Y confiar en un operador de puente para anunciar que la deuda fue saldada o que una liquidación fue válida recrearía el mismo riesgo intermediario que TBV está diseñado para evitar.
Babylon aborda esto mediante un proceso de desafío basado en BABE.
Cuando una bóveda entra en redención, se genera una prueba de conocimiento cero para demostrar que ocurrió el evento correspondiente en Ethereum. Luego, se envía una reclamación en Bitcoin, seguida de un período de desafío durante el cual se pueden impugnar las reclamaciones inválidas.
Solo después de que ese proceso se complete, la ruta de pago previamente firmada puede liberar el BTC al destino fijo establecido cuando se creó la bóveda.
Ese período de espera puede parecer una UX ineficiente.
Pero en realidad es donde el modelo de confianza se vuelve visible.
Un servicio centralizado puede redimir más rápido porque los usuarios confían en que mantendrá el BTC y respetará los retiros. TBV acepta más latencia porque la liberación de Bitcoin está condicionada por evidencia criptográfica y un proceso de disputa, no por la promesa de un operador.
Para mí, esta es la parte que hace que el diseño valga la pena estudiarlo.
La pregunta difícil no es si el BTC nativo puede aparecer como garantía dentro de una aplicación DeFi.
La pregunta es si Bitcoin puede imponer la salida final sin un custodio, una federación de puentes o una bifurcación de Bitcoin.
TBV está intentando resolver exactamente eso.
El depósito crea la oportunidad.
La redención demuestra si el sistema realmente está minimizado en confianza.
Por eso veo el período de desafío no como un simple detalle técnico, sino como una de las partes más importantes del diseño de @BabylonLabs_io .
#baby $BABY
vaultBTC tiene “BTC” en su nombre, así que inicialmente asumí que era otra versión envuelta de Bitcoin.
Después de leer cómo funcionan las Trustless Bitcoin Vaults (TBV), me di cuenta de que esa suposición pasa por alto todo el diseño.
Bitcoin envuelto normalmente sigue un modelo conocido: el BTC nativo se coloca bajo el control de un custodio o un puente, y luego se emite un token transferible en otra cadena. El token se mueve por DeFi, mientras que los usuarios dependen de una vía de redención externa de vuelta al BTC original.
vaultBTC no funciona de esa manera.
El BTC nativo permanece bloqueado en una bóveda Taproot en la Red de Bitcoin. Cuando esa bóveda se activa para la integración de Aave v4, el adaptador crea vaultBTC solo como un registro contable interno para que el mercado crediticio pueda reconocer el valor de la garantía.
No se envía a la billetera del usuario.
No se puede transferir a direcciones arbitrarias.
No tiene mercado secundario.
Y se quema cuando se retira la bóveda o se liquida.
Esa distinción importa porque la representación contable nunca intenta convertirse en un sustituto de Bitcoin. No circula de forma independiente, no crea un mercado separado, ni pide a los usuarios que traten un token en Ethereum como si fuera el BTC subyacente.
El activo y el registro permanecen separados.
Bitcoin se queda en Bitcoin, donde sus rutas de gasto se hacen cumplir por el script Taproot acordado en la creación de la bóveda. Ethereum solo recibe la capa contable necesaria para pedir prestado, pagar, comprobaciones de health-factor y la liquidación.
Para mí, esta es una de las ideas más claras del diseño de Babylon.
La mayoría de los sistemas entre cadenas mueven el activo primero y explican las suposiciones de confianza después.
TBV parte de la pregunta opuesta: ¿Cómo puede una aplicación usar Bitcoin como garantía sin convertir Bitcoin en otra cosa?
La respuesta no es otro activo envuelto.
Bitcoin sigue siendo la garantía.
vaultBTC sigue siendo el lenguaje contable que la aplicación usa para entenderlo.
#baby $BABY @BabylonLabs_io
Después de leer cómo funcionan las Trustless Bitcoin Vaults (TBV), me di cuenta de que esa suposición pasa por alto todo el diseño.
Bitcoin envuelto normalmente sigue un modelo conocido: el BTC nativo se coloca bajo el control de un custodio o un puente, y luego se emite un token transferible en otra cadena. El token se mueve por DeFi, mientras que los usuarios dependen de una vía de redención externa de vuelta al BTC original.
vaultBTC no funciona de esa manera.
El BTC nativo permanece bloqueado en una bóveda Taproot en la Red de Bitcoin. Cuando esa bóveda se activa para la integración de Aave v4, el adaptador crea vaultBTC solo como un registro contable interno para que el mercado crediticio pueda reconocer el valor de la garantía.
No se envía a la billetera del usuario.
No se puede transferir a direcciones arbitrarias.
No tiene mercado secundario.
Y se quema cuando se retira la bóveda o se liquida.
Esa distinción importa porque la representación contable nunca intenta convertirse en un sustituto de Bitcoin. No circula de forma independiente, no crea un mercado separado, ni pide a los usuarios que traten un token en Ethereum como si fuera el BTC subyacente.
El activo y el registro permanecen separados.
Bitcoin se queda en Bitcoin, donde sus rutas de gasto se hacen cumplir por el script Taproot acordado en la creación de la bóveda. Ethereum solo recibe la capa contable necesaria para pedir prestado, pagar, comprobaciones de health-factor y la liquidación.
Para mí, esta es una de las ideas más claras del diseño de Babylon.
La mayoría de los sistemas entre cadenas mueven el activo primero y explican las suposiciones de confianza después.
TBV parte de la pregunta opuesta: ¿Cómo puede una aplicación usar Bitcoin como garantía sin convertir Bitcoin en otra cosa?
La respuesta no es otro activo envuelto.
Bitcoin sigue siendo la garantía.
vaultBTC sigue siendo el lenguaje contable que la aplicación usa para entenderlo.
#baby $BABY @BabylonLabs_io
Parcialmente cierto
Lo que me llamó la atención sobre los Trustless Bitcoin Vaults (TBV) no es simplemente que permiten que Bitcoin entre en DeFi. Es que la actividad de préstamo puede moverse a Ethereum mientras el BTC subyacente no se mueve.
En la mayoría de los modelos de DeFi de Bitcoin, el activo tiene que transformarse antes de volverse útil. El BTC se deposita con un custodio, se mueve a través de un puente o se representa como un token envuelto en otra cadena. Eso crea liquidez, pero también cambia el modelo de confianza. El usuario ya no se basa solo en Bitcoin. Depende de una entidad emisora, un puente, un conjunto de signatarios o un proceso de redención.
TBV toma una ruta diferente. El BTC nativo permanece bloqueado dentro de un script de Taproot en la red de Bitcoin. En Ethereum, el protocolo hace seguimiento de la bóveda y permite que una aplicación integrada como Aave v4 reconozca ese BTC bloqueado como colateral.
Esta separación importa porque Ethereum se encarga de la lógica de préstamo, mientras que Bitcoin sigue manteniendo el activo en sí.
El usuario puede pedir prestados activos compatibles a través de la capa de aplicación, pero el BTC no se transfiere a una billetera de Ethereum, no se deposita con un custodio ni se convierte en un token envuelto libremente negociable. El colateral permanece donde las propias reglas de consenso de Bitcoin pueden hacer cumplir las rutas de gasto que se acordaron cuando se creó la bóveda.
Para mí, ese es el cambio de diseño real.
TBV no intenta hacer que Bitcoin sea útil moviéndolo a otro lugar. Intenta hacer que Bitcoin sea útil preservando su entorno nativo de liquidación.
Aún hay compensaciones. El peg-in requiere confirmaciones de Bitcoin, la redención tarda más porque existe el proceso de prueba y de desafío, y siguen existiendo riesgos a nivel de aplicación como contratos inteligentes, oráculos, factores de salud y la liquidación.
Pero esos son riesgos distintos a entregar la custodia del BTC original.
Por eso, el enfoque de @BabylonLabs_io es interesante: la actividad DeFi puede ocurrir entre cadenas, mientras que el colateral central permanece nativo de Bitcoin.
#baby $BABY
En la mayoría de los modelos de DeFi de Bitcoin, el activo tiene que transformarse antes de volverse útil. El BTC se deposita con un custodio, se mueve a través de un puente o se representa como un token envuelto en otra cadena. Eso crea liquidez, pero también cambia el modelo de confianza. El usuario ya no se basa solo en Bitcoin. Depende de una entidad emisora, un puente, un conjunto de signatarios o un proceso de redención.
TBV toma una ruta diferente. El BTC nativo permanece bloqueado dentro de un script de Taproot en la red de Bitcoin. En Ethereum, el protocolo hace seguimiento de la bóveda y permite que una aplicación integrada como Aave v4 reconozca ese BTC bloqueado como colateral.
Esta separación importa porque Ethereum se encarga de la lógica de préstamo, mientras que Bitcoin sigue manteniendo el activo en sí.
El usuario puede pedir prestados activos compatibles a través de la capa de aplicación, pero el BTC no se transfiere a una billetera de Ethereum, no se deposita con un custodio ni se convierte en un token envuelto libremente negociable. El colateral permanece donde las propias reglas de consenso de Bitcoin pueden hacer cumplir las rutas de gasto que se acordaron cuando se creó la bóveda.
Para mí, ese es el cambio de diseño real.
TBV no intenta hacer que Bitcoin sea útil moviéndolo a otro lugar. Intenta hacer que Bitcoin sea útil preservando su entorno nativo de liquidación.
Aún hay compensaciones. El peg-in requiere confirmaciones de Bitcoin, la redención tarda más porque existe el proceso de prueba y de desafío, y siguen existiendo riesgos a nivel de aplicación como contratos inteligentes, oráculos, factores de salud y la liquidación.
Pero esos son riesgos distintos a entregar la custodia del BTC original.
Por eso, el enfoque de @BabylonLabs_io es interesante: la actividad DeFi puede ocurrir entre cadenas, mientras que el colateral central permanece nativo de Bitcoin.
#baby $BABY
La advertencia de phishing de MetaMask ha estado diciéndoles a los usuarios que no procedan durante años. Aun así, la gente hace clic y pasa por encima, con la frecuencia suficiente como para que la advertencia prácticamente deje de registrar como tal: solo una pantalla roja entre ellos y aquello que ya habían decidido hacer.
Ese es el modo de falla integrado en cada sistema de advertencia y permitir el paso. Una advertencia solo funciona en alguien que ya iba a detenerse. Cualquiera que ya hubiera decidido simplemente la ignora y pasa. Y después de suficientes repeticiones, el clic se vuelve reflejo.
Una política que bloquea de forma contundente en lugar de advertir elimina esa opción en el momento en que importa, lo cual suena contundente hasta que te das cuenta de que la advertencia nunca fue realmente una opción para la mayoría de las personas: solo era fricción que habían aprendido a ignorar.
Las comprobaciones de la política de Newton se reducen a atestación o nada: si falla, no se realiza la transacción. No es una pantalla roja que alguien pueda pasar por alto. Es un tipo de seguridad más acotado que un sistema que intenta informar a cada posible usuario. También es el tipo que no depende de que alguien realmente lea la advertencia.
Si una advertencia solo detiene a la persona que ya iba a detenerse, ¿estaba protegiendo a alguien más?
#newt $NEWT @NewtonProtocol
Ese es el modo de falla integrado en cada sistema de advertencia y permitir el paso. Una advertencia solo funciona en alguien que ya iba a detenerse. Cualquiera que ya hubiera decidido simplemente la ignora y pasa. Y después de suficientes repeticiones, el clic se vuelve reflejo.
Una política que bloquea de forma contundente en lugar de advertir elimina esa opción en el momento en que importa, lo cual suena contundente hasta que te das cuenta de que la advertencia nunca fue realmente una opción para la mayoría de las personas: solo era fricción que habían aprendido a ignorar.
Las comprobaciones de la política de Newton se reducen a atestación o nada: si falla, no se realiza la transacción. No es una pantalla roja que alguien pueda pasar por alto. Es un tipo de seguridad más acotado que un sistema que intenta informar a cada posible usuario. También es el tipo que no depende de que alguien realmente lea la advertencia.
Si una advertencia solo detiene a la persona que ya iba a detenerse, ¿estaba protegiendo a alguien más?
#newt $NEWT @NewtonProtocol
Inicia sesión para explorar más contenidos