Dilema de descentralización: Riesgo de cascada y poder de emergencia en la crisis de KelpDAO

Escrito por: BlockSec

Puntos clave: La brecha de puente de KelpDAO de 290 millones de dólares provocó una reacción en cadena, congelando más de 6.700 millones de dólares en liquidez de WETH en cinco cadenas, afectando a usuarios que nunca habían interactuado con rsETH. Este evento también revela los límites prácticos de los sistemas “permissionless”: el Consejo de Seguridad de Arbitrum, mediante una autorización de gobernanza, actualizó un contrato atómico para realizar una conversión forzada de estado, transfiriendo 30,766 ETH sin necesidad de firma del poseedor.

El 18 de abril de 2026, el puente cross-chain de rsETH de KelpDAO fue atacado, con una pérdida aproximada de 290 millones de dólares, convirtiéndose en el mayor incidente de seguridad en DeFi de este año. La investigación preliminar apunta al Lazarus Group, un grupo de ataque de nivel estatal con antecedentes comprobados de ataques a infraestructura criptográfica [1]. Este ataque no explotó vulnerabilidades en contratos inteligentes, sino que mediante la inyección de RPC en un nodo de verificación descentralizado (DVN) comprometido, falsificó mensajes cross-chain y, sin destrucción en la cadena fuente, liberó tokens rsETH.

LayerZero [1] y KelpDAO [2] han proporcionado detalles sobre el ataque. Este artículo aborda otro ángulo: en lugar de repetir el proceso del ataque, examina qué ocurrió después: cómo una dependencia en infraestructura de punto único provocó la congelación de decenas de miles de millones en liquidez en cinco cadenas, y cómo esta cascada forzó a los marcos de gobernanza descentralizados a ejercer poderes centralizados en vista pública.

La cadena causal del incidente de KelpDAO atraviesa tres niveles del stack tecnológico “descentralizado”: la dependencia en DVN de punto único hizo posible el ataque; la composabilidad de DeFi (el “Lego DeFi”, donde los protocolos encajan como bloques) convirtió la vulnerabilidad del puente en una crisis sistémica de liquidez; y la escala de la crisis, a su vez, expuso el ejercicio de poderes centralizados en el marco de gobernanza.

Contexto: Resumen del ataque a KelpDAO

KelpDAO es el emisor de rsETH. rsETH es un token de liquidez de re-pledge (LRT), que representa posiciones de staking en ETH distribuidas en múltiples operadores. Para facilitar la circulación cross-chain de rsETH, KelpDAO integró el protocolo de mensajes LayerZero. Este protocolo depende de DVN (red de verificación descentralizada) para verificar la legitimidad de los mensajes cross-chain antes de su ejecución en la cadena destino.

Configuración clave: La app de rsETH de KelpDAO usa una configuración DVN 1-de-1, confiando únicamente en el DVN operado por LayerZero Labs como único validador. Esto significa que toda la seguridad cross-chain de rsETH depende de una única entidad de validación. La documentación de LayerZero recomienda explícitamente usar configuraciones con múltiples DVN redundantes, y LayerZero informó a KelpDAO antes del incidente que esta era la mejor práctica [1]. KelpDAO respondió que la configuración 1/1 es “la que está documentada en LayerZero y que se publica como configuración predeterminada para nuevos despliegues OFT”, además de que “en la expansión a L2 se confirmó como adecuada” [2].

El atacante comprometió dos nodos RPC utilizados por el DVN de LayerZero, reemplazando sus archivos binarios por versiones maliciosas. Estos nodos maliciosos solo devolvían datos falsificados del estado en cadena para la IP del DVN, mientras que a todos los demás observadores (incluyendo la infraestructura de monitoreo de LayerZero) parecían normales. Simultáneamente, un ataque DDoS dirigido a los nodos RPC no comprometidos provocó una conmutación por error a los nodos infectados. Como resultado, el DVN confirmó un mensaje cross-chain que nunca ocurrió en la cadena fuente, sin destrucción correspondiente en la cadena origen, y en la interfaz de Ethereum (0x85d4…8ef3) se liberaron 116,500 rsETH [1, 3]. La transacción de liberación fue 0x1ae232…db4222. La evidencia en cadena es clara: el endpoint de destino en Ethereum aceptó un nonce 308, mientras que el nonce máximo reportado por el endpoint fuente de Unichain seguía siendo 307 [10].

