Las lecciones de mil millones de dólares: La seguridad de DeFi está cambiando de código a gobernanza operativa

Original compilation: 登链社区

Resumen y guía de contenido:

En el último año, casi 1,000 millones de dólares en pérdidas en DeFi, las verdaderas pérdidas de gran volumen ya no provienen principalmente de vulnerabilidades en el código del contrato inteligente, sino de riesgos en gestión de permisos, flujos de firma, ataques sociales, infraestructura de terceros y riesgos de interoperabilidad cross-chain. Aprendiendo de la resiliencia operativa, las tres líneas de defensa, congelaciones de emergencia, gobernanza de datos de riesgo y revisión de acceso a activos en TradFi, junto con análisis de seguridad asistido por IA, solo así se puede mantener la apertura y la composabilidad mientras se mejora la seguridad de los fondos de los usuarios.

No teníamos por qué perder esos mil millones de dólares

En los últimos doce meses, se han perdido cerca de 1,000 millones de dólares por incidentes en DeFi, pero la mayoría de esas pérdidas podrían haberse evitado.

Empezando por el exploit más reciente: el 18 de abril, el exploit de 292 millones de dólares en Kelp DAO.

AAVE cayó un 15%. Aave congeló el mercado de rsETH en todas sus implementaciones, y luego, por precaución, congeló los préstamos de WETH. Los contratos de Aave en sí nunca fueron explotados, pero en pocas horas, la utilización del mercado WETH alcanzó el 100%. Los proveedores de WETH que nunca habían interactuado con rsETH, de repente, no pudieron retirar fondos.

Luego vino la opinión común en crypto twitter: La puente está rota. DeFi está muerto. Por eso, los fondos reales no entran.

Creo que esas afirmaciones no capturan el punto clave.

La mayor parte de esas pérdidas, en esos 1,000 millones, provienen de vectores de ataque que ya habían sido discutidos y con soluciones propuestas. Las mayores pérdidas están impulsadas por accesos privilegiados, flujos de firma, ataques sociales e infraestructura de terceros, no por bugs aislados en contratos inteligentes. Sin embargo, esas soluciones de reparación no están en la documentación de DeFi, sino en manuales de control bancario, estudios de resiliencia de ingeniería y en los playbooks operativos que TradFi ha perfeccionado durante décadas.

Kelp es el ejemplo más claro.

Un verificador. Un punto de fallo.

El exploit de Kelp no fue un bug en el contrato inteligente. La causa raíz fue que @KelpDAO optó por una configuración de red de validadores descentralizados (DVN) 1-de-1 en el puente LayerZero. Según se dice, los atacantes relacionados con el grupo Lazarus de Corea del Norte no lograron vulnerar el DVN en sí. Primero, identificaron qué proveedores RPC dependían del DVN de LayerZero. Luego, comprometieron dos de ellos para que devolvieran datos falsificados. Después, lanzaron ataques DDoS a los demás proveedores, forzando al sistema a hacer failover a los que ya estaban comprometidos. El DVN firmó una transacción falsa de cross-chain en buena fe — y, dado que no había otros verificadores que validaran el resultado, esa firma fue suficiente.

Un verificador. Un punto de fallo.

116,500 rsETH fueron liberados desde el adaptador OFT de LayerZero en Ethereum (que gestiona tokens cross-chain) a los atacantes, dejando sin respaldo a los tokens rsETH en dieciséis L2. Los atacantes usaron rsETH en Ethereum como colateral para depositar en Aave, Compound y Euler, y así obtener 236 millones de dólares en WETH, hasta que alguien descubrió la estafa. Ahora, todos los que poseen rsETH en alguna L2, solo tienen reclamaciones sobre un “buzón” vaciado.

Este riesgo claro ya fue marcado hace doce días.

El 6 de abril, la ingeniera @liliangjya5, en @get_truenorth, publicó una skill de código abierto Claude que señalaba la opacidad en la configuración del DVN, marcando las 16 cadenas como el mayor vector de riesgo, comparando esa configuración con los exploits de Ronin y Harmony en 2022. La marca de commit es pública — cualquiera puede verla.

[]

Kelp nunca hizo pública su umbral de DVN. LayerZero recomienda explícitamente en su checklist de integración usar configuraciones multi-DVN. Kelp eligió seguir con 1-de-1. Nadie los obligó a publicar o a modificar esa configuración.

