THORChain: hack de 10,8 M$ y un halt de 13 horas

El 15 de mayo de 2026, un solo nodo malicioso reconstruyó la clave privada de una bóveda de THORChain y drenó unos 10,8 millones de dólares repartidos en nueve cadenas a la vez. No hubo manipulación de oráculo ni bug de contrato inteligente: el atacante rompió la propia criptografía que reparte el control de los fondos entre decenas de validadores. Lo verdaderamente notable llegó después. El protocolo que durante años se presentó como «imparable» detuvo sus firmas en cuestión de minutos y congeló la red entera durante casi 13 horas mediante una decisión coordinada de gobernanza, garantizando cero pérdidas para los usuarios finales sin acuñar un solo RUNE nuevo. Y dejó una pregunta incómoda servida en bandeja: si un puñado de operadores puede apagarlo todo en minutos, ¿hablamos de descentralización real o de un punto central de control con buen marketing?

¿Qué pasó exactamente con THORChain el 15 de mayo?

THORChain es un protocolo de liquidez de cadena cruzada (cross-chain): permite intercambiar, por ejemplo, Bitcoin nativo por Ethereum nativo sin pasar por un exchange centralizado y sin envolver el activo en un token sintético. Los fondos que hacen posible cada swap viven en unas reservas que el protocolo llama bóvedas Asgard.

El 13 de mayo, un operador entró al conjunto de validadores con un nodo preparado para atacar. Durante dos días, ese nodo participó en las ceremonias de firma normales del protocolo mientras filtraba, poco a poco, fragmentos de la clave que controla una de las bóvedas. El 15 de mayo ya tenía suficiente material para reconstruir la clave privada completa de esa bóveda —que custodiaba aproximadamente una quinta parte de todos los fondos del protocolo— y firmar transferencias de salida válidas él solo.

El resultado: unos 10,8 millones de dólares salieron de la bóveda en nueve cadenas distintas (Bitcoin, Ethereum, BNB Chain, Base, Avalanche, Dogecoin, Litecoin, Bitcoin Cash y XRP) sin que ningún sistema de defensa pudiera frenar las firmas a tiempo, porque a ojos del protocolo esas firmas eran legítimas. El atacante tenía la llave real.

¿Qué es una bóveda Asgard y cómo se reparte su llave?

Imagina una caja fuerte cuya puerta no se abre con una sola llave, sino con varias repartidas entre decenas de personas; hace falta que un número mínimo de ellas pongan su llave a la vez. Nadie puede abrirla solo, y si una persona desaparece, la caja sigue funcionando con las demás. Eso es, conceptualmente, una bóveda Asgard: el control no está en un custodio único, sino repartido entre muchos operadores de nodos.

La tecnología que lo hace posible se llama firma de umbral (TSS, por threshold signature scheme): cada nodo guarda solo un fragmento de clave (key share), nunca la clave entera, y se necesita un cuórum de fragmentos para autorizar cualquier salida de fondos. La clave privada completa, en teoría, no existe en ningún ordenador en ningún momento — se reconstruye matemáticamente solo durante el instante de la firma y desaparece.

La promesa de seguridad es contundente: aunque un atacante comprometa un nodo, o varios, no obtiene nada útil mientras no alcance el cuórum. Por eso el caso de THORChain es tan llamativo. El atacante no reunió el cuórum: engañó a los nodos honestos para que le fueran entregando, ronda a ronda, los pedazos que le faltaban.

¿Cómo rompió el atacante una firma de umbral sin reunir el cuórum?

THORChain implementa la firma de umbral con una variante propia (un fork) de la librería tss-lib de Binance, que aplica el protocolo criptográfico conocido como GG20. Ahí está la grieta.

Según el análisis independiente del investigador de seguridad Banteg, el fork de THORChain omitió una comprobación de seguridad que el diseño original sí exige: cuando un nodo se une, debe demostrar matemáticamente —con una prueba que no revela ningún secreto— que los parámetros criptográficos que aporta están bien formados. Es una verificación de «solidez» sobre un componente llamado módulo de Paillier. En la receta estándar es obligatoria; en la versión modificada de THORChain, no se ejecutaba.

La analogía: pensemos en las ceremonias de firma como reuniones donde cada participante mete su pedazo de secreto dentro de una caja con candado y la pasa a los demás para un cálculo conjunto, confiando en que la caja de cada uno es de verdad y no una trampa. La prueba de solidez es el guardia que revisa que la caja de cada participante es legítima antes de dejarle entrar. THORChain quitó al guardia. El atacante se presentó con una «caja» manipulada y, cada vez que los nodos honestos metían su pedazo dentro para colaborar en una firma, esa caja trucada le filtraba una pizca del secreto de cada uno.

