¡De nivel bomba nuclear! Los hackers de IA están liquidando en segundos tus posiciones DeFi, ¿pueden salvarte 3 "invariantes"?

Te voy a contar algo, no pienses que te estoy asustando.

Recientemente vi unos datos de ataques de hackers en 2026, la cantidad de DeFi hackeado alcanzó un récord histórico. Solo en el primer trimestre se rompió el récord, y en el segundo trimestre, justo empezando, otro récord está a punto de ser superado. La fuente son las estadísticas de DefiLlama, claramente.

Te doy una señal de peligro: la IA ha llevado el costo de buscar vulnerabilidades a precios de suelo. Antes, un equipo humano necesitaba semanas para revisar la configuración de cien protocolos en busca de errores, ahora los modelos básicos más recientes solo necesitan unas horas.

Aquellos que todavía creen que “la IA no es tan inteligente” en sus protocolos, están siendo descubiertos en un segundo.

No me digas que no te da miedo “los actores estatales”. Estos supervillanos son expertos en tecnología, con recursos abundantes, jugando un juego de largo plazo. Se dedican a revisar cada rincón de tus protocolos e infraestructura en busca de vulnerabilidades, mientras tu equipo está distraído en seis o siete áreas de negocio.

No soy un experto en seguridad, pero he liderado equipos de alto riesgo—en el ámbito militar y financiero con fondos elevados. Creo en una cosa: solo los paranoicos sobreviven.

Déjame contarte ideas para responder. La superficie de los ataques de hackers se puede dividir en tres partes: el equipo del protocolo, los contratos inteligentes y la infraestructura, y los límites de confianza del usuario (como redes sociales).

Para estas tres áreas, hay que implementar cinco capas de defensa: prevenir, mitigar, pausar, recuperar y restaurar. Prevenir significa bloquear vulnerabilidades en los procesos; mitigar, en caso de fallar la prevención, limitar el daño; pausar, detectar el ataque y desconectar inmediatamente, sin tomar decisiones bajo presión; recuperar, si un componente es comprometido, abandonarlo y reemplazarlo; restaurar, planear con anticipación socios que puedan congelar fondos, revertir transacciones y colaborar en investigaciones.

¿Cómo hacerlo específicamente? Aquí te doy información valiosa.

Usa ampliamente IA avanzada para escanear tu código y configuración, realiza pruebas de red team. Los atacantes usan IA, y las herramientas defensivas que tú usas para detectar ya las han detectado en sus escaneos ofensivos.

El tiempo y la fricción son buenas defensas. Añade múltiples pasos y bloqueos temporales a cualquier operación que pueda causar daño. Antes, oponerse a esto buscaba reducir fricciones en el equipo, pero ahora, con IA, puedes automatizar estos pasos en segundo plano, sin preocuparte.

Las invariantes son clave. Escribe “hechos” inmutables—como la lógica central del protocolo. Si estos hechos se rompen, todo el protocolo colapsa. Pero no escribas demasiado; hacer que varias invariantes se cumplan en cada función puede ser inmanejable.

Es necesario equilibrar el poder. Muchas brechas provienen de wallets comprometidos. Tu configuración debe garantizar que, incluso si una firma múltiple es comprometida, puedas limitar rápidamente el daño y devolver el control del protocolo a una gobernanza que pueda decidir. La gobernanza lo decide todo; las acciones de rescate pueden restaurar la estabilidad gobernable, pero no reemplazar o anular la gobernanza misma.

Supón que seguro serás hackeado. Incluso tú, tan inteligente, no podrás escapar. Los contratos inteligentes o dependencias fallarán, los ataques de ingeniería social llegarán, las actualizaciones introducirán vulnerabilidades. Con este supuesto, los límites de tasa y los interruptores de corte del protocolo serán tus mejores aliados. Limita el daño a un 5-10%, congela y planifica la respuesta.