KelpDAO detectó la anomalía en 46 minutos y pausó todos los contratos relacionados. Esto evitó un ataque posterior que habría drenado otros 40,000 rsETH (aproximadamente 95 millones de dólares) [2]. Pero en ese momento, los atacantes ya estaban en otra fase: mediante protocolos DeFi de préstamo, convirtieron los rsETH robados en activos prestables.

De tokens falsificados a activos prestados

Los atacantes no vendieron directamente los rsETH robados. Los 116,500 tokens se dispersaron en siete wallets, y se monetizaron a través de varias vías, incluyendo intercambios directos por ETH, posiciones en Compound V3 y puentes a Arbitrum [10]. Pero la vía más impactante fue Aave: los atacantes depositaron 89,567 rsETH (unos 221 millones de dólares) en los mercados de préstamo en Ethereum y Arbitrum. Aprovechando la función E-Mode de Aave (que permite mayor eficiencia de préstamo para activos relacionados), los atacantes usaron rsETH como colateral para tomar prestados 82,620 WETH y 821 wstETH [3].

Estas posiciones estaban altamente apalancadas. Los factores de salud de los siete addresses del atacante oscilaban entre 1.01 y 1.03, apenas por encima del umbral de liquidación [3]. Esto fue posible porque la LTV en E-Mode para rsETH en Aave está configurada en 93%, con un umbral de liquidación del 95%, dejando un margen de seguridad de solo 2 puntos porcentuales.

Detalles de las posiciones en los dos mercados:

Tabla 1: Detalles de la provisión de rsETH y los préstamos en WETH/wstETH de los atacantes en Aave

Fuente: datos en cadena, combinando Etherscan, Arbiscan y DeBank, al 22-04-2026 16:51 UTC. El valor en USD refleja los precios en el momento de cada transacción.

Efecto en cascada: cómo una vulnerabilidad en el puente congeló WETH en cinco cadenas

El diagrama a continuación muestra la cadena completa del efecto en cascada. Los pasos 1 y 2 (vulnerabilidad en el puente y depósito en Aave) ya se explicaron en la sección previa. Aquí se analizan en profundidad los pasos 3 a 5: por qué fue necesario congelar WETH, qué parámetros determinaron la gravedad de la cascada y cuál fue el costo real de la congelación.

Figura 1: Flujo en cascada desde la vulnerabilidad en el puente hasta la congelación de WETH en cinco cadenas

Por qué fue necesario congelar WETH

El 19 de abril, el Guardian del protocolo de Aave congeló todos los mercados de rsETH y wrsETH en Aave V3 y V4, prohibiendo nuevas colocaciones y préstamos con rsETH como colateral [8]. Este fue el primer paso esperado en la respuesta.

El segundo paso, inesperado, ocurrió el 20 de abril: Aave congeló las reservas de WETH en Ethereum, Arbitrum, Base, Mantle y Linea [3, 8].

¿Por qué congelar WETH? Porque es un activo no atacado, sin relación con el puente cross-chain. Los rsETH depositados fueron creados sin respaldo en activos en la cadena fuente. La oráculo de Aave continúa valorando estos tokens a precios de mercado completos, considerándolos como colateral válido indistinguible del rsETH legítimo. Los atacantes aprovecharon esta asimetría informativa para tomar préstamos sin respaldo real, usando WETH como garantía. Esto drenó WETH de los pools de préstamo, alcanzando una utilización del 100%. Con la utilización al máximo, los depositantes de WETH no pueden retirar y los liquidadores no pueden ejecutar liquidaciones, paralizando la protección contra malos créditos [3].