Doce días después, 292 millones de dólares desaparecieron.

Los últimos doce meses no niegan DeFi

El exploit de Kelp fue el mayor, pero no el único.

• Hace apenas dos semanas, el 1 de abril, Drift perdió 285 millones de dólares tras meses de ataque social. Los atacantes usaron nonces duraderos en Solana para obtener firmas de administrador válidas, whitelistaron un token sin valor como colateral y vaciaron activos reales. Al menos otros 20 protocolos reportaron impactos similares. Drift, en su reconstrucción posterior, añadió dispositivos de firma dedicados, timelocks en operaciones administrativas y una gobernanza multisig reconstruida.

• El 22 de marzo, Resolv fue atacado a través de infraestructura offchain. Los atacantes, tras comprometer un punto de entrada de un proyecto tercero, accedieron a GitHub y a la nube de Resolv, logrando permisos para firmar en el proceso de minting, creando 80 millones de USR sin respaldo y robando 25 millones de dólares en ETH. El contrato inteligente no falló; la vulnerabilidad estuvo en las claves privilegiadas y en la pila operativa que las rodea.

• El 10 de marzo, las herramientas de riesgo de Aave detectaron una discrepancia en los parámetros de dos oráculos, lo que provocó liquidaciones por aproximadamente 26 millones de dólares, afectando a 34 cuentas. La discrepancia hizo que el precio de wstETH cayera un 2.85%. En este caso, no hubo actor malicioso ni exploit. La pérdida fue resultado de una actualización de configuración bienintencionada, que no fue probada en escenarios hostiles.

• Antes de que comenzara 2026, también ocurrieron pérdidas en Cetus en Sui por 223 millones de dólares, en Cork tras varias auditorías por 12 millones en wstETH, en Balancer en noviembre por más de 120 millones, y en Aerodrome por más de 1 millón, no por un exploit en el contrato, sino por un secuestro DNS en su registrador. El contrato en sí no sufrió daño; fue un phishing el que dio el golpe final.

Sumando, esas pérdidas alcanzan casi 1,000 millones de dólares. Cada incidente tiene causas distintas, pero se empieza a notar un patrón.

Estos exploits se han trasladado fuera del onchain

El riesgo en contratos inteligentes no ha desaparecido — Cetus, Cork y Balancer sufrieron fallos en lógica onchain. Cualquier protocolo que siga considerando que las pruebas de invariantes, simulaciones adversariales y métodos formales son opcionales, aprenderá la lección en su próxima versión. Pero esa ya no es la historia principal.

Mirando a todo el cripto, Chainalysis estima que en 2025 se robarán más de 6,5 mil millones de dólares, y solo los tres mayores hacks representan el 69% de esas pérdidas. Como se mencionó antes, las mayores pérdidas están impulsadas por accesos privilegiados, flujos de firma, ataques sociales e infraestructura de terceros, no por bugs aislados en contratos.

Veo esto como tres modos diferentes de fallo: Capa de código, plano de control, y composabilidad.

2. Código es la capa en la que DeFi es más competente en defensa, pero aún no está completamente resuelta. Tenemos fuzzing, análisis estático y dinámico, verificación formal, bug bounty, auditorías, pruebas de invariantes — ahora, cada equipo serio sabe cómo hacer estas cosas.

3. Plano de control es donde DeFi todavía está al menos una década atrás de TradFi. Dispositivos de firma, rotación de claves, revisión de permisos privilegiados, provenance en CI/CD, endurecimiento de DNS, seguridad en registradores de dominios. La mayoría de los protocolos ni siquiera tiene inventario de estas superficies, mucho menos controlarlas.

4. Composabilidad, aunque es una de las mayores ventajas de DeFi, también trae el riesgo más reciente y subestimado: cuando un mercado de préstamos lista un activo envuelto, convierte el modo de fallo del puente en un fallo propio. Cuando un debt position colateralizado acepta un token de staking líquido, hereda la latencia en gobernanza del emisor. Aave no escribió ninguna línea de código en Kelp, pero aún así sufrió daños por su fallo — y eso revela problemas de gobernanza propios.

Si un protocolo lista un colateral que no puede valorar, congelar, hacer haircut o liquidar de forma independiente bajo presión, en realidad está poniendo el tail risk de ese activo en su balance, independientemente de si el treasury firma o no.

TradFi ya tiene un playbook