El mejor momento para planear es ahora. Antes de que te hackeen, diseña tu plan. Codifica los procesos y entrena a tu equipo. En la era de IA, esto significa tener habilidades y algoritmos que puedan presentar información rápidamente y compartirla con tu círculo principal. No necesitas ser perfecto, pero sí sobrevivir. Ningún sistema es invulnerable desde el principio; tras varias iteraciones, te vuelves antifrágil. La ausencia de evidencia de hackeo no significa que no te puedan hackear. Los momentos más cómodos suelen ser los más peligrosos.

En las medidas preventivas, el diseño de contratos inteligentes debe centrarse en invariantes, elevándolos a verificaciones en tiempo de ejecución. El modo FREI-PI: al final de cada función que manipula valor, vuelve a verificar la invariancia del “corona” que esa función debe mantener. Muchas ataques de extracción—como sandwich de flash loans, liquidaciones asistidas por oráculos, extracción de capacidad de pago entre funciones—pueden ser detectados con estas verificaciones al final de la función.

Las pruebas de fuzzing con estado deben generar secuencias aleatorias de llamadas a la superficie del protocolo, afirmando invariantes en cada paso. La mayoría de las vulnerabilidades en producción son transacciones múltiples, y las pruebas de fuzzing con estado son casi la única forma confiable de detectar rutas antes de que los atacantes las encuentren. Combinadas con verificación formal, pueden demostrar que las propiedades se mantienen en todos los estados alcanzables.

Los oráculos y dependencias externas son enemigos de la seguridad. Cada dependencia externa amplía la superficie de ataque. Diseña primitivas que deleguen la confianza en el usuario. Si no puedes eliminar dependencias, diversifica. Que ningún fallo único pueda destruir el protocolo. Amplía el alcance de auditoría para simular fallos en oráculos y dependencias, y limitar los posibles desastres. El reciente fallo de KelpDAO es un ejemplo: heredaron la configuración predeterminada de LayerZero, requiredDVNCount=1, que quedó fuera del alcance de la auditoría, y fue comprometido en infraestructura fuera de la cadena.

Las amenazas superficiales ya están listadas. Revisa cada categoría, pregunta si aplica a tu protocolo, y aplica controles. Entrena habilidades de red team, y haz que tus IA activamente busquen vulnerabilidades, esto ya es un requisito básico.

Ten capacidades de rescate nativas. En gobernanza basada en votación, el poder está en la multi firma del equipo, que tarda en dispersarse. Implementa “billeteras guardianas”, con autorizaciones estrictas: solo pueden pausar el protocolo, y en casos extremos, con un umbral de >=4/7, pueden reemplazar a los afectados por una billetera de reemplazo predefinida. Los guardianes nunca pueden ejecutar propuestas de gobernanza. Así, tienes una capa de rescate sin poder de derrocar la gobernanza.

En la topología de wallets y claves, la multi firma mínima debe ser 4/7. Nadie controla todas las 7 claves. Rota las firmas con frecuencia, de forma silenciosa. Las claves nunca interactúan con dispositivos diarios. Si usas un dispositivo de firma para navegar, enviar correos o abrir Slack, esa firma ya está comprometida. Usa múltiples multi firmas, cada una para diferentes usos. Supón que al menos una firma completa será comprometida, y planifica desde allí.

Las recompensas por vulnerabilidades deben ser generosas. Si tienes recursos, establece recompensas altas en relación con el TVL del protocolo, mínimo 7-8 cifras. Frente a actores estatales, quizás no negocien, pero aún puedes participar en programas de bug bounty, autorizando a hackers éticos a actuar en tu nombre.

El valor de los auditores sigue siendo importante. Los buenos auditores están un paso adelante. Cuando innovas, las vulnerabilidades pueden no estar en sus datos de entrenamiento, y aumentar solo tokens aún no ha demostrado ser efectivo. No quieres ser el primer ejemplo de vulnerabilidad única. Contratar auditores también es usar su reputación como garantía—si aprueban y tú te hackean, estarán muy motivados a ayudar.

