La primera vez que simulé Babylon TBV, pasé 20 minutos redimensionando dos Bóvedas... y me di cuenta de que había entendido mal el juego desde el principio.
probé 10.000 USD en colateral BTC, con un Factor de Colateral del 78%, pidiendo prestados 7.000 USD.
el Health Factor me dio alrededor de 1,11.
una caída del precio del 15% → el HF se desliza hasta ~0,95 → Estado Liquidable.
¿suena simple, verdad?
no.
el problema real empezó cuando dividí la posición en una Bóveda Sacrificial y una Bóveda Protegida.
una bóveda equivale a un solo UTXO, así que la Indivisibilidad del UTXO convierte la Liquidación en una cuestión de orden de ejecución, no solo del tamaño del colateral.
una sola Bóveda es más fácil de entender, pero se topa con el Acantilado de Liquidación.
la división en dos Bóvedas amortigua el impacto, pero introduce Riesgo de Configuración de Bóveda, Riesgo de Orden de Bóvedas e incluso Riesgo Operacional.
invertí las dos Bóvedas varias veces... un pequeño cambio fue suficiente para alterar la Unidad Mínima de Liquidación, el Monto Objetivo de Secuestro, y qué activos podían reclamarse primero.
honestamente, aquí es donde TBV se vuelve fascinante y desesperante a la vez.
@BabylonLabs_io puede optimizar la interfaz, sugerir Reordenamiento de Bóvedas y calcular el Health Factor Objetivo o la bonificación de Liquidación.
pero el Precio del Oráculo no te pregunta si entendiste el sistema.
la Velocidad del Bot de Liquidación no esperará a que termines tu café.
el Tiempo de Confirmación le importa incluso menos que planeases ajustar una Bóveda cinco minutos después.
el Pago de Equidad puede devolver el Exceso de Secuestro, y lo respeto.
pero la compensación es compensación, el camino de ejecución es el camino de ejecución... no es lo mismo.
lo que quiero vigilar ahora es el Promedio del Ratio de Exceso de Secuestro, el Número de Liquidaciones, el tiempo de liquidación, y qué pasa cuando llegue una verdadera Prueba de Estrés en Mainnet.
porque para mí, el mejor protocolo no es el que mejor oculta la complejidad.
es el que hace que los usuarios entiendan qué parte de sus activos recibe prioridad de ejecución.
si la Liquidación de Posición Parcial no puede existir de forma natural debido a la estructura del UTXO, ¿debería el protocolo absorber esa complejidad... o deberían gestionarla los usuarios?
#baby $BABY @BabylonLabs_io $BEAT $COTI
probé 10.000 USD en colateral BTC, con un Factor de Colateral del 78%, pidiendo prestados 7.000 USD.
el Health Factor me dio alrededor de 1,11.
una caída del precio del 15% → el HF se desliza hasta ~0,95 → Estado Liquidable.
¿suena simple, verdad?
no.
el problema real empezó cuando dividí la posición en una Bóveda Sacrificial y una Bóveda Protegida.
una bóveda equivale a un solo UTXO, así que la Indivisibilidad del UTXO convierte la Liquidación en una cuestión de orden de ejecución, no solo del tamaño del colateral.
una sola Bóveda es más fácil de entender, pero se topa con el Acantilado de Liquidación.
la división en dos Bóvedas amortigua el impacto, pero introduce Riesgo de Configuración de Bóveda, Riesgo de Orden de Bóvedas e incluso Riesgo Operacional.
invertí las dos Bóvedas varias veces... un pequeño cambio fue suficiente para alterar la Unidad Mínima de Liquidación, el Monto Objetivo de Secuestro, y qué activos podían reclamarse primero.
honestamente, aquí es donde TBV se vuelve fascinante y desesperante a la vez.
@BabylonLabs_io puede optimizar la interfaz, sugerir Reordenamiento de Bóvedas y calcular el Health Factor Objetivo o la bonificación de Liquidación.
pero el Precio del Oráculo no te pregunta si entendiste el sistema.
la Velocidad del Bot de Liquidación no esperará a que termines tu café.
el Tiempo de Confirmación le importa incluso menos que planeases ajustar una Bóveda cinco minutos después.
el Pago de Equidad puede devolver el Exceso de Secuestro, y lo respeto.
pero la compensación es compensación, el camino de ejecución es el camino de ejecución... no es lo mismo.
lo que quiero vigilar ahora es el Promedio del Ratio de Exceso de Secuestro, el Número de Liquidaciones, el tiempo de liquidación, y qué pasa cuando llegue una verdadera Prueba de Estrés en Mainnet.
porque para mí, el mejor protocolo no es el que mejor oculta la complejidad.
es el que hace que los usuarios entiendan qué parte de sus activos recibe prioridad de ejecución.
si la Liquidación de Posición Parcial no puede existir de forma natural debido a la estructura del UTXO, ¿debería el protocolo absorber esa complejidad... o deberían gestionarla los usuarios?
#baby $BABY @BabylonLabs_io $BEAT $COTI