Si se permitiera seguir tomando WETH, otros pools en diferentes cadenas también serían drenados mediante el mismo mecanismo: depositar rsETH, tomar WETH y salir. La congelación de WETH no es una opción, sino la única medida para limitar el daño.

Parámetros que determinaron la cascada

La gravedad de la cascada no fue casual. Tres parámetros del protocolo determinaron la magnitud del daño directo y el alcance de la congelación.

1. LTV: cuánto puede extraer de un colateral contaminado por unidad

La LTV en E-Mode para rsETH en Aave está en 93%, lo que significa que por cada dólar de rsETH contaminado depositado, se puede tomar prestado 0.93 dólares en WETH. En comparación, la LTV de rsETH en Spark Protocol es 72%, y en Fluid aproximadamente 75% [3]. La configuración de Aave es la más agresiva del mercado.

Este diseño fue deliberado, no un descuido. En enero de 2026, la gobernanza de Aave aumentó la LTV en E-Mode de rsETH del 92.5% al 93%, reduciendo aún más el margen de seguridad de 2.5% a 2%. La LTV en modo no E-Mode se estableció intencionadamente cerca de cero (0.05%), forzando que toda la actividad significativa de préstamo en rsETH pase por la vía de alta LTV en E-Mode.

2. Profundidad del pool: vulnerabilidad de cada mercado ante extracción de liquidez

La misma cantidad de préstamo tiene impactos diferentes según la profundidad del pool objetivo.

Tabla 2: Tamaño de reservas WETH en mercados Aave V3 en diferentes cadenas y porcentaje de extracción directa del atacante

El atacante solo depositó rsETH en Aave V3. La versión V4 (solo en Ethereum, en línea desde marzo de 2026) también tiene congelación preventiva de rsETH [3], pero no se refleja aquí. Los datos de reservas WETH provienen de LlamaRisk [8]; los datos de préstamos del atacante, de la tabla anterior.

El atacante se concentró en Ethereum y Arbitrum. Pero lo importante es lo que ocurrió en las cadenas no tocadas por el atacante. Debido a que rsETH fue aceptado como colateral en Mantle, Base y Linea, si se destruyen los respaldos en esas cadenas, las posiciones existentes con rsETH como colateral enfrentan riesgo de insolvencia. La decisión de congelar WETH preventivamente en las cinco cadenas fue razonable: mantener abiertas esas plataformas las expondría a la misma mecánica de extracción que ya fue validada en Ethereum y Arbitrum [3, 8].

3. Número de despliegues cross-chain: alcance de la propagación de la congelación

De los 23 mercados de Aave V3 que aceptan rsETH como colateral, 11 están en la lista, y 7 tienen exposición sustancial [3]. El atacante operó solo en dos cadenas, pero la congelación preventiva de WETH afectó al menos a cinco, incluyendo mercados donde el atacante nunca depositó tokens. La LTV determina cuánto puede extraer en cada cadena, y la profundidad del pool, cuánto impacto recibe cada mercado. Pero la cantidad de cadenas que aceptan rsETH como colateral finalmente define el alcance de la cascada.

Estos parámetros no son estáticos. Nueve días antes del ataque, el 9 de abril, la Risk Steward de Aave aumentó el límite de suministro de rsETH: en Ethereum, de 480,000 a 530,000; en Mantle, de 52,000 a 70,000 [3]. Aunque esto no implica causalidad (el período de preparación del atacante probablemente fue anterior a estos ajustes), muestra cómo cambios en parámetros pueden inadvertidamente ampliar el impacto potencial de eventos futuros.

Impacto real de la congelación

El resultado fue que una vulnerabilidad en el puente de 290 millones de dólares congeló la liquidez de WETH en cinco cadenas, con reservas combinadas en los mercados afectados que superan los 6.700 millones de dólares.

