En estos años, mientras auditaba distintos códigos de bajo nivel, he visto demasiadas funciones de pause (pausar) y unpause (reanudar). Y en el código de contratos de TermMax V2 también se mantienen estos dos interfaces de alto riesgo. Desde la perspectiva del equipo, la intención seguramente es buena: si se sufre un ataque de hackers o una vulnerabilidad catastrófica del contrato, el administrador puede pulsar el botón de pausa de inmediato para congelar todas las transacciones y así preservar los activos del pool.
Pero para un protocolo de préstamos que se centra en “plazo fijo (FT)” y en “salida en cualquier momento (Smart Unwind)”, en realidad es una contradicción lógica mortal. Los productos de tipo de interés fijo exigen una liquidez y una ventana temporal extremadamente estrictas. Imagina este escenario: cuando el mercado macro cae en picada, tu posición está al borde de la liquidación y quieres añadir colateral antes de la liquidación forzosa, o aprovechar el mecanismo de Smart Unwind para retirar fondos con descuento a tiempo y cortar pérdidas. Justo en ese momento, el administrador percibe que el sistema en su conjunto tiene riesgo y llama directamente a la interfaz de pause. Entonces tu dinero queda instantáneamente bloqueado de forma forzada dentro del contrato y cualquier operación on-chain se revierte.
Cuando la tormenta pasa, el precio de los activos ya se ha desplomado en picada. El administrador llama a unpause para reanudar las operaciones. En ese punto, tu ratio de colateral ya ha caído por debajo del umbral; apenas se restablecen las operaciones, los robots de liquidación te liquidan al instante. Durante todo este proceso, no cometiste ningún error operativo. Solo por una acción defensiva del administrador, te ves obligado a asumir todas las consecuencias de la liquidación.
Mi criterio: se puede entender conservar la autoridad de pausa de emergencia, pero esa espada jamás puede pender sobre la cabeza de los traders sin límites. El equipo debe codificar de forma explícita a nivel de código: ¿durante la pausa se puede activar una exención de liquidación? Si el sistema queda bloqueado por fuerza y los usuarios no pueden añadir colateral, ¿quién asumirá las pérdidas después de que se desbloquee? Convertir la liquidez del usuario en un colchón de amortiguación gratuito para que el sistema se cubra contra el riesgo es un tipo de transferencia de riesgo absolutamente inaceptable para mí. #termmax @TermMax $BTC
Pero para un protocolo de préstamos que se centra en “plazo fijo (FT)” y en “salida en cualquier momento (Smart Unwind)”, en realidad es una contradicción lógica mortal. Los productos de tipo de interés fijo exigen una liquidez y una ventana temporal extremadamente estrictas. Imagina este escenario: cuando el mercado macro cae en picada, tu posición está al borde de la liquidación y quieres añadir colateral antes de la liquidación forzosa, o aprovechar el mecanismo de Smart Unwind para retirar fondos con descuento a tiempo y cortar pérdidas. Justo en ese momento, el administrador percibe que el sistema en su conjunto tiene riesgo y llama directamente a la interfaz de pause. Entonces tu dinero queda instantáneamente bloqueado de forma forzada dentro del contrato y cualquier operación on-chain se revierte.
Cuando la tormenta pasa, el precio de los activos ya se ha desplomado en picada. El administrador llama a unpause para reanudar las operaciones. En ese punto, tu ratio de colateral ya ha caído por debajo del umbral; apenas se restablecen las operaciones, los robots de liquidación te liquidan al instante. Durante todo este proceso, no cometiste ningún error operativo. Solo por una acción defensiva del administrador, te ves obligado a asumir todas las consecuencias de la liquidación.
Mi criterio: se puede entender conservar la autoridad de pausa de emergencia, pero esa espada jamás puede pender sobre la cabeza de los traders sin límites. El equipo debe codificar de forma explícita a nivel de código: ¿durante la pausa se puede activar una exención de liquidación? Si el sistema queda bloqueado por fuerza y los usuarios no pueden añadir colateral, ¿quién asumirá las pérdidas después de que se desbloquee? Convertir la liquidez del usuario en un colchón de amortiguación gratuito para que el sistema se cubra contra el riesgo es un tipo de transferencia de riesgo absolutamente inaceptable para mí. #termmax @TermMax $BTC