Sobre la discusión de hacer DeFi “más parecido a TradFi”, suele desviarse en el mismo paso. La intuición en cripto es que, si se vuelve más parecido a TradFi, será más lento, más custodial, más permissioned y más regulado.

[]

Creo que eso no es correcto.

Aunque TradFi no es perfecto, ha ideado cosas mucho más útiles que el permissioning. Ha desarrollado formas de operar sistemas críticos en medio de disrupciones — esos marcos ya existen. Han sido sometidos a pruebas de estrés en quiebras bancarias, interrupciones en transacciones, ciberataques y fallos operativos durante décadas.

Ejemplos relevantes:

• NIST Cybersecurity Framework 2.0 eleva la gobernanza a una función central junto a Identify, Protect, Detect, Respond y Recover.

• Basel Committee on Banking Supervision define la resiliencia operativa como la capacidad de entregar operaciones críticas en medio de disrupciones.

• FCA del Reino Unido exige a las firmas identificar servicios críticos, establecer tolerancias de impacto y probar si las disrupciones las superan.

• Institute of Internal Auditors, mediante su modelo de Tres Líneas, separa gestión, desafío de riesgos y aseguramiento independiente.

Todo esto no requiere activos ni pasivos en TradFi, ni permisos. Todo puede trasladarse a DeFi. Un DeFi seguro no significa convertirse en un banco, sino mantener la apertura y la composabilidad del usuario, mientras en la capa de control se aplica disciplina bancaria.

Cuando Lazarus atacó los RPC de LayerZero, usaron el mismo playbook que en ataques a SWIFT y supply chains de software empresarial. TradFi tiene treinta años de experiencia en esto. Pero en DeFi, parece que creen que no hay nada que aprender de esa historia.

El poder privilegiado es una utilidad de importancia sistémica

El poder privilegiado debe ser más difícil de usar que las funciones normales del protocolo. Cualquier clave, multisig o cuenta de servicio que pueda listar colaterales, mover reservas, actualizar oráculos, cambiar pares en puentes o modificar lógica de liquidación, es una utilidad financiera de importancia sistémica. El estándar mínimo:

• Hardware wallets

• Autenticación anti-phishing

• Máquinas de firma independientes

• Decodificación fuera de banda de transacciones

• Separación de quórum

• Timelocks en todas las operaciones no urgentes

• Rechazo explícito a funciones que puedan ser usadas para activar firmas dormidas en el futuro

El plan de recuperación tras incidentes de Drift es un buen mínimo.

El stack offchain también forma parte del protocolo. Gestión de código fuente, CI/CD, IAM en la nube, registros de paquetes, dominios, DNS, superficie de WalletConnect y frontends entregados por navegador, están en la frontera de amenazas reales. Los estándares de ingeniería incluyen acceso con permisos mínimos, identidad soportada por hardware, despliegues sin secretos, construcción reproducible con software bill of materials, y dependencia en versiones específicas. En la frontera, el bloqueo de registradores, endurecimiento de DNS y frontends espejo descentralizados pueden mantener la continuidad durante incidentes.

El secuestro DNS en Aerodrome nos recuerda que la frontera es mucho más grande de lo que la mayoría de los equipos asumen.

Cada cambio debe ser probado en escenarios hostiles. Los verificadores cross-chain deben verificar proof, no solo attestation. El puente canónico verifica merkle proofs firmados de headers, una garantía criptográfica: los nodos comprometidos pueden negarse a proporcionar datos, pero no falsificarlos. La verificación de proof es más fuerte que la attestation, pero los puentes basados en proof aún heredan riesgos de consenso, implementación y actualización. La pregunta es qué fallos se excluyen y cuáles se conservan.

Los verificadores basados en attestation no ofrecen las mismas garantías. Firmarán cualquier contenido que devuelvan los endpoints RPC, ampliando la superficie de ataque. Si se usa attestation por velocidad o compatibilidad, el quórum representa independencia, no cantidad. Cinco validadores que leen el mismo RPC envenenado firmarán la misma mentira cinco veces. Solo cuando los miembros del quórum tengan fuentes de datos verdaderamente independientes, la seguridad será real, idealmente combinando nodos privados y públicos confiables. Kelp es el resultado de un atacante sofisticado que explotó esa brecha.

No todos los colaterales valen para el balance compartido. Activos en puentes, tokens de restaking líquidos, shares en vaults, dólares sintéticos y tokens envueltos deben considerarse productos estructurados. Requieren un memo de onboarding independiente, con perfiles de riesgo amplios y límites conservadores. En la mayoría de los casos, deben operar en mercados aislados, no en pools centrales compartidos.