La pérdida directa se limita a los préstamos tomados por los atacantes. Pero en DeFi, la congelación no es solo una interrupción operativa menor: bloquea la liquidez de los usuarios, impide retiros, desorganiza posiciones activas y debilita la capacidad de los protocolos para liquidar malos créditos. La mayoría de los afectados nunca interactuaron con rsETH, KelpDAO o el puente cross-chain. Son depositantes y prestatarios de WETH en Aave, participando en mercados que consideran directos y transparentes.

WETH es el activo de liquidez más fundamental en DeFi. Congelarlo equivale a cerrar la vía de retiro del mayor banco de la ciudad, por una razón: una institución financiera usó un producto que la mayoría de los depositantes nunca ha oído, y fue víctima de un fraude.

El informe de LlamaRisk [3] modela dos escenarios de incumplimiento, con predicciones de shortfall por cadena, siendo el análisis más completo de propagación de riesgo hasta la fecha. Pero incluso este análisis se centra en posibles malos créditos, no en los costos operativos más amplios de la cascada, como bloqueos de retiros, impedimentos en posiciones y debilitamiento de la capacidad de liquidación en los mercados afectados. La cuantificación total del impacto en cascada sigue siendo un tema abierto.

Si la cascada de ataques es compleja, la recuperación tampoco es sencilla. La composabilidad, que agrava la destrucción, también limita la reparación. Aave no puede simplemente “descongelar todo”. Cada mercado requiere evaluación independiente, considerando exposición en rsETH, utilización de WETH y actividad del atacante, enfrentando diferentes riesgos. La línea de tiempo ilustra esto claramente:

19 de abril: Protocol Guardian congela todos los rsETH y wrsETH en Aave V3 y V4 [3].

20 de abril: WETH en Ethereum, Arbitrum, Base, Mantle y Linea se congela [8].

21 de abril: Solo se descongela WETH en Ethereum Core V3, manteniendo LTV en 0 como medida preventiva. En las otras cadenas, WETH sigue congelado [8].

Cuatro días después del ataque, solo un mercado ha sido descongelado. La recuperación sigue un proceso similar al del ataque: paso a paso, por protocolo y cadena, con decisiones de gobernanza y evaluación de riesgos en cada etapa.

Respuesta de emergencia: cómo Arbitrum transfirió 30,766 ETH sin firma del poseedor

Mientras Aave gestionaba la cascada de préstamos, Arbitrum también tomó medidas paralelas. El 21 de abril, el Consejo de Seguridad de Arbitrum anunció una acción de emergencia: congeló los 30,766 ETH en poder del atacante en Arbitrum One [6]. Estos fondos fueron transferidos a una dirección intermedia de congelación (0x…0DA0), y solo podrán ser gestionados mediante una votación de gobernanza posterior [7].

Acción de gobernanza

El Consejo de Seguridad de Arbitrum es parte formal de la estructura de gobernanza de Arbitrum DAO, no un ente externo o comité temporal. La acción de emergencia se anunció públicamente en el foro de gobernanza [7], tras confirmar la identidad del atacante, y se ejecutó con detalles completos de la transacción para su verificación. El Consejo actuó dentro de sus competencias, equilibrando la seguridad y la integridad de la comunidad de Arbitrum, sin afectar a usuarios o aplicaciones [6].

No fue una decisión en secreto, sino una acción autorizada por gobernanza, transparente y pública, con evidencia en cadena clara.

Mecanismo técnico

Lo notable de esta acción no es la decisión en sí, sino cómo se ejecutó en la cadena. Basado en el análisis Phalcon trace de BlockSec [6], el Consejo utilizó un proceso atómico en tres pasos:

El ejecutor de actualización (Upgrade Executor) realizó una actualización temporal del contrato de inbox de Ethereum (DelayedInbox), añadiendo una función llamada sendUnsignedTransactionOverride.

