Guía de seguridad DeFi: ¿Cómo defenderse eficazmente de los ataques de hackers en la era de la IA?

Escribir artículo: sysls

Compilación: AididiaoJP, Foresight News

Enlace al original:

Declaración: Este artículo es una reproducción, los lectores pueden obtener más información a través del enlace original. Si el autor tiene alguna objeción respecto a la reproducción, por favor contáctenos, haremos las modificaciones según su solicitud. La reproducción es solo para compartir información, no constituye ningún consejo de inversión, ni representa la opinión o postura de Wu.

Introducción

Al entender numerosos eventos de hackeos en protocolos DeFi, me ha generado temor hacia los «actores estatales». Son expertos en tecnología, con recursos abundantes, y juegan un juego de largo plazo; estos supervillanos se enfocan en revisar cada rincón de tus protocolos e infraestructura en busca de vulnerabilidades, mientras que los equipos de protocolos comunes están distraídos en seis o siete direcciones de negocio diferentes.

No me considero un experto en seguridad, pero he liderado equipos en ambientes de alto riesgo (incluyendo fuerzas armadas y finanzas con fondos elevados), y tengo experiencia en pensar y planear planes de contingencia.

Creo sinceramente que solo los paranoicos sobreviven. Ningún equipo empieza pensando «voy a actuar con despreocupación y negligencia respecto a la seguridad»; sin embargo, los hackeos aún ocurren. Necesitamos hacerlo mejor.

La IA significa que esta vez realmente es diferente

