Los robots de liquidación no tienen tijeras: solo se llevan cajas enteras. Al ver que la red de pruebas actual con el @BabylonLabs_io convierte cada Vault en un UTXO independiente, recién entonces entendí esto: el doble Vault no es una opción de depósito bonita, sino una forma de desmenuzar las pérdidas de la liquidación.
En el DeFi común, los colaterales se pueden cortar proporcionalmente, pero en las transacciones de Bitcoin solo se puede gastar un output completo. Supongamos que en la posición hay 0.4 BTC; la liquidación solo tendría que gestionar aproximadamente 0.25 BTC. Pero si esos 0.4 BTC están metidos por completo en un solo Vault, el protocolo no puede recortar 0.25: solo puede incluir el Vault entero en la liquidación. El valor “sobrante” no desaparece por arte de magia: el mecanismo de equidad primero reducirá la deuda restante del usuario, y si aún hay saldo, lo devolverá en WBTC. Pero “recibir una compensación equivalente” y “que el BTC nativo siga en tu propio Vault” no son lo mismo.
Ahí es donde el doble Vault realmente es útil. Con los parámetros actuales de la red de pruebas pública, el factor de colateral es 78% y el factor de salud objetivo es 1.24. Según la estimación del documento, cuando la posición apenas se activa para la liquidación, la cantidad objetivo que se lleva equivale a ~62% del valor en BTC. Portal, con parámetros en tiempo real, coloca primero el Vault de sacrificio (el más grande) y deja el resto de los BTC en el Vault de protección. El proceso de liquidación revisa las torres desde la parte superior de la lista: cuando la primera basta, se detiene; si no, la segunda continúa quedando en la posición.
Por eso no es un “superpoder anti-liquidación”, sino más bien una puerta estanca en el barco: el accidente seguirá causando pérdidas, solo que se intenta evitar que la pérdida se coma todo el barco. Si la volatilidad baja demasiado rápido, el tamaño del Vault de sacrificio es insuficiente o el orden se coloca mal, el sistema aún puede seguir llevándose el siguiente Vault; el 62/38 tampoco es una fórmula permanente: tras cualquier cambio de parámetros, debes volver a revisar el desglose que te entregue Portal.
Yo preferiría llamar a este diseño “gestión de la granularidad de las pérdidas”. Lo que el prestatario realmente tiene que vigilar, además del factor de salud, es el tamaño de su Vault y el orden en que están dispuestos. ¿Aceptarías una gestión de posición más compleja para poder proteger el segundo Vault de BTC nativo?
#baby $BABY
En el DeFi común, los colaterales se pueden cortar proporcionalmente, pero en las transacciones de Bitcoin solo se puede gastar un output completo. Supongamos que en la posición hay 0.4 BTC; la liquidación solo tendría que gestionar aproximadamente 0.25 BTC. Pero si esos 0.4 BTC están metidos por completo en un solo Vault, el protocolo no puede recortar 0.25: solo puede incluir el Vault entero en la liquidación. El valor “sobrante” no desaparece por arte de magia: el mecanismo de equidad primero reducirá la deuda restante del usuario, y si aún hay saldo, lo devolverá en WBTC. Pero “recibir una compensación equivalente” y “que el BTC nativo siga en tu propio Vault” no son lo mismo.
Ahí es donde el doble Vault realmente es útil. Con los parámetros actuales de la red de pruebas pública, el factor de colateral es 78% y el factor de salud objetivo es 1.24. Según la estimación del documento, cuando la posición apenas se activa para la liquidación, la cantidad objetivo que se lleva equivale a ~62% del valor en BTC. Portal, con parámetros en tiempo real, coloca primero el Vault de sacrificio (el más grande) y deja el resto de los BTC en el Vault de protección. El proceso de liquidación revisa las torres desde la parte superior de la lista: cuando la primera basta, se detiene; si no, la segunda continúa quedando en la posición.
Por eso no es un “superpoder anti-liquidación”, sino más bien una puerta estanca en el barco: el accidente seguirá causando pérdidas, solo que se intenta evitar que la pérdida se coma todo el barco. Si la volatilidad baja demasiado rápido, el tamaño del Vault de sacrificio es insuficiente o el orden se coloca mal, el sistema aún puede seguir llevándose el siguiente Vault; el 62/38 tampoco es una fórmula permanente: tras cualquier cambio de parámetros, debes volver a revisar el desglose que te entregue Portal.
Yo preferiría llamar a este diseño “gestión de la granularidad de las pérdidas”. Lo que el prestatario realmente tiene que vigilar, además del factor de salud, es el tamaño de su Vault y el orden en que están dispuestos. ¿Aceptarías una gestión de posición más compleja para poder proteger el segundo Vault de BTC nativo?
#baby $BABY