Repetido durante dos días y muchas rondas de firma, ese goteo —los investigadores lo describen como filtración progresiva de material de clave— bastó para que el atacante acumulara las piezas que le faltaban y reconstruyera por sí solo la clave privada completa de la bóveda. A partir de ahí, las firmas malintencionadas eran indistinguibles de las legítimas: tenían la llave auténtica.

El matiz importante es que no fue un fallo de la idea de firma de umbral, sino de una implementación que recortó una salvaguarda. Es deuda criptográfica: una librería compleja, un fork sin la cobertura de pruebas completa, y un detalle omitido que durante años nadie explotó hasta que alguien lo hizo.

¿A cuánto ascendió el botín y cómo se repartió por cadena?

El atacante consolidó los fondos en un puñado de direcciones. En las cadenas compatibles con Ethereum, casi todo el botín fue a parar a la dirección 0x82fc0d…54eb; en Bitcoin, a bc1ql4u…6f37. El reparto aproximado del valor extraído:

El nodo malicioso operaba desde la dirección de validador thor16ucjv…cn84q. A diferencia del caso de Echo en Monad —donde el atacante acuñó 77 millones nominales pero solo pudo monetizar 816.000 dólares porque no había liquidez para vender—, aquí el daño nominal y el daño real coinciden: el atacante no necesitaba un mercado donde vender nada. Sacó activos reales y canjeables directamente de la bóveda. Por eso los 10,8 millones se perdieron de verdad, sin el «cortafuegos accidental» de la iliquidez.

¿Cómo logró THORChain detenerse en minutos?

El sistema de defensa de THORChain monitoriza constantemente una cosa muy simple: lo que el protocolo cree que tiene frente a lo que realmente hay en cada cadena externa. Es una verificación automática de solvencia, una especie de arqueo de caja permanente. Cuando los saldos reales empezaron a caer sin operaciones legítimas que lo justificaran, las alertas saltaron solas: pocos minutos después del inicio del drenaje, esa verificación hizo que la capa de comunicación con las cadenas externas (Bifrost) dejara de firmar transacciones automáticamente, sin que ningún humano apretara un botón. Eso protegió las bóvedas que aún no estaban comprometidas.

Lo que vino después ya no fue automático, sino humano y coordinado. Los validadores se organizaron por sus canales de comunicación, confirmaron el vector del ataque y, en cuestión de horas, llegaron a un consenso para hacer un halt coordinado: congelar por completo el estado de la red. Un halt es exactamente lo que suena — apagar la máquina de consenso para que no procese absolutamente nada, ni un solo swap. La congelación duró 12 horas y 42 minutos (de los bloques 26190429 a 26191149), el tiempo que los desarrolladores necesitaron para compilar, probar y desplegar un parche de emergencia, thornode v3.18.1, que tapaba la filtración.

¿Cómo se recuperó el dinero sin emitir RUNE nuevo?

Aquí THORChain hizo algo que merece reconocerse: resolvió un agujero de 10,8 millones sin imprimir tokens. La tentación habitual tras un hack es acuñar activo nativo nuevo para tapar el hueco, lo que diluye a todos los tenedores y suele hundir el precio en espiral. THORChain lo prohibió expresamente en su plan de recuperación, la propuesta de gobernanza ADR-028.

El plan repartió el golpe en este orden:

• Primero, la POL. La POL (liquidez de propiedad del protocolo, protocol-owned liquidity) es el capital que el propio protocolo posee en sus pools, a diferencia del que aportan los usuarios. Funciona como el colchón de reservas de la casa. Esas reservas absorbieron la primera tanda de pérdidas, agotándose con prioridad para no tocar a nadie más.
• Después, los tenedores de sintéticos. El déficit residual que la POL no cubrió se distribuyó entre los synth holders (tenedores de activos sintéticos del protocolo), no entre los proveedores de liquidez tradicionales.
• Reposición sin dilución. Para rellenar la POL con el tiempo, el protocolo redirige una fracción de los ingresos futuros de los swaps a reconstruir esas reservas. No se acuña ni se vende RUNE nuevo en ningún momento.
• Castigo al atacante. El protocolo confiscó (slashed) la totalidad de la fianza en RUNE que el validador malicioso había depositado para poder operar, a la vez que protegía a los validadores honestos que compartían bóveda y no tuvieron nada que ver.

Para los usuarios minoristas directamente afectados, se habilitó un portal de recuperación con 10 millones de dólares de la tesorería y un plazo de 21 días —hasta el 4 de junio de 2026— para revocar aprobaciones maliciosas y reclamar compensación. El resultado final fue cero pérdida para los usuarios finales: quien tenía fondos en THORChain los recuperó.

¿Es esto descentralización real o un punto central de apagado?

