En solo 18 días de este abril, los atacantes drenaron $ 606 millones de DeFi. Ese único tramo borró las pérdidas del primer trimestre de 2026 en 3,7 veces y convirtió al mes en el peor desde el atraco a Bybit en febrero de 2025. Dos protocolos —Drift en Solana y Kelp DAO en Ethereum— representaron el 95 % de los daños. Ambos habían sido auditados. Ambos superaron el análisis estático. Ambos lanzaron actualizaciones de rutina que invalidaron silenciosamente las suposiciones que sus auditores habían verificado.
Este es el nuevo rostro del riesgo en DeFi. Los exploits catastróficos de 2026 ya no se tratan de errores de reentrada o desbordamientos de enteros que los fuzzers pueden detectar en CI. Se trata de vulnerabilidades introducidas por actualizaciones: cambios sutiles en las configuraciones de los puentes, fuentes de oráculos, roles de administrador o valores predeterminados de mensajería que convierten el código previamente seguro en una puerta abierta, sin que ninguna línea individual de Solidity parezca obviamente incorrecta.
Si construyes, custodias o simplemente posees activos en DeFi, la conclusión de abril de 2026 es incómoda: un informe de auditoría impecable con fecha de hace tres meses ya no es evidencia de que un protocolo sea seguro hoy.
El patrón de abril: Configuración, no código
Para entender por qué lo "introducido por actualizaciones" merece su propia categoría, observe cómo se desarrollaron realmente los dos mayores exploits.
**Drift Protocol — 285millones,1deabrilde2026.∗∗ElDEXdeperpetuosmaˊsgrandedeSolanaperdioˊmaˊsdelamitaddesuTVLdespueˊsdequelosatacantespasaranseismesesejecutandounacampan~adeingenierıˊasocialcontraelequipo.Unavezestablecidalaconfianza,utilizaronlafuncioˊnde"noncesduraderos"deSolana—unaconvenienciadeUXdisen~adaparapermitiralosusuariosprefirmartransaccionesparasuenvıˊoposterior—paraengan~aralosmiembrosdelConsejodeSeguridaddeDriftparaqueautorizaranloquepensabanqueeranfirmasoperativasderutina.Esasfirmaseventualmenteentregaronelcontroldeadministradoralosatacantes,quienesincluyeronenlalistablancauntokendegarantıˊafalso(CVT),depositaron500millonesdeunidadesdeesteyretiraron 285 millones en USDC, SOL y ETH reales. La función de Solana estaba funcionando según lo diseñado. Los contratos de Drift estaban haciendo lo que sus administradores ordenaron. El ataque vivió enteramente en la brecha entre lo que los firmantes del multisig pensaban que estaban aprobando y lo que realmente estaban aprobando.
Kelp DAO — $ 292 millones, 18 de abril de 2026. Atacantes atribuidos por LayerZero al Lazarus Group de Corea del Norte comprometieron dos nodos RPC que sustentaban el puente rsETH cross-chain de Kelp, intercambiaron los binarios que se ejecutaban en ellos y utilizaron un DDoS para forzar una conmutación por error del verificador. Los nodos maliciosos luego le dijeron al verificador de LayerZero que había ocurrido una transacción fraudulenta. El exploit solo funcionó porque Kelp ejecutaba una configuración de verificador 1 de 1, lo que significa que una sola DVN operada por LayerZero tenía autoridad unilateral para confirmar mensajes cross-chain. Según LayerZero, esa configuración 1 de 1 es la predeterminada en su guía de inicio rápido y es utilizada actualmente por aproximadamente el 40 % de los protocolos en la red. En 46 minutos, un atacante drenó 116 500 rsETH —alrededor del 18 % de todo el suministro circulante— y dejó varada la garantía envuelta en 20 cadenas. Aave, que lista rsETH, se vio forzada a una crisis de liquidez mientras los depositantes corrían hacia la salida.
Ninguno de los ataques requirió un error en el contrato inteligente. Ambos requirieron comprender cómo una configuración —flujos de firma multifirma, recuentos de DVN por defecto, redundancia de RPC— había sido elevada silenciosamente de "detalle operativo" a "suposición de seguridad estructural".
Por qué las auditorías estáticas pasan por alto esta clase de error
La auditoría tradicional de DeFi está optimizada para el modelo de amenaza equivocado. Firmas como Certik, OpenZeppelin, Trail of Bits y Halborn sobresalen en la revisión de código línea por línea y en la ejecución de pruebas de invariantes contra una versión de contrato congelada. Eso detecta reentrada, errores de control de acceso, desbordamientos de enteros y fallos de estilo OWASP.
Pero la clase de errores introducidos por actualizaciones tiene tres propiedades que derrotan ese flujo de trabajo:
-
Vive en el comportamiento de tiempo de ejecución compuesto, no en el código fuente. La seguridad de un puente depende de la configuración del verificador de su capa de mensería, el conjunto de DVN, la redundancia de RPC de esas DVN y la exposición al slashing de esos operadores. Nada de eso está en el Solidity que lee un auditor.
-
Se introduce mediante cambios, no por el despliegue inicial. El puente de Kelp presumiblemente se veía bien cuando se integró LayerZero v2 por primera vez. El recuento de DVN se volvió peligroso solo cuando el TVL creció lo suficiente como para valer la pena un ataque y cuando Lazarus invirtió en comprometer la infraestructura RPC.
-
Requiere pruebas diferenciales de comportamiento —responder "¿se preservó el invariante X bajo la nueva ruta de código?"— lo cual ninguna de las principales firmas de auditoría comercializa como un servicio programado posterior a la actualización. Obtienes una auditoría única en la versión 1.0 y una auditoría única separada en la versión 1.1, pero ninguna declaración continua de que la actualización de 1.0 a 1.1 no rompe las propiedades de las que dependía la 1.0.
Las estadísticas del primer trimestre de 2026 cuantifican la brecha. DeFi registró 165,5millonesenpeˊrdidasatraveˊsde34incidentesentodoeltrimestre.Soloabrilprodujo 606 millones en 12 incidentes. El lado del despliegue escaló —se agregaron más de $ 40 mil millones en nuevo TVL en el primer trimestre— mientras que la capacidad de auditoría, la respuesta a incidentes y la validación posterior al despliegue se mantuvieron prácticamente estables. Algo tenía que ceder.
Tres fuerzas que convierten a 2026 en el año en que esto golpea a gran escala
1. La cadencia de actualizaciones se ha acelerado en cada capa
Cada L1 y L2 está iterando más rápido. La actualización Pectra de Ethereum está en despliegue activo, Fusaka y Glamsterdam están en diseño, y Solana, Sui y Aptos lanzan cambios en la capa de ejecución en ciclos de varias semanas. Cada actualización a nivel de cadena puede alterar sutilmente la semántica del gas, los esquemas de firma o el orden de las transacciones de maneras que repercuten en los supuestos de la capa de aplicación. El exploit de Drift es un claro ejemplo : una función de Solana ( durable nonces ) diseñada para la conveniencia de la UX se convirtió en el vehículo para una toma de control por parte del administrador.
2. El restaking multiplica la superficie de ataque de las actualizaciones
El stack de restaking — EigenLayer ( que todavía representa más del 80 por ciento del mercado ) , Symbiotic, Karak, Babylon, Solayer — añade una tercera dimensión al problema. Un solo LRT como rsETH se asienta sobre EigenLayer, que a su vez se asienta sobre el staking nativo de ETH. Cada capa lanza sus propias actualizaciones en su propio horario. Un cambio en la semántica de slashing de EigenLayer tiene consecuencias implícitas para cada operador y cada LRT que consume la validación de ese operador. Cuando el puente de Kelp fue drenado, el contagio amenazó inmediatamente el TVL de EigenLayer, porque los mismos depositantes tenían una exposición a la rehipoteca de tres capas que nunca se les había obligado a modelar. La hoja de ruta de EigenCloud, con sus inminentes expansiones de EigenDA, EigenCompute y EigenVerify, solo ampliará esa superficie.
3. La actividad DeFi impulsada por IA se mueve más rápido que la revisión humana
Los stacks de agentes como XION, Brahma Console y Giza ahora interactúan con contratos actualizados a velocidad de máquina. Mientras que un tesorero humano podría esperar días después de la actualización de un contrato antes de volver a interactuar, un agente realiza un backtest, lo integra y enruta capital a través de él en cuestión de horas. Cualquier actualización que rompa silenciosamente un invariante es puesta a prueba por un flujo adversarial antes de que un auditor humano pueda volver a revisarla.
La arquitectura defensiva que comienza a emerger
La noticia alentadora es que la comunidad de investigación de seguridad no ha estado ociosa. Las pérdidas de abril de 2026 han catalizado propuestas concretas en cuatro frentes.
Verificación formal continua. La colaboración de larga duración de Certora con Aave — financiada como una subvención de verificación continua en lugar de un compromiso único — es ahora un modelo a seguir. El Certora Prover vuelve a ejecutar automáticamente las pruebas de invariantes cada vez que cambia un contrato, detectando fallos antes de la integración. Halmos y HEVM ofrecen rutas alternativas de código abierto hacia el mismo objetivo. Cuando la verificación formal detectó recientemente una vulnerabilidad en una integración con la actualización Electra de Ethereum que las auditorías tradicionales habían pasado por alto, no fue un caso aislado ; fue un anticipo.
Servicios de auditoría de diff de actualizaciones. Spearbit, Zellic y Cantina han comenzado a pilotar servicios de pago que auditan el diff entre dos versiones de un contrato, no la nueva versión de forma aislada. El modelo trata cada actualización como una nueva atestación y examina explícitamente si se conservan los invariantes anteriores. El programa de subsidios de auditoría de $ 1 M de la Fundación Ethereum, lanzado el 14 de abril de 2026, con una lista de socios que incluye a Certora, Cyfrin, Dedaub, Hacken, Immunefi, Quantstamp, Sherlock, Spearbit, Zellic y Zokyo, tiene como objetivo parcial ampliar la capacidad para este tipo de trabajo.
Ingeniería del caos y monitoreo en tiempo de ejecución. OpenZeppelin Defender y otras herramientas emergentes están integrando simulaciones de mainnet bifurcada ( forked-mainnet ) en los pipelines de CI, lo que permite a los protocolos replicar escenarios adversariales contra cada actualización propuesta. La disciplina se toma prestada directamente de la práctica de SRE de la Web2 — y es algo que ya debería haber llegado a DeFi.
Escrows de actualización con bloqueo de tiempo. El patrón Compound Timelock v3, donde cada actualización aprobada por la gobernanza permanece en una cola pública durante un retraso fijo antes de su ejecución, le da a la comunidad tiempo para detectar problemas que la revisión interna pasó por alto. No evita los errores introducidos por las actualizaciones, pero gana tiempo para que sean descubiertos antes de su explotación.
La comparación con TradFi : La auditoría continua es la norma fuera de DeFi
Las finanzas tradicionales resolvieron el problema análogo hace décadas. SOC 2 Tipo II, el estándar al que se someten la mayoría de los proveedores de servicios institucionales, no es una atestación única ; es una ventana de auditoría continua de seis a doce meses. El marco de riesgo de contraparte de Basilea III exige que los bancos actualicen sus modelos de capital a medida que cambian las exposiciones, no anualmente. Un banco de custodia que actualizara un sistema de liquidación no tendría permitido operar bajo la premisa de " auditamos la v1 ; la v2 fue solo un pequeño cambio ".
La cultura predominante de DeFi — " auditar una vez, desplegar para siempre, volver a auditar solo en rediseños importantes " — es la práctica que TradFi rechazó explícitamente después de la crisis de 2008. Al ritmo actual de pérdidas, la industria está en camino de alcanzar los $ 2 mil millones o más en pérdidas anuales por exploits de actualizaciones. Esto es lo suficientemente grande como para atraer a reguladores que ya consideran que los estándares de auditoría de DeFi son deficientes, y es lo suficientemente grande como para hacer de la validación continua una condición previa para el capital institucional.
Qué significa esto para constructores, depositantes e infraestructura
Para los equipos de protocolos, el mandato operativo es sencillo, aunque no sea barato : cada actualización debe tratarse como un nuevo lanzamiento que vuelve a derivar, no hereda, sus garantías de seguridad. Eso significa re-auditorías programadas basadas en diffs, especificaciones de verificación formal que acompañen cada propuesta de gobernanza y bloqueos de tiempo significativos antes de la ejecución. Significa publicar — al estilo de Aave — un marco de riesgo en cascada cuantificado que nombre de qué protocolos dependes y cómo se ve tu exposición cuando uno de ellos falla.
Para los depositantes, la lección es que " este protocolo fue auditado " ya no es una señal útil por sí sola. La pregunta correcta es " ¿cuándo fue la última ejecución de verificación continua, contra qué invariantes y sobre qué versión del código desplegado ? ". Los protocolos que no puedan responder a eso deben valorarse en consecuencia.
Para los proveedores de infraestructura — operadores de RPC, indexadores, custodios — el incidente de Kelp es una advertencia directa. El compromiso se produjo en dos nodos RPC cuyos binarios fueron intercambiados silenciosamente. Cualquier persona que ejecute infraestructura que participe en la verificación cross-chain ( DVN, nodos de oráculo, secuenciadores ) ahora es parte del modelo de seguridad, tanto si se inscribió para ello como si no. Las compilaciones reproducibles, los binarios atestiguados, los quórums de múltiples operadores por encima de los valores predeterminados de 1 de 1 y la verificación de binarios firmados al inicio ya no son opcionales.
Las actualizaciones a nivel de cadena — Pectra y Fusaka en Ethereum, los despliegues de ejecución paralela en Solana y Aptos, los objetivos de rendimiento de Glamsterdam — seguirán ampliando la superficie. Los protocolos y operadores de infraestructura que sobrevivan a 2026 serán aquellos que adoptaron la validación continua lo suficientemente pronto como para que su próxima actualización rutinaria sea también su próximo punto de control de seguridad demostrable.
BlockEden.xyz opera infraestructura de producción de RPC, indexadores y nodos en Sui, Aptos, Ethereum, Solana y una docena de otras cadenas. Tratamos cada actualización de protocolo — en la capa de cadena o en la capa de aplicación — como un nuevo evento de seguridad, no como una tarea de mantenimiento. Explore nuestra infraestructura empresarial para construir sobre una base diseñada para sobrevivir a la cadencia de actualizaciones que se avecina.
Fuentes