Aave ya suspendió rsETH en abril de 2025 por un bug de sobre-emisión en Kelp. Un año después, rsETH volvió a mercado compartido, lo que merece una revisión más estricta.

La detección y respuesta deben operar a velocidad máquina. Cuando un protocolo puede ser vaciado en minutos, la intervención manual es solo teatro de gobernanza. La automatización limitada debe ser la norma: detección de operaciones administrativas, eventos de mint y burn, uso excesivo, despegue de oráculos y tráfico en puentes, combinados con rate limits nativos, throttling en préstamos y triggers predefinidos, revisados por gobernanza y con alcance limitado, que puedan ser auto-congelados tras incidentes.

Debemos priorizar la protección de fondos de usuarios. La incomodidad de activar automatizaciones ocasionales es mucho menor que el costo de no tenerlas desde el principio.

La gobernanza debe definir qué no puede fallar

Para ayudar a los equipos a definir metas de seguridad, la gobernanza debe establecer qué cosas son absolutamente críticas y no pueden fallar. La junta, el consejo de fundación o DAO deben listar claramente sus servicios críticos: depósitos y retiros, liquidaciones, actualizaciones de oráculos, ejecución de gobernanza, entradas y salidas de puentes, acceso a frontends y comunicación en incidentes.

Para cada uno, se deben establecer tolerancias de impacto, incluyendo daño máximo tolerable a usuarios, pérdida de solvencia, tiempo de inactividad y incertidumbre de datos, y verificar que esas tolerancias se mantengan en escenarios severos pero plausibles.

Eso es exactamente resiliencia operativa bancaria, y puede trasladarse directamente a DeFi.

DeFi debe adoptar un modelo de Tres Líneas real:

• Primera línea: producto, ingeniería, tesorería y operaciones, responsables de sus riesgos y controles.

• Segunda línea: funciones independientes de riesgo y seguridad, con autoridad clara, que desafían listados, parámetros, upgrades y contrapartes, y frenan cambios inseguros.

• Tercera línea: auditoría independiente que verifica si la primera y segunda línea cumplen su función.

La independencia es la forma de evitar que los incentivos de crecimiento hagan que las unidades se aprueben a sí mismas.

El onboarding de activos debe parecerse más a una evaluación de crédito que a desarrollo de negocio. El memo de listado debe cubrir liquidez, concentración, centralización en gobernanza, rutas y capacidad de upgrade en puentes, mecanismos de redención, circuit breakers, construcción de oráculos y aspectos legales. Si alguna de esas hipótesis se rompe, el memo debe tener un plan de degradación claro.

Los permisos de emergencia deben ser estrechos, predefinidos y con sunset. La votación de recuperación en Cetus y Sui muestra dos aspectos: la intervención de emergencia puede salvar cientos de millones, pero también plantea quién puede activar esas acciones, bajo qué condiciones, con qué evidencia, cuánto tiempo puede durar y cómo volver a la gobernanza normal. La definición de esas condiciones debe hacerse antes de la crisis, no en medio de ella.

Cada protocolo debe tener un plan de resolución preparado antes del incidente. Drift está formando un recovery pool post-evento. Aave ha optado por compensar a los afectados tras el error en oráculos. Resolv ha reembolsado en 1:1 a los poseedores antes del hackeo. Estas son respuestas razonables, pero el estándar más alto es una cascada de autorizaciones previas: primero protección a usuarios, luego buffer en treasury, después seguros o módulos de seguridad, responsabilidad de proveedores de servicios y límites claros a pérdidas socializadas.

Distinguir protocolos que toman en serio la gobernanza de los que no, implica tres preguntas: ¿quién puede detener un lanzamiento inseguro? ¿quién puede congelar un mercado bajo condiciones predefinidas? ¿quién paga cuando un proveedor delegado causa pérdidas?

Un protocolo que no puede identificar a las personas, condiciones y responsabilidades relacionadas, no ha definido bien su gobernanza, solo reza para que no ocurra un exploit.

Los datos de riesgo determinan el éxito o fracaso de las medidas de control

Un DeFi seguro necesita un data plane en vivo: señales onchain y offchain que impulsen cada freeze, cap y liquidación. El control plane actúa, el data plane indica si debe actuar.