La seguridad operativa debe ser un indicador de éxito. Realiza simulacros de phishing, contrata red teams para ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda la multi firma.

En cuanto a mitigaciones, tu ruta de salida es el límite de pérdida. El tamaño máximo de pérdida en cualquier ruta de extracción de valor del protocolo. Sin límites por bloque en la función de emisión, es un cheque en blanco de emisión infinita. Sin límites semanales en la función de redención, es un cheque en blanco de saldo de activos dañado. Piensa cuidadosamente en límites claros de salida, equilibrando daño máximo y experiencia de usuario.

Las listas blancas y negras deben formalizarse. Usa mecanismos de dos fases para establecer, creando fricción. El atacante debe primero agregar a la lista blanca y luego eliminar de la negra para actuar. Tener ambas significa que el atacante debe vulnerar dos procesos.

Las medidas de recuperación deben tener monitoreo algorítmico. Los monitores off-chain vigilan invariantes, y si detectan un problema, generan alertas automáticas. La ruta final llega a las manos humanas de los guardianes, con suficiente contexto para decidir en minutos.

Si te hackean, primero detén la hemorragia. Prepara un script auxiliar de “pausar todo”, enumerando todos los componentes que se puedan pausar y haciendo una pausa atómica. Solo la gobernanza puede levantar la pausa; el interruptor de emergencia no puede pausar el contrato de gobernanza en sí. Si la capa de guardianes puede pausar la gobernanza, un guardian comprometido puede bloquear permanentemente el proceso de recuperación.

Activa la sala de crisis. Congela, detén, reúne a las personas de confianza en un círculo reducido, para evitar filtraciones a atacantes, público o arbitrajistas maliciosos. Roles: un decisor, un operador que ejecute los scripts de defensa, un experto en reconstrucción de vulnerabilidades, un comunicador, y alguien que registre la línea de tiempo de eventos.

Considera las reacciones en cadena. La primera vulnerabilidad puede ser un señuelo, sembrando semillas para ataques posteriores. La pausa debe ser exhaustiva y completamente controlada. La pausa debe congelar todo el protocolo, evitando que la desactivación de un componente abra otra vulnerabilidad. Cuando encuentres la causa raíz, explora superficies expuestas adyacentes y reacciones en cadena, y corrige todo en una sola vez.

Planifica la rotación de sucesores precomprometidos. Solo si conoces a los sucesores con anticipación, la rotación será segura. 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”.

Prueba cuidadosamente antes de actualizar. Cuando determines el alcance, lanza la actualización con cautela. Es el código más peligroso: escrito bajo presión, dirigido a atacantes que ya saben cómo hackearte. Si no hay tiempo para auditoría, apóyate en relaciones con white hats, o establece una carrera de 48 horas.

Las acciones de recuperación deben ser rápidas. Los fondos robados tienen una vida media; una vez en marcha, entran rápidamente en lavado de dinero. Prepara con anticipación proveedores como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar a los exchanges para congelar. Prepara listas de terceros: departamentos de cumplimiento, administradores de puentes cross-chain, custodios, etc.

La negociación es imprescindible. Intenta dialogar con los atacantes. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que si devuelven en el plazo, no tomarás acciones legales. Frente a actores estatales, quizás no tengas suerte, pero con atacantes menos sofisticados, quieren salir barato. Pero primero, consulta con asesores legales.

La conclusión es dura: los ataques no se detendrán, y cuanto más inteligente sea la IA, más ataques habrá. Solo hacer que los defensores sean “más agudos” no basta. Necesitas usar las mismas herramientas de los atacantes, realizar red team en tus protocolos, monitorear continuamente, y poner límites estrictos al daño, para sobrevivir en el peor escenario.

Tu posición, tú decides.