📝 Hola a todos, soy 𝟏𝟎, para ser sincero, tengo bastante miedo. No se trata de la tecnología en sí misma, sino de que seguimos usando viejas estrategias defensivas para enfrentar a un nuevo oponente que ya está armado con IA.
Los datos ya lo dicen todo: en el primer trimestre de 2026, los ataques a DeFi alcanzarán un nuevo récord; el segundo trimestre apenas ha comenzado y ya estamos cerca del pico. Antes pensaba que los ataques a nivel estatal eran un poco exagerados, pero desde KelpDAO, Step Finance hasta WazirX, este riesgo se está volviendo cada vez más concreto.
KelpDAO es un ejemplo muy típico. El problema no está en las vulnerabilidades del código, sino en la herencia. Usaron la configuración predeterminada de LayerZero, que permite a un único validador confirmar mensajes entre cadenas, y no está en el alcance de la auditoría. El resultado es que 292 millones de dólares desaparecieron en un tiempo extremadamente corto.
Ahora el riesgo ya no es solo si el código tiene errores, sino que puede que ni siquiera sepas qué riesgos has heredado.
👇👇👇
Uno, con la llegada de la IA, el ataque y la defensa ya no son equitativos.
Antes pensaba que mientras se hicieran suficientes auditorías, se establecieran configuraciones multi-sig adecuadas, y se implementaran medidas como el tiempo de bloqueo, todo estaría bastante seguro, y me sentía tranquilo.
Pero ahora la situación es un poco diferente, la gente puede tardar semanas en revisar meticulosamente la configuración de cientos de protocolos; sin embargo, la IA puede completar un trabajo similar en unas pocas horas. Y como el Mythos AI de Anthropic, incluso puede convertir una vulnerabilidad conocida en una herramienta de ataque aprovechable en 24 horas, por menos de 50 dólares.
Esto ha traído dos cambios muy reales:
Primero, aquellas vulnerabilidades que creías que pocos podrían descubrir, ahora la IA puede encontrarlas en masa.
Segundo, mientras tú intentas cubrir todas las vulnerabilidades, los atacantes ya están utilizando IA para escaneos masivos.
Por eso, ahora me inclino más hacia un enfoque más práctico: en lugar de suponer que el sistema es seguro, es mejor asumir que eventualmente podría ser atacado. Pensar de antemano en cómo realizar una rápida mitigación y controlar las pérdidas es más importante.
En resumen: en lugar de intentar cerrar todas las puertas, es mejor pensar en cómo reducir al mínimo las pérdidas si alguna se abre.
Dos, lo que más temo no son las vulnerabilidades del contrato, sino las vulnerabilidades humanas.
Esta frase no es mía, son datos que nos dicen. Para el Q1 de 2026, las pérdidas en toda la industria debido a phishing y ataques de ingeniería social representarán más del 65%, sumando aproximadamente 306 millones de dólares.
Por ejemplo, en el incidente de WazirX de 230 millones de dólares, el problema no estaba en el contrato inteligente, sino en que la clave privada del administrador de la billetera multi-sig fue robada. Una vez que el atacante obtuvo los permisos, modificó directamente la lógica de la billetera.
Es decir: el contrato es seguro, el proceso está bien diseñado, pero si una persona con permisos es engañada o comprometida, todo se pierde.
No dependas solo de una billetera multi-sig, separa los fondos por diferentes usos y gestiona el riesgo con diferentes estructuras multi-sig. Además, hay un punto más crítico: no mezcles las claves con los dispositivos de uso diario.
Si tu computadora o teléfono se conecta a Internet, recibe correos electrónicos, usa Slack, o has hecho clic en enlaces sospechosos, esos dispositivos ya no se pueden considerar un entorno seguro.
En pocas palabras: mientras esté conectado a la red, se asume que tiene riesgos. Puede sonar un poco exagerado, incluso un poco excesivo en cuanto a precauciones. Pero en esta etapa, ser cauteloso en temas de seguridad es lo normal.
Tres, el kill switch no es un adorno, es tu último recurso.
Mucha gente piensa que el kill switch es solo para cuando no hay otra opción, pero en realidad, debería ser parte del diseño desde el principio.
Hablando claro: cuanto mayor sea tu salida, mayor será tu límite de pérdida. Una función de acuñación sin límite en la cadena es como dar un cheque en blanco para un agujero de acuñación infinito.
Además, el kill switch no debe estar solo en la interfaz de usuario. Necesitas un script de un clic que congele todos los movimientos de valor, ejecutándose de manera atómica. Y antes de presionar, es mejor que ya tengas un sistema de alerta funcionando, con monitores fuera de la cadena vigilando tus invariantes, y si se rompen, subir inmediatamente a un humano.
La razón por la que enfatizo lo humano es que la IA puede detectar, pero la decisión final siempre debe ser humana. Nadie quiere dejar que un algoritmo decida si se congelan miles o millones de dólares en fondos.
Cuatro, un concepto técnico que me gusta: invariantes.
Las variables son las reglas que estableces en el diseño del sistema que deben mantenerse siempre, pase lo que pase. Por ejemplo: depósitos totales ≤ deudas totales.
Puedes escribir estas reglas en el código para que el sistema verifique automáticamente después de cada función clave. Si encuentra que esta regla se ha roto, el sistema se detiene directamente o lanza un error, y no continúa ejecutando transacciones.
Muchos ataques de DeFi (como los préstamos relámpago o los oráculos manipulados) se basan en que el atacante manipula el proceso de ejecución de la función, llevando al sistema a un estado erróneo por un corto tiempo.
Pero si al final forzas una verificación de invariantes, aunque se hayan modificado en el medio, al final deben volver a un estado legal, de lo contrario, falla directamente. Puede dejarte entrar, pero no permitir que salgas con un resultado erróneo.
Por supuesto, los invariantes no son siempre mejores en mayor cantidad. Si intentas restringir todo, el sistema se vuelve rígido, y no podrás realizar operaciones normales.
Una buena práctica es: elegir solo las dos o tres reglas clave, como la seguridad de los fondos y el equilibrio de activos, como objetivos de protección prioritaria.
Luego, combinar validaciones formales o pruebas de fuzzing de estado para verificar estas reglas, generalmente cubre la mayoría de los riesgos.
Cinco, la esencia de la seguridad es dejar espacio para la pérdida de control.
Ahora creo cada vez más que la seguridad no se puede resolver con una auditoría o un informe. Es más como un proceso que necesita ejecutarse cada día, manteniendo la alerta.
Hay una frase que dice bien: no tener evidencia de que te han hackeado no significa que no vayas a ser hackeado. El mayor peligro a menudo no es la vulnerabilidad en sí, sino el momento en que crees que todo está bien.
Así que mi mentalidad ahora es: aceptar que seré hackeado, pero nunca permitir que me lleven de un solo golpe. Pensar de antemano en el camino, hacer simulaciones, preparar la billetera de guardianes y planear los procesos de negociación y seguimiento. No es para ser perfecto, es para que cuando ese día llegue, no estés en pánico.
No se trata de evitar problemas siempre, sino de poder mantener la calma cuando surgen.