Los estándares de datos y la calidad de los datos son igual de importantes. La información que alimenta oráculos, freezes y cambios en parámetros debe tener ventanas de frescura, provenance documentada, puntuación de confianza y validación cruzada con feeds independientes. Cuando hay discrepancias, las acciones de fallback deben estar definidas de antemano, no improvisadas.

Aave propone un oracle gestionado por riesgo para USDe, y su Oracle de pendiente ponderada en el tiempo, Slope2, va en la dirección correcta. El evento de wstETH nos recuerda que cada ciclo de control automatizado necesita barreras contra errores de configuración.

La divulgación en sí misma es una forma de control. Los usuarios deben tener páginas públicas de estado, listas de direcciones atacantes, logs en tiempo real, declaraciones iniciales rápidas y claras, y un post-mortem que distinga hechos confirmados de hipótesis, cuantifique pérdidas, liste controles modificados y explique caminos de compensación. La actualización de recuperación de Drift, el post-mortem de Resolv y las explicaciones de oráculo en Aave son mucho mejores que las publicaciones vagas y silencios pasados. El estándar de la industria debe ser un playbook de comunicación que ya se haya ensayado antes de que sea necesario.

El propósito de los datos de riesgo es impulsar acciones. Limitar préstamos, reducir caps, pausar mercados, actualizar manualmente, demostrar que un mercado puede seguir abierto de forma segura. Analíticas que no puedan integrarse en control, límites o assurance no merecen llamarse infraestructura de riesgo.

El modelo de amenaza de IA ya cambió

En abril de 2026, cambió el modelo de amenaza de IA. Claude Mythos Preview de Anthropic ha demostrado poder identificar y explotar vulnerabilidades zero-day en todos los sistemas operativos y navegadores principales. Más del 99% de esas vulnerabilidades aún no se han divulgado, porque nadie las ha parchado. Los bancos y reguladores en UK, EE.UU. y Alemania ya consideran que capacidades como Mythos representan un riesgo cibernético real.

Los protocolos de DeFi también deberían actuar así.

Desde un punto de vista práctico, el spear-phishing es más barato, el desarrollo de exploits más rápido, la recon más autónoma, y los casos de bajo señal se detectan más temprano. La defensa y respuesta deben ser:

• Los workstations de los desarrolladores deben estar reforzados como endpoints privilegiados

• La revisión de código debe incluir análisis adversarial asistido por IA en entornos controlados

• Los workflows de firma deben tener capacidades anti-phishing por defecto

• La detección de anomalías y respuestas automáticas limitadas deben asumir que los atacantes pueden actuar más rápido que cualquier equipo humano

La historia de Kelp es en realidad una versión optimista de esto. La misma capacidad de IA que amenaza a los protocolos puede también defenderlos. Una herramienta de auditoría open source corriendo en Claude Code, detectó con 12 días de antelación los riesgos precisos de Kelp. No es perfecta: calificó el riesgo como medio, cuando en realidad debería ser crítico; no puede penetrar configuraciones sin verificación onchain; y también omitió que la configuración del DVN puede consultarse en chain mediante los contratos EndpointV2 de LayerZero.

Pero hizo las preguntas correctas que otros no han planteado.

Este es el modelo que debemos adoptar. La IA como capa de seguridad independiente, que cualquier LP, protocolo o auditor puede usar para adelantarse en movimientos de fondos.

Un DeFi seguro no significa un DeFi lento

Tras el incidente de Kelp, la visión predominante es que DeFi tiene problemas de seguridad. Pero creo que ese encuadre es incorrecto.

DeFi tiene problemas en la capa de control, en la valoración de composabilidad y en la disciplina de gobernanza. Los tres tienen soluciones conocidas, muchas de las cuales ya están en manuales de riesgos bancarios de hace treinta años. La única barrera entre DeFi y una mayor seguridad para los usuarios, es si los fundadores las implementan o no.

Un DeFi seguro no tiene por qué ser lento. “Slow” y “safe” son atributos diferentes. Acceso abierto para usuarios, composabilidad y liquidaciones 24/7 globales; disciplina bancaria en la capa de control, challenge independiente, velocidad de máquina y assurance continua. Ambos pueden coexistir.

Las herramientas ya existen. Los playbooks ya existen. El capital para un DeFi seguro también.

DeFi acaba de empezar. Asegurémonos de que siga existiendo en diez años.