KelpDAO + LayerZero: $292M Por Un Fallo De DVN
$292 millones. Un mensaje falsificado. Un firmante en quien el puente nunca debió confiar solo.
Así, a lo tonto y sin que nadie se enterara de la misa la mitad, el chiringuito de KelpDAO, que operaba su puente de rsETH encima de LayerZero, se marcó una chapuza de narices. Resulta que LayerZero les dio un botoncito mágico, la dichosa configuración DVN —o sea, Red de Verificadores Descentralizada, tócate las narices— y los de KelpDAO, ni cortos ni perezosos, la pusieron en '1'. ¿Qué significa eso? Pues que un solo verificador, una única firma, un mensajito entre blockchains, y listo el pollo. El 1 de junio, vaya fecha, un hacker con más arte que el que diseñó la movida, le metió mano a la llave de ese firmante único. Ni corto ni perezoso, el fulano forjó un mensaje de retirada de dinero desde la bóveda de KelpDAO en Ethereum hacia LayerZero, y salió pitando con 92.000 rsETH. ¿En pasta? Pues ni más ni menos que unos 292 millones de dólares al cambio de ese día. Al final, lo de "descentralizado" del DVN era más cuento que otra cosa, una frase de marketing para vender la moto. La firma, eso sí, era más real que los problemas en el paraíso.
El Esquema
El modelo de seguridad de LayerZero permite que cada protocolo elija el número de verificadores independientes (DVNs) que deben firmar cada mensaje cross-chain. KelpDAO eligió uno. La llave de firma de ese único DVN fue comprometida — phishing, dispositivo robado, el post-mortem aún no lo dice — y el atacante la usó para falsificar un mensaje 'release rsETH' que el Endpoint de LayerZero aceptó sin pedir una segunda opinión. 92.000 rsETH fueron acuñados a un address controlado por el atacante en Ethereum, dumpeados en stETH y ETH, y lavados a BTC vía THORChain en menos de cuatro horas.
DVN significa Red Descentralizada de Verificadores. KelpDAO corría uno. Uno no es descentralizado. Uno es centralizado, con capucha.
Serie: Exploits de Puentes
Diferentes puentes, misma autopista. Cómo la infraestructura cross-chain falla — por una clave filtrada o un mensaje fabricado.
El Puente Que Tenía Un Portero Y Confiaba En Él
El pitch de LayerZero es ingenioso: en vez de un modelo único de seguridad que cada protocolo herede, cada app elige el suyo. Más DVNs, más gas pero más firmas independientes. Menos DVNs, menos gas y más confianza. La arquitectura está bien. El default está bien. Las configuraciones que los protocolos realmente despliegan — ahí vive el dinero.
KelpDAO lanzó rsETH en Ethereum y se expandió a Arbitrum, Optimism y Base vía LayerZero. Para ahorrar gas y enviar más rápido, el equipo puso el conteo requerido de DVNs en 1 — un único verificador (el DVN default de LayerZero Labs) tenía que firmar cada retiro a Ethereum. Sin redundancia. Sin segunda opinión. Una firma, una asunción de confianza, una llave privada en una pieza de infraestructura.
El 1 de junio de 2026, 14:22 UTC, esa llave firmó un mensaje que KelpDAO nunca envió. El mensaje autorizaba un retiro en Ethereum de 92.000 rsETH al address 0x4a7b…d931. El Endpoint de LayerZero verificó la firma, llamó al contrato de bóveda de KelpDAO, y el contrato obedientemente transfirió los rsETH. A las 14:24 UTC el atacante estaba haciendo swaps. A las 18:11 UTC las ganancias estaban en una billetera Bitcoin vía THORChain.
No fue un bug de contrato. Fue un campo de config puesto en '1' el día que una llave fue phisheada.
Por Qué 1-de-1 Es Lo Mismo Que Ninguno-de-Ninguno
Un 'verificador' que no tiene un par con quien estar en desacuerdo no está verificando nada — está firmando. El sentido completo de los esquemas multi-firma es que ninguna llave, ningún host, ningún humano pueda mover dinero solo. En el momento en que pones N en 1, conviertes un protocolo criptográfico en un problema de gestión de llaves. Los problemas de gestión de llaves le pierden al phishing cada trimestre del año, año tras año.
La documentación de LayerZero advierte sobre esto explícitamente. Su página de seguridad recomienda un mínimo de dos DVNs independientes y al menos un verificador 'opcional' de respaldo. Publican una tabla mostrando qué configuraciones son 'rápidas/baratas' vs 'seguras'. KelpDAO eligió 'rápida/barata' en una bóveda que, en su pico, contenía $1.4B. La advertencia estaba en los docs. Los docs no son el despliegue.
El daño se detuvo en $292M porque la bóveda de rsETH no contenía todo — la mayor parte del TVL de KelpDAO estaba en las estrategias subyacentes de restaking en EigenLayer, sobre las que el puente no tenía autoridad. El atacante tomó la capa líquida. La capa profunda sobrevivió. Pequeñas misericordias en una historia con muy pocas.
Dos firmantes es un quorum. Un firmante es un punto único de falla con una 'D' pintada al frente.
Vocabulario Decodificado: 'Verificador Descentralizado' vs Un Tipo Con Una Llave
Lo que prometía la marca LayerZero vs lo que la config de KelpDAO realmente requería:
"Red Descentralizada de Verificadores (DVN)"
Lo que parece:
Una red de verificadores independientes, cada uno corriendo su propia infraestructura, firmando mensajes de forma independiente. Descentralizado en el sentido de que ningún partido único puede producir un mensaje válido de puente por sí solo.
Lo que realmente pasó:
KelpDAO requería exactamente una firma DVN. La 'red' tenía un participante para los propósitos de KelpDAO. La palabra 'descentralizada' describía el sistema que LayerZero construyó; el campo 'requiredDVNCount = 1' describía el sistema que KelpDAO realmente desplegó. El atacante explotó el segundo.
"Auditado por [REDACTED] en Q1 2026"
Lo que parece:
Firma de seguridad independiente revisó los contratos, la integración del puente, y la configuración de despliegue. Listo para producción.
Lo que realmente pasó:
La auditoría revisó el código. La configuración DVN se establece en despliegue y no es código — es un parámetro pasado al Endpoint. Los auditores marcaron el setup 1-de-1 con severidad 'media' recomendando elevarlo antes de mainnet. Fue 'reconocido'. No fue cambiado.
"Hack de $292M" (todos los titulares)
Lo que parece:
LayerZero fue hackeado. O KelpDAO fue hackeado. O alguien encontró un zero-day de Solidity de $292M.
Lo que realmente pasó:
Los contratos de LayerZero se comportaron exactamente como están especificados. La bóveda de KelpDAO se comportó exactamente como está especificada. Una llave privada controlada por un único operador de DVN fue comprometida, y el puente ejecutó fielmente el mensaje que esa llave firmó. Es un incidente de gestión de llaves disfrazado de exploit de contrato.
Los contratos funcionaron. La firma era válida. El 'verificador' era una persona. Esa es toda la historia.
Cómo Una Sola Llave Comprometida Drenó Toda Una Bóveda
El ataque tenía cuatro partes y el atacante solo tuvo que aterrizar una. Las otras tres eran decisiones de configuración que KelpDAO ya había tomado meses antes:
Paso 1: Phish Al Operador Del DVN
La llave comprometida pertenecía a un ingeniero junior de infraestructura del operador DVN. El vector exacto sigue bajo investigación, pero el reporte interino de Chainalysis apunta a una notificación falsa de Slack → página de credenciales → token de sesión del dispositivo → acceso a KMS en la nube. Desde ahí, la llave no fue exfiltrada; el atacante simplemente firmó dentro del entorno del operador durante 90 minutos.
Si la seguridad de tu puente depende de que un ingeniero nunca haga click en un DM de Slack, tu puente depende de que las leyes de probabilidad aguanten mejor de lo que aguantan jamás.
Paso 2: Forjar El Mensaje LayerZero
Usando la llave comprometida, el atacante construyó un payload de Endpoint de LayerZero desde Arbitrum → Ethereum: 'release 92.000 rsETH a 0x4a7b…d931, nonce 18742, GUID 0xabc…'. La firma validó. El DVN posteó el mensaje. La bóveda de Ethereum vio una instrucción cross-chain debidamente firmada y la ejecutó.
El contrato hizo su trabajo perfectamente. El puente hizo su trabajo perfectamente. Ambos trabajos los definía una sola firma que nunca debió ser suficiente.
Paso 3: Drenar A stETH Y ETH
92.000 rsETH llegaron a la billetera del atacante. En dos minutos, 60.000 se desempaquetaron a stETH vía la cola de redención de KelpDAO (que se ejecutó al instante porque la cola no tenía límite de velocidad), 25.000 se cambiaron a ETH en 1inch a través de Curve y Uniswap V3, y 7.000 quedaron como rsETH porque la liquidez se agotó.
Los límites de velocidad son la defensa más barata en ingeniería de puentes. KelpDAO no tenía ninguno en el camino de redención de rsETH. El atacante no necesitó paciencia. Necesitó un solo bloque.
Paso 4: Lavado Cross-Chain A Bitcoin
El ETH y stETH se enrutaron por THORChain en 11 swaps por lotes a lo largo de las siguientes 3h 47min. Destino final: bc1q…f4e2, una billetera Bitcoin recién fondeada que no se ha movido desde. BTC recibidos: ~3.720 BTC al precio del momento.
THORChain. Siempre THORChain. El off-ramp favorito del lavado cross-chain sigue siendo el titular que nadie en THORChain quiere escribir una respuesta a.
Cadena Técnica: De Slack Phisheado A Billetera Bitcoin
Reconstruido de datos on-chain, el reporte de LayerZero, el post-mortem de KelpDAO, y los hallazgos interinos de Chainalysis:
T-72h: El Phish Aterriza
29 de mayo, 2026: una notificación falsa de Slack llega a un ingeniero de infraestructura del operador DVN. Parece una alerta de CI. Click → página de credenciales → token de sesión capturado. El atacante tiene acceso de sesión vivo a herramientas internas.
La llave hardware del ingeniero fue bypaseada porque la sesión capturada ya estaba autenticada. No se solicitó segundo factor porque la sesión ya lo tenía. FIDO2 protege el login. No protege una sesión robada.
T-24h: Reconocimiento
El atacante pasa un día dentro del entorno del operador DVN, mapeando infraestructura de firmas. Identifican qué llave KMS se usa para qué cadena, qué protocolos usan qué DVN, y cuáles son 1-de-1.
KelpDAO emergió en este reconocimiento porque cada config DVN de LayerZero es pública on-chain. El atacante no necesitó conocimiento interno; cruzaron una config pública con acceso interno robado.
T+0: Mensaje Falsificado Posteado
1 de junio, 2026, 14:22 UTC: el atacante usa el contexto de firma comprometido para firmar un payload del Endpoint autorizando un retiro de 92.000 rsETH en Ethereum. El DVN postea el mensaje. El Endpoint acepta. La bóveda ejecuta.
Una llamada LayerZero. Una firma. Una ejecución de contrato. Tiempo total de phish a drenaje: menos de 72 horas. La ventana entre compromiso y explotación se reduce cada trimestre.
T+2 min: Drenaje Comienza
92.000 rsETH llegan a 0x4a7b…d931. El atacante encola al instante una redención de 60.000 (instantánea — sin límite), cambia 25.000 a través de Curve y Uniswap V3 en un bundle, y deja los 7.000 restantes para después (el 'después' nunca llegó — la liquidez era tan delgada que más dumps costarían más de lo que devolverían).
Bots MEV front-ranearon algunos swaps, comiéndose unos $4M. KelpDAO no recuperó nada de eso — la ganancia MEV fue a los searchers, no al protocolo. El atacante aún netteó ~$285M tras slippage.
T+3h 47min: Liquidación En BTC
Todas las ganancias puenteadas vía THORChain en 11 swaps. Liquidadas a bc1q…f4e2 como BTC nativo. La billetera no se ha movido desde. Sin coin-join; sin depósitos a exchanges.
Mismo patrón THORChain que Hyperbridge, IoTeX y otros cuatro hacks de puentes de 2025-26. La vía de salida está establecida. Las contramedidas no.
72 horas desde un email de phishing hasta una billetera Bitcoin. La parte más lenta fue esperar las confirmaciones de THORChain.
Evidencia On-Chain: Las Transacciones Que Hicieron El Daño
Lo que dice la blockchain, en orden cronológico. Cada address truncado por seguridad:
LayerZero Endpoint receive(srcChainId=110 [Arbitrum], srcAddress=0x…KelpDAO, nonce=18742, payload=releaseRsETH(0x4a7b…d931, 92_000e18), guid=0xabc…). Una firma DVN: válida. requiredDVNCount = 1. Executor llamó KelpDAOVault.handleMessage().
Traducción: 'Aquí hay una instrucción debidamente firmada desde Arbitrum que dice liberar 92.000 rsETH a este address.' 'OK, liberando.' '¿No quieres preguntarle a nadie más?' 'No, solo preguntamos a un verificador. Dijo sí.'
El Endpoint se comportó exactamente como está configurado. La firma DVN era criptográficamente válida. La bóveda ejecutó la instrucción que le dieron. Todo bajo la capa de aplicación funcionó. La capa de aplicación requería N=1.
Tx 1: KelpDAO.requestRedemption(60_000) — ejecutada al instante (sin delay). Tx 2: ruta 1inch 25_000 rsETH → 23_840 ETH vía Curve+Uniswap V3, slippage 4.6%. Tx 3: unwrap de stETH en Lido (60_000). Sandwich MEV en Tx 2: ~$4.1M extraídos.
Traducción: golpear cada salida a la vez, tomar lo que escape, aceptar el haircut, seguir. Los caminos del contrato existían. Los límites de velocidad no.
Tres caminos de salida en paralelo en 90 segundos. Una cola de redención de 6 horas habría hecho que el exploit fallara ruidosamente con fondos aún recuperables. KelpDAO no tenía cola. La asunción de diseño era que el puente no produciría mensajes fraudulentos; el diseño no asumió que el puente lo haría pero contendría el daño igualmente.
11 swaps secuenciales en 3h 47min: ETH → BTC, stETH → ETH → BTC. Volumen total puenteado: ~$289M post-slippage. Destino final: bc1q…f4e2. Sin coin-join. Sin mezclador. Camino directo.
Traducción: el dinero robado entra a un DEX cross-chain permissionless, sale como Bitcoin en una sola billetera, espera. Misma vía de salida que otros cuatro hacks de puente que hemos cubierto. El patrón sigue siendo el patrón.
THORChain no hace preguntas. Hasta que los grandes exchanges centralizados bloqueen depósitos de addresses conocidos de salida de THORChain en horas en vez de días, este off-ramp seguirá absorbiendo cada paga de hack de puente.
Señales De Alerta Que La Propia Documentación De KelpDAO Ya Advertía
- •requiredDVNCount = 1 en una bóveda con nueve cifras — La propia documentación de LayerZero marca configuraciones de DVN único como 'usar bajo tu propio riesgo'. El riesgo de KelpDAO fue $292M. La configuración encajó.
- •Sin límite de velocidad en la redención de rsETH — Una cola de redención de 6 horas habría contenido el 80% del daño. KelpDAO eligió redención instantánea para competir en UX. El atacante les dio las gracias.
- •Auditoría marcó 1-de-1 DVN como 'severidad media' — Los auditores lo vieron. Lo escribieron. Recomendaron subir el conteo DVN. La recomendación fue 'reconocida'. Reconocer no es remediar.
- •Infra del operador DVN tenía tokens de sesión válidos cruzando MFA — Las llaves hardware FIDO2 protegen logins. No protegen sesiones ya autenticadas. Las herramientas internas deberían re-solicitar confirmación hardware en cada operación de firma. Esta no lo hacía.
- •Config pública de LayerZero exponía cada despliegue 1-de-1 de antemano — Las configs DVN son on-chain. Los atacantes pueden enumerar cada protocolo corriendo 1-de-1 parseando estado público. KelpDAO estaba en esa lista. Decenas más también.
Cada señal de alerta era una frase en los docs de LayerZero. KelpDAO leyó las frases. KelpDAO desplegó igual.
Los Números: Qué Costó Cada Decisión De Config
La brecha entre 'rápido/barato' y 'seguro' tarifada en dólares el 1 de junio de 2026:
92.000 rsETH — Total Drenado
Aproximadamente el 38% del float de rsETH en Ethereum en el momento del ataque. Valor: ~$292M al precio del día de $3.175/rsETH.
~$285M — Botín Neto Del Atacante Tras Slippage
Tras slippage de Curve/Uniswap V3, pérdidas por sandwich MEV (~$4.1M), y fees de THORChain (~$2.8M). Los ~$285M restantes liquidaron en una sola billetera Bitcoin.
$0 — Costo Para KelpDAO De Subir requiredDVNCount A 2
Añadir un segundo DVN habría subido el gas por mensaje en ~$0.40 por transferencia cross-chain. Anualizado al volumen de KelpDAO: ~$180.000. La pérdida de $292M compró un descuento de ~1.600x sobre una característica que ya existía.
~$4.1M — Ganancia MEV Durante El Drenaje
Searchers MEV sandwicharon el swap del atacante en Uniswap V3, extrayendo valor que el protocolo no podía recuperar. Incluso durante un hack, MEV es el socio silencioso del protocolo.
Por Qué Los Puentes Siguen Enviando Configuraciones 1-De-1
El incidente de KelpDAO no es único. El razonamiento que lo produjo es deprimentemente estándar:
El Gas Acumula, La Seguridad No
Cada firma DVN adicional cuesta ~$0.40 por mensaje cross-chain. Multiplica por volumen diario, multiplica por 365, y la línea es visible en el burn rate. La línea de 'seguridad' — pérdidas por DVN comprometido — es invisible hasta el día en que deja de serlo, y ese día empequeñece cada ahorro de gas combinado.
Los puentes optimizan la variable que pueden medir. La variable que no pueden medir es el tamaño de la pérdida que aún no han tenido.
Los Defaults Son Menores Que Las Recomendaciones
Los docs de LayerZero recomiendan dos o tres DVNs para bóvedas sobre $50M. El default en sus ejemplos de SDK es uno. La mayoría de equipos copia el ejemplo, lo envía, y encuentra tiempo de endurecer 'después'. El 'después' llega el día del post-mortem.
Cada config de ejemplo que no coincide con defaults de producción es un futuro reporte de incidente esperando suceder a alguien que no eres tú.
Los Auditores Marcan Configs Como 'Medio' Porque No Son Código
Las auditorías asignan severidad basadas en el contrato. Una mala config no es un bug del contrato — es una perilla mal puesta. Los auditores la marcan, rara vez como 'Crítica', porque el contrato está bien. El protocolo archiva el hallazgo bajo 'revisión de config' y envía. Después la perilla se dispara.
Un hallazgo de auditoría de severidad media que cuesta $292M no es severidad media. Es Crítico con un sombrero educado.
Por Qué El Titular Dice LayerZero Y El Bug Es KelpDAO
Cada recap de este hack listará a LayerZero en el titular. La verdad es menos pegadiza y más útil:
El Reconocimiento De Marca Distribuye La Culpa
LayerZero es la marca que más lectores reconocen. KelpDAO es el protocolo que eligió la config. El sistema funcionó como lo especificó el protocolo que lo integró. El titular culpa al chasis, no al conductor. Ambos son parcialmente correctos. El conductor eligió la configuración del chasis.
Arquitecturas De Seguridad Compartida Distribuyen Responsabilidad Sin Distribuir Visibilidad
Cuando LayerZero envía un modelo de seguridad flexible, cada integrador elige cuánta seguridad activar. Los usuarios no ven esas elecciones. Ven 'powered by LayerZero' y asumen paridad de seguridad. La flexibilidad es para los constructores. El riesgo aterriza en los usuarios.
Los Holders De rsETH Asumieron La Pérdida
El respaldo de rsETH cayó de ~1.00 a ~0.81 ETH por token en 10 minutos del drenaje. Cualquiera que tuviera rsETH en ese momento comió un haircut del 19%. KelpDAO desde entonces se ha comprometido a un plan de reembolso parcial durante 18 meses, fondeado de los fees del protocolo. Los números sugieren recuperación total para 2028 — asumiendo que el TVL aguante.
EigenLayer No Fue Afectado
Las posiciones subyacentes de restaking de KelpDAO en EigenLayer no fueron tocadas. El exploit quedó confinado a la capa del puente rsETH. La cobertura mainstream rutinariamente confundió 'hack de KelpDAO' con 'hack de EigenLayer' durante las primeras seis horas. No son lo mismo.
LayerZero envió el puente configurable. KelpDAO envió la configuración. El atacante envió las consecuencias.
Cómo Protegerte Del Próximo DVN 1-De-1
Los puentes seguirán enviando configuraciones agresivas. La única pregunta es si tus fondos están dentro de uno cuando la config falla:
- Regla 1: Revisa la config DVN de cualquier protocolo LayerZero que uses Las configs DVN de LayerZero son públicas on-chain. Herramientas como LayerZeroScan muestran requiredDVNCount por app. Si el número es 1, trata al protocolo igual que tratarías un multisig con un solo firmante.
- Regla 2: Prefiere tokens de restaking líquido con colas de redención con límite de velocidad Una cola de redención de 6-24 horas es molesta para usuarios y devastadora para atacantes. Si un protocolo anuncia 'retiros instantáneos' en una bóveda con nueve cifras, la conveniencia tiene precio.
- Regla 3: No mantengas tokens envueltos o restakeados en tamaño a menos que entiendas el modo de falla del puente Si no puedes nombrar el conteo de verificadores, el límite de velocidad, y el peor escenario de pérdida, no entiendes qué estás teniendo. Reduce posición o muévete a nativo.
- Regla 4: Vigila protocolos cuyas auditorías marcan hallazgos de 'config' como aceptados-sin-remediación Los reportes de auditoría listan qué hallazgos fueron arreglados y cuáles 'reconocidos'. 'Reconocido' en un hallazgo medio o superior es bandera amarilla. 'Reconocido' en un hallazgo de config atado a seguridad de puente es bandera roja.
- Regla 5: Pasa cualquier invitación a puente desconocido por nuestro Detector de Estafas gratuito DMs relacionados a puentes, mensajes falsos de 'actualización de seguridad' en Telegram, y clones falsos de DApps son staple de 2026. Si una URL o contrato se siente extraño, pégalo en nuestro detector antes de firmar nada.
¿Recibiste un Mensaje Sospechoso?
Usa nuestro detector con IA para analizar posibles estafas al instante.
Conclusiones Clave
- 1KelpDAO corrió su puente rsETH a través de LayerZero con requiredDVNCount = 1 — un único verificador podía autorizar cualquier mensaje cross-chain. La llave de firma del único verificador fue comprometida el 1 de junio de 2026.
- 292.000 rsETH (~$292M) fueron drenados en un solo mensaje LayerZero que el puente ejecutó fielmente. Los contratos se comportaron correctamente. La configuración era la vulnerabilidad.
- 3Los fondos fueron drenados vía redención instantánea + swaps en 1inch en menos de 4 minutos, luego lavados a ~3.720 BTC a través de THORChain en 3h 47min.
- 4La documentación de LayerZero recomienda explícitamente dos o más DVNs para bóvedas de alto TVL. La auditoría de KelpDAO marcó el setup 1-de-1 como severidad media. El hallazgo fue reconocido pero no remediado.
- 5Los holders de rsETH asumieron un haircut de respaldo del ~19% en 10 minutos del drenaje. KelpDAO se ha comprometido a un plan de reembolso parcial durante 18 meses fondeado de fees del protocolo.
- 6Antes de usar cualquier activo respaldado por puente: revisa la config DVN pública, prefiere protocolos con redención con límite de velocidad, y trata los hallazgos de auditoría 'reconocidos' sobre config de puente como banderas rojas, no amarillas.
Un verificador, una llave, una firma.
Doscientos noventa y dos millones de dólares. La 'D' en DVN era de decoración.
Preguntas Frecuentes
Fuentes y Citas
Investigación compilada de datos de blockchain disponibles públicamente, informes de seguridad y documentación de la comunidad.
layerzero.network
peckshield.com
www.chainalysis.com
etherscan.io
Verificación: Todas las transacciones y direcciones de blockchain referenciadas en este artículo pueden verificarse de forma independiente a través de los exploradores de blockchain enlazados. Animamos a los lectores a realizar su propia verificación.
Metodología: Cada caso requiere al menos tres fuentes independientes más evidencia on-chain verificable antes de publicarse. Estándares completos: /es/methodology
Aviso legal: Esta investigación es periodismo y educación en seguridad, no asesoramiento legal ni una acusación de conducta delictiva. Cuando se nombran empresas, proyectos, dominios o carteras, describimos lo que muestran los registros públicos, los datos on-chain y los informes citados en el momento de la redacción — no una resolución judicial. Los nombres de empresas pueden aparecer porque fueron suplantadas por estafadores, no porque hicieran algo indebido. Las personas están anonimizadas. Si crees que algo aquí es inexacto o está desactualizado, escribe a cryptostrapon@proton.me y lo corregiremos registrando el cambio. Política editorial
Más Alertas de Estafas
Sigue aprendiendo sobre amenazas cripto
Hyperbridge $1.2B DOT Falso: Mint Function Sin Control
Exploit de Puente • 2026-05-28
Un modificador de control de acceso ausente permitió mintear $1.2B de DOT sin respaldo en Ethereum vía Hyperbridge. Cronología y evidencia on-chain.
Hackeo Puente CrossCurve: $3M Robados en 15 Min [2026]
Exploit de Puente • 2026-03-10
Un mensaje falso. Cero validación. $3M drenados en 3 cadenas en una sola transacción. La auditoría pasó — el puente no. Flujo del exploit completo.
Hackeo Puente IoTeX: 1 Clave Filtrada Drenó $8.8M [2026]
Exploit de Puente • 2026-03-05
Una clave filtrada. $8.8M en minutos. El puente ioTube sin protección. Cronología y cómo verificar si tus tokens fueron afectados.