Puse juntos la página de seguridad, el repositorio de auditorías y las explicaciones de permisos del @TermMax y vi que “auditado” en realidad es solo la capa más externa. Lo que realmente determina cómo reacciona el sistema cuando algo sale mal es qué contratos pueden modificarse, quién puede pausar y cómo se controla de forma conjunta el acceso a permisos críticos. #TermMax
En el repositorio público actualmente aparecen informes por fases de ABDK, el informe de TMX y el informe del concurso Cantina; además, Immunefi también tiene recompensas por vulnerabilidades que aún siguen en funcionamiento. Los documentos también mencionan un monitoreo on-chain durante 24 horas y un mecanismo de pausas automáticas. Esta información muestra que el proyecto aplica defensas en múltiples capas, pero lo que resuelven es detectar problemas y acortar el tiempo de respuesta; no significa que los contratos, a partir de ahí, ya nunca tendrán problemas.
Al desglosar aún más la capa de permisos, TermMax asigna acciones administrativas clave a una multisig 4-de-6, aísla entre mercados, y los parámetros de Vault cuentan con contrapesos mediante timelock y Guardian. Al mismo tiempo, la entidad oficial también deja claro que conserva la capacidad de parada de emergencia, y que algunos componentes se implementan con opciones actualizables. En otras palabras, este sistema no garantiza la seguridad porque “nadie pueda administrar nada”, sino porque limita el riesgo de un único punto de fallo mediante el aislamiento, la latencia, la autorización conjunta de varias personas y acciones de contingencia.
Sobre el aislamiento entre mercados, eso lo anotaré por separado. Que un mercado se despliegue de manera independiente no significa que necesariamente no ocurran pérdidas; lo que expresa es que el límite de fallo se intenta que no se propague a otros mercados. El diseño de seguridad muchas veces no elimina el riesgo: primero reduce el alcance en el que un error podría afectar.
Más bien siento que esto es más digno de mirarlo que la frase “el código es la ley”, porque cuando DeFi realmente se enfrenta a una anomalía, siempre hay que responder dos preguntas concretas: ¿los permisos alcanzan para actuar con suficiente rapidez?, ¿y el límite de impacto es lo bastante estrecho? Si es demasiado lento, quizá no llegue para detenerlo; si es demasiado amplio, entonces la gobernanza misma se convertirá en una fuente de riesgo.
Por eso, más adelante seguiré de cerca si cambia la composición de la multisig, el alcance de los componentes actualizables, los eventos de pausa y el historial de parches tras la auditoría. El informe de auditoría prueba que alguien se tomó en serio la búsqueda de problemas, y el rastro de permisos me dirá cómo maneja el sistema los problemas en la realidad.
En el repositorio público actualmente aparecen informes por fases de ABDK, el informe de TMX y el informe del concurso Cantina; además, Immunefi también tiene recompensas por vulnerabilidades que aún siguen en funcionamiento. Los documentos también mencionan un monitoreo on-chain durante 24 horas y un mecanismo de pausas automáticas. Esta información muestra que el proyecto aplica defensas en múltiples capas, pero lo que resuelven es detectar problemas y acortar el tiempo de respuesta; no significa que los contratos, a partir de ahí, ya nunca tendrán problemas.
Al desglosar aún más la capa de permisos, TermMax asigna acciones administrativas clave a una multisig 4-de-6, aísla entre mercados, y los parámetros de Vault cuentan con contrapesos mediante timelock y Guardian. Al mismo tiempo, la entidad oficial también deja claro que conserva la capacidad de parada de emergencia, y que algunos componentes se implementan con opciones actualizables. En otras palabras, este sistema no garantiza la seguridad porque “nadie pueda administrar nada”, sino porque limita el riesgo de un único punto de fallo mediante el aislamiento, la latencia, la autorización conjunta de varias personas y acciones de contingencia.
Sobre el aislamiento entre mercados, eso lo anotaré por separado. Que un mercado se despliegue de manera independiente no significa que necesariamente no ocurran pérdidas; lo que expresa es que el límite de fallo se intenta que no se propague a otros mercados. El diseño de seguridad muchas veces no elimina el riesgo: primero reduce el alcance en el que un error podría afectar.
Más bien siento que esto es más digno de mirarlo que la frase “el código es la ley”, porque cuando DeFi realmente se enfrenta a una anomalía, siempre hay que responder dos preguntas concretas: ¿los permisos alcanzan para actuar con suficiente rapidez?, ¿y el límite de impacto es lo bastante estrecho? Si es demasiado lento, quizá no llegue para detenerlo; si es demasiado amplio, entonces la gobernanza misma se convertirá en una fuente de riesgo.
Por eso, más adelante seguiré de cerca si cambia la composición de la multisig, el alcance de los componentes actualizables, los eventos de pausa y el historial de parches tras la auditoría. El informe de auditoría prueba que alguien se tomó en serio la búsqueda de problemas, y el rastro de permisos me dirá cómo maneja el sistema los problemas en la realidad.