(Fuente de datos:

Los hackeos no son raros, pero claramente están en aumento. El primer trimestre de 2026 fue el trimestre con mayor cantidad de hackeos en DeFi registrados, y aunque el segundo trimestre acaba de comenzar, ya se espera que rompa el récord del trimestre anterior.

Mi hipótesis central es: la IA ha reducido drásticamente el costo de encontrar vulnerabilidades y ha expandido enormemente la superficie de ataque. La humanidad necesita varias semanas para revisar la configuración de cien protocolos en busca de errores; en cambio, los modelos básicos más recientes pueden hacerlo en unas pocas horas.

Esto debería cambiar radicalmente nuestra forma de pensar y responder a los hackeos. Los protocolos antiguos que confiaban en medidas de seguridad antes de que la IA se volviera poderosa, enfrentan cada vez más el riesgo de ser «eliminados en un segundo».

Pensando en superficie y jerarquías

(Fuente de datos:

La superficie de ataque en realidad puede reducirse a tres: el equipo del protocolo, los contratos inteligentes y la infraestructura, y los límites de confianza de los usuarios (DSN, redes sociales, etc.).

Una vez identificadas estas superficies, se superponen capas de defensa:

Prevención: si se implementa estrictamente, puede minimizar la probabilidad de explotación de vulnerabilidades.

Mitigación: cuando la prevención falla, limita la magnitud del daño.

Pausa: nadie puede tomar decisiones óptimas bajo una gran presión. Una vez confirmado un ataque, se activa inmediatamente la «llave de apagado». Congelar puede detener pérdidas adicionales y dar espacio para pensar…

Recuperación: si pierdes control sobre componentes tóxicos o comprometidos, debes descartarlos y reemplazarlos.

Restauración: recupéralo todo lo que perdiste. Planea con anticipación cómo contactar socios que puedan congelar fondos, revertir transacciones y ayudar en investigaciones.

Principios

Estos principios guían las acciones concretas para implementar cada capa de defensa.

Uso intensivo de IA de vanguardia

Utiliza modelos de IA de última generación para escanear tu código y configuración en busca de vulnerabilidades, y realiza pruebas de red en superficie amplia: intenta encontrar fallos en el frontend para ver si pueden llegar al backend. Los atacantes hacen esto. Lo que puedas detectar con defensas y escaneos preventivos, ellos ya lo habrán detectado con escaneos ofensivos.

Usa plataformas de IA como pashov, nemesis, así como Cantina (Apex) y Zellic (V12), para escanear rápidamente tu código antes de una auditoría completa.

El tiempo y la fricción son buenas defensas

Agrega pasos adicionales y bloqueos temporales a cualquier operación que pueda causar daño. Necesitas suficiente tiempo para intervenir y congelar cuando detectes anomalías.

Antes, se oponía a los bloqueos temporales y pasos múltiples la idea de que generaban fricción para el equipo del protocolo. Ahora, no te preocupes demasiado: la IA puede gestionar fácilmente estos pasos en segundo plano.

Invariantes

Los contratos inteligentes pueden construirse defensivamente escribiendo «hechos» inmutables: si estos hechos se rompen, toda la lógica del protocolo colapsa.

Normalmente solo tienes unos pocos invariantes. Debes elevar cuidadosamente estos invariantes al código; forzar múltiples invariantes en cada función se vuelve difícil de gestionar.

Balance de poder

Muchas vulnerabilidades provienen de wallets comprometidos. Necesitas una configuración que, incluso si una firma múltiple se ve comprometida, pueda rápidamente limitar el daño y devolver el protocolo a un estado gobernable.

Esto requiere un equilibrio entre Gobernanza (que decide todo) y Rescate (que restaura la estabilidad gobernable, pero no puede reemplazar o anular la gobernanza).

Siempre habrá problemas

Desde el principio, debes asumir: por muy inteligente que seas, serás hackeado. Tus contratos o dependencias pueden fallar. Podrías ser víctima de ingeniería social, y las nuevas actualizaciones pueden introducir vulnerabilidades imprevistas.

Pensando así, los limitadores de daño y los interruptores de bloqueo del protocolo serán tus mejores amigos. Limita el daño a un 5-10%, congela y planifica tu respuesta. Nadie puede tomar decisiones óptimas en medio del fuego cruzado.

El mejor momento para planear es ahora

Antes de ser hackeado, piensa en tu respuesta. Codifica los procesos tanto como puedas y realiza simulacros con tu equipo, para que no te sorprenda la crisis. En la era de la IA, esto significa tener habilidades y algoritmos que puedan presentar rápidamente mucha información, y compartir resúmenes y detalles con tu núcleo.

No necesitas ser perfecto, pero sí sobrevivir. Ningún sistema es invulnerable desde el día uno; a través de iteraciones, aprenderás y te volverás antifrágil.

Que no tener sido hackeado no significa que no puedas serlo. El punto de máxima comodidad suele ser el mayor riesgo.

Medidas preventivas

Diseño de contratos inteligentes

Una vez definidos los invariantes, eleválos a verificaciones en tiempo de ejecución. Piensa cuidadosamente cuáles invariantes realmente valen la pena hacer cumplir.

Este es el patrón FREI-PI (Requisitos Funcionales, Efectos, Interacciones, Invariantes del Protocolo): al final de cada función que toque valores, vuelve a verificar los invariantes que esa función prometió mantener. Muchas de las explotaciones por CEI (Checks-Effects-Interactions) (como ataques de flash loans, liquidaciones con oráculos, o drenajes entre funciones) pueden ser capturadas por estas verificaciones al final de la función.

Buenas pruebas

Las pruebas de fuzzing con estado (Stateful fuzzing) generan secuencias aleatorias de llamadas a la interfaz del protocolo, y en cada paso verifican los invariantes. La mayoría de vulnerabilidades en producción son transacciones múltiples, y el fuzzing con estado es casi la única forma confiable de detectar estos caminos antes de que los exploten.

Usa invariantes en las pruebas para asegurar que las propiedades se mantengan en todas las secuencias generadas por el fuzzing. Combinado con verificación formal, puede demostrar que las propiedades se mantienen en todos los estados alcanzables. Tus invariantes de «corona» deben aceptar este enfoque.

Oráculos y dependencias

La complejidad es enemiga de la seguridad. Cada dependencia externa amplía la superficie de ataque. Cuando diseñes primitivas, da a los usuarios la opción de confiar en quién y en qué confiar. Si no puedes eliminar la dependencia, diversifícala, para que ningún fallo único pueda destruir tu protocolo.

Amplía el alcance de auditoría para simular fallos en oráculos y dependencias, y aplica límites de tasa a los posibles desastres que puedan causar si fallan.

El reciente fallo de KelpDAO es un ejemplo: heredaron la configuración predeterminada de LayerZero requiredDVNCount=1, que estaba fuera del alcance de su auditoría. La infraestructura fuera de la cadena que fue comprometida fue la que no estaba en su alcance de auditoría.

Superficie de ataque

La mayoría de las superficies de ataque en DeFi ya han sido listadas. Revisa cada categoría, pregunta si aplica a tu protocolo, y luego implementa controles específicos para cada vector. Entrena habilidades de red team, y haz que tus IA busquen vulnerabilidades activamente en tu protocolo; esto ya es un requisito básico hoy en día.

Capacidad de rescate nativa

En gobernanza basada en votación, el poder inicialmente está concentrado en los multisigs del equipo, y toma tiempo distribuirlo. Aunque los tokens estén ampliamente distribuidos, la delegación suele concentrar autoridad en unas pocas wallets (a veces solo una). Cuando estas wallets son comprometidas, el juego termina.

Implementa «wallets guardianes», con permisos estrictamente limitados: solo pueden pausar el protocolo, y en un umbral de >=4/7, pueden en casos extremos rotar los fondos dañados a wallets de reemplazo predefinidos. Los guardianes nunca pueden ejecutar propuestas de gobernanza.

Así, tienes una capa de rescate que siempre puede restaurar la estabilidad gobernable, sin tener el poder de derrocar la gobernanza. La probabilidad de que pierdas >=4/7 de los guardianes en el peor escenario es muy baja (considerando la diversidad de poseedores), y una vez que la gobernanza esté madura y dispersa, esta capa puede eliminarse gradualmente.

Wallets y topología de claves

Multisig es un requisito básico, mínimo 4/7. Nadie controla todas las 7 claves. Rota frecuentemente los signatarios, y hazlo discretamente.

Las claves nunca deben interactuar con dispositivos de uso diario. Si usas un hardware para firmar mientras navegas, envías correos o abres Slack, esa firma ya está comprometida.

Ten múltiples multisigs, cada uno con diferentes propósitos. Supón que al menos uno será comprometido, y planifica desde allí. Nadie debe tener control suficiente para comprometer el protocolo, incluso en escenarios extremos (secuestros, torturas, etc.).

Considera las recompensas

Si tienes recursos, establecer una recompensa por vulnerabilidades alta en relación con el TVL del protocolo vale mucho la pena; incluso para protocolos pequeños, las recompensas deben ser generosas (por ejemplo, en 7-8 cifras mínimas).

Si enfrentas ataques de actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty (que en realidad lo paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes más inteligentes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva ha cambiado.

Primero, buenos auditores están en la cúspide de la curva. Si haces algo novedoso, tu código y sus vulnerabilidades quizás no estén en sus datos de entrenamiento, y aumentar tokens no ha demostrado ser efectivo para descubrir vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda la multisig si es necesario. No esperes a la «Día D» para comprar estas cosas.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo de activos dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y las necesidades extremas de UX de los usuarios. Si algo sale mal, esto te salvará de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de prohibidos. Incluso si son implícitas, son límites de confianza, y deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso en la configuración, generando fricción significativa. Los atacantes primero deben agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas significa que, si introducen vectores nuevos en secreto, deben vulnerar ambos procesos: el mercado debe aceptar (listado / listado), y la acción no puede ser prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Si nadie supervisa, el «interruptor de apagado» no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y si detectan problemas, activar alertas algorítmicas. La ruta final debe llegar a los guardianes humanos, con suficiente contexto para decidir en minutos.

Recalibrar y detenerse

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el «interruptor de apagado» (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el interruptor no puede pausar el contrato de gobernanza en sí. Si los guardianes pueden pausar el contrato de gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: uno para tomar decisiones; otro para ejecutar scripts de defensa y pausas; uno para reconstruir y analizar la causa raíz; uno para comunicarse con las partes clave; y uno para registrar observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe ser una congelación total del protocolo: no quieres que te induzcan a pausar un componente y abrir otra vulnerabilidad. Cuando encuentres la causa raíz y el vector, explora superficies expuestas relacionadas y repara todo en una sola vez.

Rotación de sucesores preacordados

Solo con sucesores predefinidos, la rotación es segura. Me gusta la idea de un registro de sucesores precomprometidos: dificulta que atacantes cambien guardianes o wallets de gobernanza sanos por otros comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de mitigación.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: hacer due diligence, visitar a quienes proponen, y hacer reuniones previas.

Prueba cuidadosamente antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que implementes: escrito bajo presión, dirigido a atacantes que ya saben cómo explotar tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o realiza una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar a los exchanges cuando saltan cadenas, para rastrear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios, y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que si devuelven todo antes de la fecha límite, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes actuar con hackers éticos, autorizados para proteger fondos, y pagarles un porcentaje del bounty (que en realidad paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de auditar disminuiría. Lo sigo creyendo, pero mi perspectiva ha cambiado.

Primero, los buenos auditores están en la cúspide de la curva. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y aumentar tokens no ha demostrado descubrir vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda la multisig si es necesario. No esperes a la «Día D» para comprar estas cosas.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo de activos dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y las necesidades extremas de UX de los usuarios. Si algo sale mal, esto te salvará de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de prohibidos. Incluso si son implícitas, son límites de confianza, y deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso en la configuración, generando fricción significativa. Los atacantes primero deben agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas significa que, si introducen vectores nuevos en secreto, deben vulnerar ambos procesos: el mercado debe aceptar (listado / listado), y la acción no puede ser prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Si nadie supervisa, el «interruptor de apagado» no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y si detectan problemas, activar alertas algorítmicas. La ruta final debe llegar a los guardianes humanos, con suficiente contexto para decidir en minutos.

Recalibrar y detenerse

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el «interruptor de apagado» (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el interruptor no puede pausar el contrato de gobernanza en sí. Si los guardianes pueden pausar el contrato de gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: uno para tomar decisiones; otro para ejecutar scripts de defensa y pausas; uno para reconstruir y analizar la causa raíz; uno para comunicarse con las partes clave; y uno para registrar observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe ser una congelación total del protocolo: no quieres que te induzcan a pausar un componente y abrir otra vulnerabilidad. Cuando encuentres la causa raíz y el vector, explora superficies expuestas relacionadas y repara todo en una sola vez.

Rotación de sucesores preacordados

Solo con sucesores predefinidos, la rotación es segura. Me gusta la idea de un registro de sucesores precomprometidos: dificulta que atacantes cambien guardianes o wallets de gobernanza sanos por otros comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de mitigación.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: hacer due diligence, visitar a quienes proponen, y hacer reuniones previas.

Prueba cuidadosamente antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que implementes: escrito bajo presión, dirigido a atacantes que ya saben cómo explotar tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o realiza una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar a los exchanges cuando saltan cadenas, para rastrear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios, y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que si devuelven todo antes de la fecha límite, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes actuar con hackers éticos, autorizados para proteger fondos, y pagarles un porcentaje del bounty (que en realidad lo paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de auditar disminuiría. Lo sigo creyendo, pero mi perspectiva ha cambiado.

Primero, los buenos auditores están en la cúspide de la curva. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y aumentar tokens no ha demostrado descubrir vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda la multisig si es necesario. No esperes a la «Día D» para comprar estas cosas.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo de activos dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y las necesidades extremas de UX de los usuarios. Si algo sale mal, esto te salvará de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de prohibidos. Incluso si son implícitas, son límites de confianza, y deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso en la configuración, generando fricción significativa. Los atacantes primero deben agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas significa que, si introducen vectores nuevos en secreto, deben vulnerar ambos procesos: el mercado debe aceptar (listado / listado), y la acción no puede ser prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Si nadie supervisa, el «interruptor de apagado» no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y si detectan problemas, activar alertas algorítmicas. La ruta final debe llegar a los guardianes humanos, con suficiente contexto para decidir en minutos.

Recalibrar y detenerse

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el «interruptor de apagado» (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el interruptor no puede pausar el contrato de gobernanza en sí. Si los guardianes pueden pausar el contrato de gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: uno para tomar decisiones; otro para ejecutar scripts de defensa y pausas; uno para reconstruir y analizar la causa raíz; uno para comunicarse con las partes clave; y uno para registrar observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe ser una congelación total del protocolo: no quieres que te induzcan a pausar un componente y abrir otra vulnerabilidad. Cuando encuentres la causa raíz y el vector, explora superficies expuestas relacionadas y repara todo en una sola vez.

Rotación de sucesores preacordados

Solo con sucesores predefinidos, la rotación es segura. Me gusta la idea de un registro de sucesores precomprometidos: dificulta que atacantes cambien guardianes o wallets de gobernanza sanos por otros comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de mitigación.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: hacer due diligence, visitar a quienes proponen, y hacer reuniones previas.

Prueba cuidadosamente antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que implementes: escrito bajo presión, dirigido a atacantes que ya saben cómo explotar tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o realiza una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar a los exchanges cuando saltan cadenas, para rastrear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios, y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que si devuelven todo antes de la fecha límite, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes actuar con hackers éticos, autorizados para proteger fondos, y pagarles un porcentaje del bounty (que en realidad lo paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de auditar disminuiría. Lo sigo creyendo, pero mi perspectiva ha cambiado.

Primero, los buenos auditores están en la cúspide de la curva. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y aumentar tokens no ha demostrado descubrir vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda la multisig si es necesario. No esperes a la «Día D» para comprar estas cosas.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo de activos dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y las necesidades extremas de UX de los usuarios. Si algo sale mal, esto te salvará de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de prohibidos. Incluso si son implícitas, son límites de confianza, y deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso en la configuración, generando fricción significativa. Los atacantes primero deben agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas significa que, si introducen vectores nuevos en secreto, deben vulnerar ambos procesos: el mercado debe aceptar (listado / listado), y la acción no puede ser prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Si nadie supervisa, el «interruptor de apagado» no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y si detectan problemas, activar alertas algorítmicas. La ruta final debe llegar a los guardianes humanos, con suficiente contexto para decidir en minutos.

Recalibrar y detenerse

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el «interruptor de apagado» (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el interruptor no puede pausar el contrato de gobernanza en sí. Si los guardianes pueden pausar el contrato de gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: uno para tomar decisiones; otro para ejecutar scripts de defensa y pausas; uno para reconstruir y analizar la causa raíz; uno para comunicarse con las partes clave; y uno para registrar observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe ser una congelación total del protocolo: no quieres que te induzcan a pausar un componente y abrir otra vulnerabilidad. Cuando encuentres la causa raíz y el vector, explora superficies expuestas relacionadas y repara todo en una sola vez.

Rotación de sucesores preacordados

Solo con sucesores predefinidos, la rotación es segura. Me gusta la idea de un registro de sucesores precomprometidos: dificulta que atacantes cambien guardianes o wallets de gobernanza sanos por otros comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de mitigación.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: hacer due diligence, visitar a quienes proponen, y hacer reuniones previas.

Prueba cuidadosamente antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que implementes: escrito bajo presión, dirigido a atacantes que ya saben cómo explotar tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o realiza una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar a los exchanges cuando saltan cadenas, para rastrear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios, y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que si devuelven todo antes de la fecha límite, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes actuar con hackers éticos, autorizados para proteger fondos, y pagarles un porcentaje del bounty (que en realidad lo paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de auditar disminuiría. Lo sigo creyendo, pero mi perspectiva ha cambiado.

Primero, los buenos auditores están en la cúspide de la curva. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y aumentar tokens no ha demostrado descubrir vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hacke