Esta función se usó para crear un mensaje cross-chain que simulaba ser del atacante. El mensaje fue inyectado mediante Bridge.enqueueDelayedMessage, tipo=3, correspondiente a L1MessageType_L2Message en Arbitrum Nitro. Este tipo de mensaje permite ejecutar en L2 un L2MessageKind_UnsignedUserTx. Lo importante: no requiere verificación de firma. El parámetro sender se cambió del estándar msg.sender a una entrada controlada por el llamante, usando un alias de dirección de L1→L2 que lleva la dirección del atacante.

Tras completar la transferencia en L2, el contrato inbox fue restaurado a su versión original.

Las transacciones en L1 [9] y las transacciones L2 resultantes [4] son visibles en Phalcon Explorer. La transacción en L2 aparece como “del atacante a 0x…0DA0”, pero no es una transferencia estándar firmada por un usuario, sino una conversión forzada de estado a nivel de cadena: mediante una actualización autorizada en infraestructura de gobernanza, se transfirieron activos sin la clave privada del propietario.

El dilema de la descentralización

El principio es simple: los contratos actualizables otorgan capacidades ilimitadas. Si un contrato puede ser actualizado, su comportamiento puede ser modificado para hacer cualquier cosa, incluyendo transferir activos sin firma del propietario. Es una capacidad inherente a cualquier sistema construido con contratos actualizables. Los 30,766 ETH están actualmente en una dirección congelada, y solo una futura votación de gobernanza decidirá su destino. La modalidad atómica de actualización-ejecución-restauración no deja cambios permanentes en el contrato inbox ni afecta a otros usuarios o aplicaciones [5].

Desde una evaluación razonable, la acción del Consejo de Seguridad de Arbitrum fue correcta. El atacante fue identificado como actor de nivel estatal, con participación de las autoridades, el proceso de gobernanza fue transparente, y se recuperaron o bloquearon al menos 7 millones de dólares en activos robados.

Pero la capacidad que hizo esto posible no se limita a este caso. La misma mecánica de actualización-ejecución-restauración, en principio, puede usarse para transferir cualquier activo en Arbitrum One. El poder del Consejo no se limita a la dirección del atacante o a los fondos robados; es una capacidad general, regulada por gobernanza, no por código.

Aquí radica el dilema: los usuarios que interactúan con L2 creen que “sus activos están controlados por su clave privada, y nadie puede transferirlos sin su firma”. La respuesta a la emergencia de KelpDAO muestra que ese modelo no es completo. En Arbitrum y en cualquier L2 con contratos de puente actualizables y Consejo de Seguridad, los activos pueden ser transferidos mediante acciones de gobernanza que evaden la firma.

Arbitrum no es un caso aislado. La congelación en Aave también fue una acción de gobernanza de emergencia. En el incidente de KelpDAO, múltiples protocolos ejercieron poderes centralizados: Aave congeló mercados en cinco cadenas, el Consejo de Seguridad de Arbitrum realizó transferencias forzadas, y KelpDAO pausó contratos globalmente. La respuesta a la crisis en este ecosistema “descentralizado” en la práctica fue una coordinación de poderes centralizados.

El problema no es si estos poderes deben existir, sino si sus límites, condiciones de activación y mecanismos de rendición de cuentas son suficientemente transparentes. Los usuarios que depositan en L2 deben poder responder: ¿en qué circunstancias el Consejo puede transferir mis fondos? ¿Qué recursos de reclamación tengo?

Estado actual de los fondos robados

El rastreo independiente en cadena de los fondos robados (visualización completa en MetaSleuth [6]) muestra que los 116,500 rsETH se dispersaron en 7 direcciones principales, la mayoría depositadas en Aave (Ethereum y Arbitrum) como colateral para WETH y wstETH, y los tokens prestados, tras intercambios menores, convergen en una misma dirección 0x5d39…7ccc (Ethereum / Arbitrum). Hasta el 22-04-2026 05:42 UTC, los fondos están en cuatro estados:

Tabla 3: Distribución de los fondos robados en cuatro estados (al 22-04-2026 05:42 UTC)