Esta es la pregunta editorialmente interesante, y no tiene respuesta cómoda. THORChain se ha vendido durante años como una infraestructura neutral e imparable, que no censura transacciones y que no puede ser apagada por nadie. El 15 de mayo, un grupo coordinado de operadores la apagó entera en horas.

Las dos lecturas son legítimas y opuestas:

La lectura optimista: un sistema descentralizado que puede pararse a sí mismo ante una emergencia, sin un CEO ni un comité central que dé la orden, y resolver el daño internamente sin perjudicar a sus usuarios, es más robusto, no menos. La detención inicial fue automática; la congelación, fruto de un consenso entre operadores independientes — autorregulación descentralizada funcionando en vivo, justo lo que el sector necesita demostrar mientras crecen las presiones regulatorias en EE. UU. para someter el DeFi a supervisión.

La lectura crítica: si un cuórum de validadores puede congelar la red, reescribir quién asume las pérdidas y abrir un portal de compensación, entonces ese cuórum es un punto de control. Hoy lo usaron para algo bueno; la misma capacidad sirve para censurar una transacción incómoda o ceder ante una orden judicial. El protocolo es «imparable» hasta que sus operadores deciden lo contrario.

La verdad práctica es que casi todo el DeFi de relevancia tiene este botón en alguna parte, aunque su marketing diga que no. El mérito de THORChain es haberlo usado con transparencia y a favor del usuario. El riesgo de fondo es que el botón existe, y quien lo controla importa tanto como el código que se audita.

¿Por qué THORChain es un objetivo tan recurrente?

El exploit no llega en el vacío. THORChain arrastra una reputación pesada: por su filosofía de neutralidad y resistencia a censurar, su liquidez ha servido de lavadero a grupos vinculados a Corea del Norte. Está confirmado que movió parte de los 1.500 millones de dólares robados a Bybit en 2025, atribuido al grupo Lazarus — el contexto que desarrollamos en nuestro análisis sobre si la pasividad de THORChain ante fondos ilícitos es complicidad o código neutral.

Y el incidente forma parte de una racha brutal. Solo en abril de 2026 las pérdidas por exploits en el sector superaron los 600 millones de dólares, con casos como el de KelpDAO (292 millones) y Drift (285 millones). La constante de 2026 es la misma que venimos documentando: el eslabón débil rara vez es la lógica del contrato auditado; es la capa de gobernanza, las claves y, como aquí, la criptografía de la propia infraestructura cross-chain.

¿Qué puede vigilar el lector en vivo tras este caso?

Un exploit de esta naturaleza es un dato congelado: ocurrió, se parcheó, se contó. Lo que cambia día a día es el riesgo que sigue vivo alrededor de la liquidez cross-chain. Tres comprobaciones con datos en tiempo real, en vez de fiarte de una captura de hace semanas:

• El peg de los wrappers de Bitcoin. THORChain mueve BTC nativo entre cadenas, pero buena parte del BTC que circula por el DeFi es BTC envuelto. Comprueba en vivo si los principales wrappers de Bitcoin mantienen su paridad 1:1 o se están desviando en nuestro monitor de wrappers de BTC.
• El riesgo comparado de los puentes. El vector de este hack es, en el fondo, el riesgo de toda infraestructura cross-chain. Antes de mover fondos entre cadenas, compara modelos de seguridad y trayectoria de los puentes en nuestro comparador de puentes.
• La salud de las stablecoins y de los wrappers de ETH que tocan estos mismos puentes, en el monitor de stablecoins y el monitor de wrappers de ETH.

¿Qué quedan como lecciones del caso?

El exploit de las bóvedas Asgard deja tres conclusiones. La técnica: la criptografía de umbral es tan fuerte como su implementación más débil — un fork que recorta una sola prueba de solidez convierte una salvaguarda matemática en una puerta abierta durante años, y auditar los contratos no basta si nadie audita la librería de firma con el mismo rigor. La operativa: la velocidad de respuesta importó más que la prevención; THORChain no evitó el robo, pero lo contuvo en minutos y lo resolvió con cero pérdidas para el usuario, sin diluir su token. Y la más incómoda: el mismo poder que salvó a los usuarios el 15 de mayo es un punto de control que contradice el relato de «imparable». RUNE cayó entre un 12 % y un 15 % en las 24 horas siguientes, no por el dinero perdido —era recuperable— sino por esa contradicción. La próxima vez que un protocolo cross-chain te diga que nadie puede apagarlo, la pregunta correcta no es si es verdad. Es: ¿y si pudieran, querrías que no pudieran?

Fuentes y enlaces: THORChain · Documentación de THORChain (ADR-028) · Rekt.news (cobertura de exploits) · tss-lib (Binance) · Etherscan (rastreo on-chain) · THORChain Network (dashboard)