El 18 de abril de 2026, el puente cross-chain rsETH de KelpDAO fue explotado por aproximadamente $290 millones, convirtiéndolo en el mayor incidente de seguridad DeFi del año. La atribución preliminar apunta al Grupo Lazarus, un actor de amenazas patrocinado por un estado con un historial bien documentado de ataques a infraestructura cripto [1]. El ataque no explotó una vulnerabilidad en un contrato inteligente. En cambio, envenenó la infraestructura RPC subyacente de un único nodo de Red de Verificadores Descentralizados (DVN), falsificando mensajes cross-chain que liberaron tokens rsETH sin ninguna quema correspondiente en la cadena de origen.
El exploit en sí ha sido cubierto en detalle por LayerZero [1] y KelpDAO [2]. Este artículo adopta un enfoque diferente. En lugar de reproducir el ataque, examinamos qué ocurrió después del exploit: cómo una dependencia de infraestructura de punto único habilitó una cascada que congeló miles de millones en liquidez en cinco cadenas, y cómo esa cascada obligó a los marcos de gobernanza descentralizada a ejercer poderes de emergencia centralizados a plena vista del público.
El incidente de KelpDAO traza una cadena causal que atraviesa tres capas de la arquitectura "descentralizada": una dependencia DVN de punto único hizo posible el exploit; la componibilidad de DeFi (también conocida como "DeFi Lego"), la propiedad que permite a los protocolos conectarse entre sí como piezas de construcción, convirtió ese exploit del puente en una crisis de liquidez a nivel de sistema; y la escala de la crisis, a su vez, obligó a los marcos de gobernanza a revelar los poderes de emergencia centralizados incorporados en ellos.
Antecedentes: El Exploit de KelpDAO en Resumen
KelpDAO es el emisor de rsETH, un token de re-staking líquido (LRT) que representa posiciones de ETH en staking a través de múltiples operadores. Para habilitar el movimiento cross-chain de rsETH, KelpDAO se integró con el protocolo de mensajería de LayerZero, que se basa en DVNs, verificadores independientes que confirman que los mensajes cross-chain son legítimos antes de que se ejecuten en la cadena de destino.
La elección de configuración crítica: el OApp rsETH de KelpDAO utilizó una configuración DVN de 1 de 1, con el DVN operado por LayerZero Labs como único verificador. Esto significaba que toda la seguridad cross-chain de rsETH dependía de una única entidad de verificación. La documentación de integración de LayerZero recomienda explícitamente configuraciones multi-DVN con redundancia, y LayerZero afirma haber comunicado esta práctica recomendada a KelpDAO antes del incidente [1]. KelpDAO, por su parte, sostiene que la configuración 1/1 era "la configuración documentada en la documentación de LayerZero y entregada como predeterminada para cualquier nuevo despliegue de OFT," y que "los valores predeterminados fueron afirmativamente confirmados como apropiados" durante su expansión a L2 [2].
Los atacantes comprometieron dos nodos RPC utilizados por el DVN de LayerZero Labs, reemplazando sus binarios con versiones maliciosas que devolvían datos de estado de cadena falsificados exclusivamente a la dirección IP del DVN mientras parecían normales para todos los demás observadores, incluida la propia infraestructura de monitoreo de LayerZero. Un ataque DDoS simultáneo contra los nodos RPC no comprometidos forzó la conmutación por error a los nodos envenenados. El resultado: el DVN confirmó un mensaje cross-chain que nunca ocurrió en la cadena de origen, liberando 116,500 rsETH del adaptador del lado de Ethereum (0x85d4...8ef3) sin ninguna quema correspondiente en el lado de origen [1, 3]. La transacción de liberación es 0x1ae232...db4222. La evidencia on-chain es inequívoca: el endpoint de destino de Ethereum aceptó el nonce 308, mientras que el endpoint de origen de Unichain aún reporta un nonce de salida máximo de 307 [10].
KelpDAO detectó la anomalía y pausó todos los contratos relevantes en 46 minutos. Esta intervención bloqueó un intento posterior dirigido a 40,000 rsETH adicionales (~$95M) [2]. Pero en ese momento, el atacante ya había pasado a la siguiente etapa: convertir el rsETH robado en activos prestados a través de protocolos de préstamo DeFi.
De Tokens Falsificados a Activos Prestados
El atacante no simplemente vendió el rsETH robado. Los 116,500 tokens fueron dispersados en siete carteras ramificadas y monetizados a través de múltiples canales, incluyendo intercambios directos a ETH mediante agregadores, posiciones de suministro en Compound V3 y re-bridging a Arbitrum [10]. Pero el camino más consecuente pasó por Aave: el atacante depositó 89,567 rsETH (aproximadamente $221 millones) en los mercados de préstamos de Aave en dos cadenas: Ethereum Core y Arbitrum. Usando el E-Mode de Aave, una característica de eficiencia de capital que permite mayores ratios préstamo-valor para activos correlacionados, el atacante tomó prestados 82,620 WETH y 821 wstETH contra el rsETH depositado [3].
Las posiciones estaban apalancadas al máximo. Los factores de salud en las siete direcciones del atacante oscilaban entre 1.01 y 1.03, apenas por encima del umbral de liquidación [3]. Esto fue posible porque el LTV de E-Mode de Aave para rsETH estaba fijado en 93%, con un umbral de liquidación del 95%, dejando un margen de seguridad de solo 2 puntos porcentuales.
El desglose por dirección en ambos mercados:
| Mercado | Dirección | rsETH Suministrado | WETH Prestado | wstETH Prestado |
|---|---|---|---|---|
| Ethereum Core | 0x1f4c...adef |
53,000.00 ($134.71M) | 52,440.58 ($126.13M) | |
| Ethereum Core | 0x8d11...2d49 |
400.00 ($1.02M) | 393.92 ($0.95M) | |
| Arbitrum | 0xeba7...129b |
12,573.80 ($31.93M) | 12,381.93 ($29.45M) | |
| Arbitrum | 0xcbb2...55cc |
9,299.00 ($23.61M) | 4,307.87 ($10.25M) | 8.13 ($23.82K) |
| Arbitrum | 0x1b74...644c |
8,000.00 ($20.33M) | 7,877.92 ($18.95M) | |
| Arbitrum | 0xbb6a...c787 |
770.00 ($1.96M) | 758.25 ($1.80M) | |
| Arbitrum | 0x8d11...2d49 |
1,024.43 ($2.60M) | 28.68 ($0.07M) | 813.11 ($2,382.32K) |
| Arbitrum | 0xe9e2...d181 |
4,500.00 ($11.44M) | 4,431.33 ($10.66M) | |
| Total | 89,567.22 rsETH ($227.61M) | 82,620.49 WETH ($198.25M) | 821.24 wstETH ($2.41M) |
Fuente: datos on-chain agregados de Etherscan, Arbiscan y DeBank a fecha de 2026-04-22 16:51 UTC. Los valores en USD reflejan los precios de los tokens en el momento de cada transacción.
Mejor Auditor de Seguridad para Web3
Valida el diseño, el código y la lógica de negocio antes del lanzamiento
La Cascada: Cómo un Exploit de Puente Congeló WETH en Cinco Cadenas
La figura a continuación resume la cascada completa. Los pasos 1 y 2 (el exploit del puente y el depósito de garantía en Aave) se tratan en la sección de Antecedentes anterior. El resto de esta sección examina los pasos 3 al 5 en detalle: por qué fue necesario congelar WETH, qué parámetros determinaron la gravedad de la cascada y cuál fue el coste real de la congelación.
Por Qué Fue Necesario Congelar WETH
El 19 de abril, el Guardián de Protocolo de Aave congeló todos los mercados de rsETH y wrsETH en Aave V3 y V4, impidiendo nuevos depósitos y préstamos contra garantías en rsETH [8]. Esta fue la primera respuesta esperada.
El segundo paso inesperado llegó el 20 de abril: Aave congeló las reservas de WETH en Ethereum, Arbitrum, Base, Mantle y Linea [3, 8].
¿Por qué congelar WETH, un activo que no fue explotado y no tiene nada que ver con los puentes cross-chain? Porque el atacante había depositado rsETH que fue acuñado sin ningún respaldo correspondiente en la cadena de origen. El oráculo de Aave continuó valorando estos tokens a su valor de mercado completo, tratándolos como garantía legítima indistinguible de rsETH correctamente bridgeado. El atacante aprovechó esta asimetría de información para tomar prestado WETH real contra una garantía que, a nivel del sistema, representaba pasivos sin respaldo. Esto drenó WETH de los pools de préstamos, llevando la utilización al 100% en los mercados afectados. Con utilización plena, los depositantes existentes de WETH no pueden retirar, y los liquidadores no pueden recibir el activo subyacente necesario para ejecutar liquidaciones. El mecanismo de liquidación, la principal defensa del protocolo contra la deuda incobrable, quedó efectivamente paralizado [3].
Si el préstamo de WETH permanecía abierto, la liquidez restante del pool en otras cadenas podría ser drenada mediante el mismo mecanismo: depositar rsETH, tomar prestado WETH, y retirarse. Congelar WETH no era opcional. Era la única forma de limitar el daño.
Tres Parámetros que Determinaron la Cascada
La gravedad de esta cascada no fue accidental. Tres parámetros del protocolo determinaron tanto el daño directo como el alcance de la congelación resultante.
1. LTV: Cuánto activo sano puede extraer cada unidad de garantía contaminada
El LTV de E-Mode de Aave para rsETH era del 93%, lo que significa que cada dólar de rsETH contaminado depositado podía tomar prestado $0.93 de WETH. Para contexto, Spark Protocol fijó el LTV de rsETH en 72% durante el mismo período, y Fluid en aproximadamente 75% [3]. El parámetro de Aave era el más agresivo del mercado.
Esta fue una decisión de diseño deliberada, no un descuido. En enero de 2026, la gobernanza de Aave elevó el LTV de E-Mode para rsETH del 92.5% al 93%, comprimiendo aún más el ya escaso margen de seguridad del 2.5% al 2% [3]. El LTV base (sin E-Mode) se fijó intencionalmente cerca de cero (0.05%), forzando efectivamente todo el préstamo significativo de rsETH a través de la ruta de E-Mode de alto LTV.
2. Profundidad del pool: Cuán vulnerable es cada mercado al drenaje de liquidez
La misma cantidad en dólares de préstamo tiene impactos vastamente diferentes dependiendo de la profundidad del pool objetivo.
| Cadena | Mercado | Reserva de WETH (pre-ataque) | Préstamo del Atacante | Ratio de Drenaje Directo |
|---|---|---|---|---|
| Ethereum | V3 Core | $5.98B | 52,834.50 WETH (~$127M) | ~2.1% |
| Arbitrum | V3 | $331M | 29,785.98 WETH (~$71M) | ~21.5% |
| Mantle | V3 | $109M | N/A | Sin actividad del atacante; WETH congelado preventivamente |
| Base | V3 | $204M | N/A | Sin actividad del atacante; WETH congelado preventivamente |
| Linea | V3 | $33M | N/A | Sin actividad del atacante; WETH congelado preventivamente |
El atacante depositó rsETH únicamente en mercados de Aave V3. Aave V4 (solo Ethereum, lanzado el 2026-03-30) también fue objeto de la congelación preventiva de rsETH [8] pero no se refleja en esta tabla. Datos de reservas de WETH de LlamaRisk [3]; préstamos del atacante derivados del desglose por dirección anterior.
El atacante concentró los préstamos en Ethereum Core y Arbitrum. Pero la observación crítica es lo que ocurrió en las cadenas que el atacante nunca tocó. Dado que rsETH era aceptado como garantía en Mantle, Base y Linea, cualquier posición de usuario existente respaldada por rsETH en esas cadenas conllevaba un riesgo latente de deuda incobrable una vez que el respaldo del puente subyacente quedó comprometido. La decisión de Aave de congelar preventivamente WETH en las cinco cadenas fue una respuesta racional: dejar estos mercados abiertos los habría expuesto al mismo mecanismo de drenaje que el atacante ya había demostrado en Ethereum y Arbitrum [3, 8].
3. Número de despliegues cross-chain: Hasta dónde se propaga la congelación
rsETH estaba listado como garantía en 11 de los 23 mercados de Aave V3, con 7 mostrando exposición material [3]. El atacante operó en solo 2 cadenas. Pero la congelación preventiva de WETH afectó al menos 5 cadenas, incluidos mercados donde el atacante nunca depositó un solo token. El LTV determina cuánto se extrae por cadena; la profundidad del pool determina con qué severidad se tensiona cada mercado. Pero es el número de cadenas donde rsETH fue aceptado como garantía lo que en última instancia decidió hasta dónde se propagó la congelación.
Estos parámetros no son estáticos. Nueve días antes del exploit, el 9 de abril, el Administrador de Riesgo de Aave elevó los límites de suministro de rsETH: Ethereum Core de 480,000 a 530,000, y Mantle de 52,000 a 70,000 [3]. Si bien esto no implica causalidad (el cronograma de preparación del atacante probablemente antecede estos cambios), subraya cómo los ajustes rutinarios de parámetros pueden ampliar inadvertidamente el radio de daño de un incidente futuro.
El Impacto Real de la Congelación
El resultado: un exploit de puente de $290M llevó a congelaciones de liquidez de WETH en cinco cadenas, afectando mercados con reservas combinadas que superan los $6.7 mil millones.
Las pérdidas directas se limitaron a los préstamos del atacante. Pero en los préstamos DeFi, una congelación no es un inconveniente operativo menor. Bloquea la liquidez de los usuarios, impide los retiros, interrumpe las posiciones activas y deteriora los mecanismos de liquidación que protegen al protocolo de la deuda incobrable. La gran mayoría de los usuarios afectados nunca habían interactuado con rsETH, KelpDAO ni ningún puente cross-chain. Eran depositantes y prestatarios de WETH en Aave, participantes en lo que razonablemente entendían como un mercado de préstamos sencillo.
WETH es el activo de liquidez más fundamental de DeFi. Congelarlo es el equivalente a cerrar los retiros en el banco más grande de la ciudad porque una institución financiera diferente, que utiliza un producto del que la mayoría de los depositantes nunca ha oído hablar, fue defraudada.
El informe de incidente de LlamaRisk [3] modeló dos escenarios de deuda incobrable con proyecciones de déficit por cadena, proporcionando el análisis de propagación de riesgo más detallado disponible. Pero incluso este análisis se centró en la deuda incobrable potencial, no en los costes operativos más amplios de la propia congelación, incluidos los retiros bloqueados, las posiciones interrumpidas y la capacidad de liquidación deteriorada en todos los mercados afectados. Una cuantificación exhaustiva del impacto total en cascada sigue siendo un problema abierto.
Si la cascada del ataque fue compleja, la recuperación ha demostrado no ser más sencilla. La componibilidad limita la reparación del mismo modo que habilita el daño. Aave no podía simplemente "descongelar todo." Cada mercado debía evaluarse de forma independiente, con diferentes perfiles de riesgo dependiendo de la exposición local a rsETH, los niveles de utilización de WETH y la actividad del atacante. La cronología cuenta la historia:
- 19 de abril: El Guardián de Protocolo congeló todas las reservas de
rsETHywrsETHen Aave V3 y V4 [8]. - 20 de abril:
WETHcongelado en Ethereum, Arbitrum, Base, Mantle y Linea [3, 8]. - 21 de abril:
WETHdescongelado únicamente en Ethereum Core V3, con el LTV manteniéndose en 0 como medida preventiva. ElWETHen Ethereum Prime, Arbitrum, Base, Mantle y Linea permaneció congelado [8].
Cuatro días después del exploit, cinco de los seis mercados afectados permanecen congelados. La ruta de recuperación refleja la ruta del ataque en complejidad: protocolo a protocolo, cadena a cadena, con cada paso requiriendo coordinación de gobernanza y evaluación de riesgos.
La Respuesta: Cómo Arbitrum Movió 30,766 ETH Sin la Firma del Titular
Mientras Aave gestionaba la cascada de préstamos, se desarrollaba una respuesta paralela en Arbitrum. El 21 de abril, el Consejo de Seguridad de Arbitrum anunció que había tomado medidas de emergencia para congelar 30,766 ETH en poder del explotador en Arbitrum One [6]. Los fondos fueron transferidos a una dirección intermediaria congelada (0x...0DA0), accesible solo a través de una acción posterior de gobernanza de Arbitrum [7].
La Acción de Gobernanza
El Consejo de Seguridad de Arbitrum es un componente formal de la estructura de gobernanza de la DAO de Arbitrum, no un actor externo ni un comité ad hoc. La acción de emergencia fue anunciada públicamente a través del foro de gobernanza de Arbitrum [7], ejecutada con información de las fuerzas del orden respecto a la identidad del explotador [6], y documentada con detalles completos de la transacción. El Consejo de Seguridad actuó dentro de su mandato establecido, sopesando "su compromiso con la seguridad e integridad de la comunidad Arbitrum sin impactar a ningún usuario o aplicación de Arbitrum" [6].
Esta no fue una decisión tomada a puerta cerrada. Fue una acción de emergencia sancionada por la gobernanza, ejecutada de forma transparente, con evidencia on-chain verificable por cualquiera.
El Mecanismo Técnico
Lo que hace notable esta acción no es la decisión de gobernanza, sino cómo se ejecutó on-chain. Basándose en el análisis de traza de Phalcon de BlockSec [9], el Consejo de Seguridad empleó un enfoque atómico de tres pasos:
-
El Ejecutor de Actualización actualizó temporalmente el contrato inbox de Ethereum (
DelayedInbox), añadiendo una nueva función llamadasendUnsignedTransactionOverride. -
Esta función se utilizó para crear un mensaje cross-chain que suplantaba la dirección del explotador. El mensaje fue inyectado a través de
Bridge.enqueueDelayedMessageconkind=3, que se corresponde conL1MessageType_L2Messageen la pila Nitro de Arbitrum. Este tipo de mensaje permite la ejecución deL2MessageKind_UnsignedUserTxen L2. Fundamentalmente, esta ruta no requiere verificación de firma. El parámetro del remitente fue desplazado de la ruta estándarmsg.sendera una entrada controlada por el llamador, transformada a través del aliasing de direcciones L1→L2 para llevar el contexto de dirección del explotador. -
Después de que la transferencia se ejecutó en L2, el contrato inbox fue restaurado a su implementación original.
La transacción L1 [4] y la transacción L2 resultante [5] son ambas públicamente visibles en Phalcon Explorer. Lo que la transacción L2 muestra como "del explotador a 0x...0DA0" no es una transferencia estándar firmada por el usuario. Es una transición de estado forzada a nivel de cadena, una transacción que movió activos sin la clave privada del propietario, ejecutada a través de los poderes de actualización de infraestructura a nivel de gobernanza.
El Dilema
El mecanismo es sencillo en principio: los contratos actualizables otorgan capacidad ilimitada. Si un contrato puede ser actualizado, su comportamiento puede cambiarse para hacer cualquier cosa, incluida la transferencia de activos sin la firma del titular. Esta capacidad es inherente a cualquier sistema construido sobre contratos actualizables. Los 30,766 ETH ahora se encuentran en una dirección congelada. Solo una votación posterior de gobernanza de Arbitrum puede determinar su disposición. El patrón atómico de actualización-ejecución-restauración no dejó ningún cambio permanente en el contrato inbox, y ningún otro usuario o aplicación se vio afectado [6].
Comienza con Phalcon Explorer
Profundiza en las Transacciones para Actuar con Sabiduría
Pruébalo gratis ahoraLa acción del Consejo de Seguridad de Arbitrum fue, según la mayoría de evaluaciones razonables, la decisión correcta. El explotador fue identificado como un actor patrocinado por un estado. Las fuerzas del orden estuvieron involucradas. El proceso de gobernanza fue público. Y $71 millones en activos robados fueron recuperados, o al menos se impidió que fueran lavados más.
Pero la capacidad que hizo esto posible se extiende más allá de este caso específico. El mismo mecanismo de actualización-ejecución-restauración podría, en principio, utilizarse para mover cualquier activo en poder de cualquier dirección en Arbitrum One. El poder del Consejo de Seguridad no se limita a las direcciones de explotadores o fondos robados. Es una capacidad de propósito general limitada por las normas de gobernanza, no por el código.
Este es el dilema. Los usuarios interactúan con las L2 bajo un modelo mental implícito: "mis activos están controlados por mi clave privada, y nadie puede moverlos sin mi firma." El incidente de KelpDAO demuestra que este modelo es incompleto. En Arbitrum, y en cualquier L2 con contratos de puente actualizables y un Consejo de Seguridad, los activos pueden ser movidos a través de acciones de gobernanza que omiten completamente las verificaciones de firma.
Arbitrum no es único en este sentido. Las congelaciones de mercado de Aave también son acciones de emergencia impulsadas por la gobernanza. Durante el incidente de KelpDAO, múltiples protocolos ejercieron simultáneamente poderes de emergencia centralizados: Aave congeló mercados en cinco cadenas, el Consejo de Seguridad de Arbitrum ejecutó una transferencia forzada, y KelpDAO pausó contratos globalmente. La respuesta a la crisis del ecosistema "descentralizado" fue, en la práctica, un ejercicio coordinado de autoridad centralizada.
La pregunta no es si deben existir poderes de emergencia. El caso de KelpDAO presenta un argumento convincente de que deberían existir. La pregunta es si los límites, las condiciones de activación y los mecanismos de responsabilidad para estos poderes son suficientemente transparentes. Los usuarios que depositan activos en una L2 deberían poder responder una pregunta básica: ¿en qué circunstancias puede el Consejo de Seguridad mover mis fondos, y qué recurso tengo?
Estado Actual de los Fondos Robados
El rastreo on-chain independiente (visualización completa en MetaSleuth [11]) muestra al atacante distribuyendo los 116,500 rsETH en siete direcciones de primer salto, suministrando la mayor parte como garantía en Aave (Ethereum Core y Arbitrum) para tomar prestados WETH y wstETH, y consolidando los fondos en una dirección compartida 0x5d39...7ccc en ambas cadenas (Ethereum / Arbitrum). A fecha de 2026-04-22 05:42 UTC, los fondos robados se encuentran en cuatro estados distintos:
| Estado | Cantidad | Ubicación | Detalle |
|---|---|---|---|
| Congelado | 30,765.67 ETH | 0x0000...0da0 en Arbitrum |
Transferido forzosamente por el Consejo de Seguridad de Arbitrum el 2026-04-21 a las 03:35:08 UTC, sin firma, ejecutado a través de la actualización de gobernanza sendUnsignedTransactionOverride |
| Interceptado en el puente | 3,575.57 rsETH |
LZMultiCall 0x8e60...286e en Arbitrum |
Intento de transferencia cross-chain fallido el 2026-04-18 a las 18:30:31 UTC |
| Inactivo | 25,701.76 ETH | 0xd4b8...1530 en Ethereum |
Recibido el 2026-04-21 a las 11:16 UTC, sin movimiento desde entonces |
| Dispersado o dispersándose | ~50,000 ETH | 0xf980...0b85 y 0x62c7...c64e en Ethereum, distribuyéndose a 103 direcciones únicas de primer salto |
0xf980...0b85 dispersó ~25,000 ETH entre el 2026-04-21 08:05 y las 20:21 UTC, luego transfirió sus últimos 8.989 ETH directamente a 0x62c7...c64e; 0x62c7...c64e comenzó su propia dispersión a las 20:13 UTC y aún estaba activo a las 2026-04-22 05:41 UTC |
Aproximadamente el 31% de los fondos están congelados o interceptados, el 23% permanece inactivo en una única dirección de Ethereum inactiva, y el 46% ha sido dispersado, o está siendo dispersado actualmente, en 103 direcciones de primer salto. El rsETH publicado como garantía en Aave permanece depositado, y el WETH y wstETH prestados no han sido reembolsados: el atacante ha abandonado la posición de préstamo.
Conclusión
El incidente de KelpDAO traza una cadena causal que atraviesa tres capas de la arquitectura "descentralizada".
Comenzó con una dependencia de punto único. La configuración DVN de 1 de 1 de KelpDAO redujo la verificación cross-chain a una única entidad, haciendo que todo el puente fuera explotable a través de un único componente de infraestructura comprometido. La arquitectura admitía la descentralización; la configuración no.
La componibilidad convirtió entonces un exploit de puente en una crisis de liquidez a nivel de sistema. Un único ataque congeló WETH, el activo más fundamental de DeFi, en cinco cadenas, afectando miles de millones de dólares en liquidez en poder de usuarios sin ninguna conexión con rsETH o KelpDAO. El alcance de la cascada fue moldeado por parámetros medibles: configuraciones agresivas de LTV, pools de liquidez poco profundos y amplio despliegue de garantías cross-chain.
La escala de la crisis, a su vez, obligó a la gobernanza descentralizada a ejercer poderes de emergencia centralizados. El Consejo de Seguridad de Arbitrum movió 30,766 ETH sin la firma del titular a través de una actualización de contrato atómica sancionada por la gobernanza. Aave congeló mercados en múltiples cadenas a través de acciones de emergencia impulsadas por la gobernanza. La respuesta fue efectiva, transparente y posiblemente necesaria. También fue una demostración de que "sin permiso" tiene límites prácticos.
La dependencia de punto único habilitó el exploit; la componibilidad amplificó el daño; el daño reveló el poder centralizado que siempre estuvo ahí, incorporado en contratos actualizables y marcos de gobernanza. Abordar estas dinámicas vinculadas requiere acción de todos los participantes:
Para los protocolos: La seguridad general de un protocolo está determinada por su eslabón más débil, que en este caso fue la infraestructura DVN y no los contratos inteligentes [10]. La seguridad efectiva requiere cobertura sistemática en múltiples dimensiones, incluidas la seguridad del código, la seguridad de la infraestructura, la gestión de claves y la seguridad operativa. Las evaluaciones integrales y las pruebas de penetración deben someter a prueba de estrés toda la pila, no componentes individuales de forma aislada. El monitoreo on-chain permite respuestas de emergencia en minutos en lugar de horas, y el rastreo rápido de fondos cross-chain es esencial para coordinar congelaciones de activos y maximizar la recuperación. Para los protocolos de préstamo específicamente, la garantía de activos sintéticos cross-chain debe someterse a pruebas de estrés frente a un escenario de "compromiso total de la garantía" con los tres parámetros discutidos anteriormente: LTV, profundidad del pool y número de despliegues cross-chain.
Para la gobernanza de L2 y las DAOs: Los poderes de emergencia deben ser transparentes y responsables. La mayoría de las principales L2s ya tienen estas capacidades, pero a menudo están enterradas en documentación técnica en lugar de estar presentes en los materiales dirigidos al usuario. Los marcos de gobernanza deben codificar las condiciones de activación, las limitaciones de alcance, las restricciones de tiempo y los requisitos de responsabilidad post-acción.
Para los usuarios: Comprender el riesgo sistémico inherente a la componibilidad de DeFi. En este incidente, los depositantes de WETH que nunca tocaron rsETH tuvieron su liquidez congelada en cinco cadenas. El riesgo de la posición individual es solo una parte del panorama; los protocolos, pools, tipos de garantías y cadenas con las que interactúan sus activos forman todos una superficie de riesgo interconectada.
Referencias
[1] LayerZero Core, "Declaración sobre el Incidente de KelpDAO": https://x.com/LayerZero_Core/status/2046081551574983137
[2] KelpDAO, "Incidente del 18 de Abril: Contexto Adicional": https://x.com/KelpDAO/status/2046332070277091807
[3] LlamaRisk, "Informe de Incidente rsETH" (20 de abril de 2026): https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580
[4] BlockSec Phalcon Explorer, Transacción L1 (acción del Consejo de Seguridad de Arbitrum): https://app.blocksec.com/phalcon/explorer/tx/eth/0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770
[5] BlockSec Phalcon Explorer, Transacción L2 (transferencia forzada de Arbitrum): https://app.blocksec.com/phalcon/explorer/tx/arbitrum/0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b
[6] Arbitrum, "Acción de Emergencia del Consejo de Seguridad": https://x.com/arbitrum/status/2046435443680346189
[7] Foro de Gobernanza de Arbitrum, "Acción de Emergencia del Consejo de Seguridad 21/04/2026": https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803
[8] Aave, actualizaciones del incidente rsETH (19-21 de abril de 2026): https://x.com/aave/status/2045593585966252377
[9] BlockSec Phalcon, "Análisis de congelación del Consejo de Seguridad de Arbitrum": https://x.com/Phalcon_xyz/status/2046467830498173088
[10] banteg, "Investigación del camino Kelp rsETH Unichain → Ethereum": https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62
[11] MetaSleuth, rastreo del exploit de KelpDAO: https://metasleuth.io/result/eth/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222?source=600c61cd-f0cd-4dff-8687-14e02f6ccd24