Aproximadamente el 31% está congelado o interceptado, el 23% permanece en una dirección inactiva en Ethereum, y el 46% ha sido o está en proceso de dispersarse en 103 direcciones secundarias. Los colaterales en rsETH en Aave no han sido rescatados, y los préstamos en WETH y wstETH no han sido devueltos; las posiciones de préstamo están abandonadas.

La cadena causal del incidente de KelpDAO refleja los tres niveles del stack “descentralizado”:

El punto de partida es la dependencia en un único punto. La configuración DVN 1/1 de KelpDAO reduce la verificación cross-chain a un solo ente, permitiendo que toda la puente sea vulnerada por un componente comprometido. Aunque la arquitectura soporta descentralización, la configuración no.

Luego, la composabilidad convirtió la vulnerabilidad en una crisis sistémica de liquidez. Un ataque congeló WETH en cinco cadenas, afectando decenas de miles de millones en liquidez, involucrando a usuarios sin relación con rsETH o KelpDAO. La extensión del impacto se determina por parámetros como la configuración de LTV agresiva, la profundidad de pools y la distribución de colaterales cross-chain.

Finalmente, la escala de la crisis llevó a que la gobernanza ejerciera poderes centralizados: el Consejo de Seguridad de Arbitrum realizó una transferencia forzada, Aave congeló mercados, y KelpDAO pausó contratos. Estas respuestas, aunque efectivas y transparentes, evidencian un ejercicio de poder centralizado en un ecosistema que se presenta como descentralizado.

La dependencia en un punto único posibilita el ataque, la composabilidad amplifica el daño, y la centralización en la respuesta revela poderes incrustados en contratos y gobernanza. La solución requiere acción coordinada de todos los actores:

• Para los protocolos: la seguridad integral depende del eslabón más débil, en este caso, la infraestructura DVN, no los contratos inteligentes [11]. La seguridad efectiva requiere cobertura en múltiples dimensiones: seguridad del código, infraestructura, gestión de claves y operaciones. Monitoreo en cadena y rastreo rápido de fondos son esenciales para responder y maximizar recuperaciones. En préstamos, los colaterales cross-chain deben someterse a pruebas de estrés considerando escenarios de colapso total.

• Para la gobernanza y DAOs: los poderes de emergencia deben ser transparentes y responsables. La mayoría de las cadenas principales ya tienen estas capacidades, pero a menudo están ocultas en documentación técnica. La gobernanza debe definir claramente condiciones, límites, duración y mecanismos de rendición de cuentas.

• Para los usuarios: comprender los riesgos sistémicos inherentes a la composabilidad en DeFi. En este incidente, depositantes de WETH que nunca interactuaron con rsETH quedaron con liquidez congelada en cinco cadenas. El riesgo de una posición individual es solo una parte del panorama; la interacción con protocolos, pools, colaterales y cadenas conforma un riesgo interconectado.

Referencias

[10] LayerZero Core, “Declaración del Incidente KelpDAO”:
[1] KelpDAO, “Contexto adicional del 18 de abril”:
[2] LlamaRisk, “Informe del incidente rsETH” [3] 20 de abril de 2026 (:
) Explorador Phalcon de BlockSec, transacción L1 [4] Acción del Consejo de Seguridad de Arbitrum (:
) Explorador Phalcon de BlockSec, transacción L2 [5] Transferencia forzada en Arbitrum (:
) Arbitrum, “Acción de emergencia del Consejo de Seguridad”:
[6] Foro de Gobernanza de Arbitrum, “Acción de emergencia del Consejo de Seguridad 21/04/2026”:
[7] Aave, actualizaciones del incidente rsETH [8] 19-21 de abril de 2026 (:
) Explorador Phalcon de BlockSec, “Análisis de congelación del Consejo de Seguridad de Arbitrum”:
[9] banteg, “Investigación del camino rsETH Unichain → Ethereum”:
[10] MetaSleuth, rastreo del exploit de KelpDAO: