THORChain pausó todas las operaciones de rotación de bóvedas después de que los desarrolladores descubrieran un problema de consenso que aparece específicamente durante el proceso de “churning”. El equipo de desarrollo de la red reestructuró su hoja de ruta en torno a un solo lanzamiento: la actualización v3.20, que consolida parches de seguridad, la integración con Monero y el despliegue de router V6 en una única actualización coordinada dirigida al despliegue la semana siguiente. La pausa se debe a una vulnerabilidad que exige cambios profundos en Thornode que no pueden llevarse mediante una versión puntual. La consolidación aborda un vacío de seguridad crítico y, al mismo tiempo, limita la cantidad de secuencias de actualización de alto riesgo que la red debe ejecutar, algo especialmente importante dada la capacidad de revisión estirada del equipo de desarrollo.
La rotación de bóvedas representa uno de los mecanismos de seguridad fundamentales de THORChain, y la operación actualmente no está en funcionamiento. Aparece un problema de consenso específicamente durante el proceso de churning, y la solución requiere cambios lo bastante profundos en Thornode como para que una versión puntual no pueda llevarlos. Eso dejó fuera el parche v3.19.4 originalmente planeado, el mismo día en que el equipo lo discutió.
El equipo se reunió para lanzar v3.20, con un objetivo de altura de actualización para la semana siguiente. Una vez que el lanzamiento se publique, el plan es reactivar Solana primero y luego restaurar el churning. Todo lo que originalmente estaba incluido para v3.19.4 — incluido el trabajo con Monero — ahora se integra en ese único lanzamiento más grande junto con el nuevo código del router V6, que ya está listo y se está desplegando progresivamente. Para los usuarios, la experiencia después de la actualización permanece igual: los swaps siguen enrutándose a través de THORChain Swap como de costumbre.
La consolidación no es puramente reactiva. Integrar varias mejoras en un solo lanzamiento coordinado reduce la cantidad de veces que la red debe atravesar una secuencia de actualización de alto riesgo, algo que importa cuando la capacidad de revisión ya está al límite.
El exploit reciente no provino de una sola falla catastrófica. Según Aaluxx, cofundador de Maya Protocol y ahora desarrollador sénior en THORChain, la vulnerabilidad fue una combinación de tres fallos más antiguos que habían coexistido sin problemas en el código base hasta que alguien — o algo — descubrió que podían activarse en secuencia.
“Fueron tres bugs que, encadenados, eran explotables. Cualquiera de ellos por separado era inofensivo”, afirmó Aaluxx.
Describió la mañana en que el exploit se rompió como algo frío. El equipo había fusionado recientemente parches de TSS desde un repositorio privado, y su temor inmediato era que un error en esa fusión hubiera introducido la vulnerabilidad. Una verificación rápida lo descartó: el commit estaba intacto y la causa raíz se remonta a código mucho más antiguo. El equipo, de hecho, había detectado un bug encadenado similar — un potencial doble gasto — solo un par de meses antes, lo que significa que el patrón subyacente ya estaba en el radar.
La detección fue técnicamente elegante. Al factorizar uno de los parámetros criptográficos de la configuración de TSS y buscar números primos pequeños que no deberían estar presentes, los desarrolladores podían identificar si cualquier bóveda dada había sido envenenada. En THORChain, se encontró que una de las cinco bóvedas estaba comprometida, lo que explica por qué se drenó aproximadamente el 20% del TVL en lugar de la cantidad total. El método proporcionó al equipo un diagnóstico fiable en una situación donde la velocidad de triage era crítica.
Aaluxx fue directo sobre la lección más amplia de cara al papel de la IA: un equipo pequeño ahora puede explorar un código base desde muchos más ángulos simultáneamente, lo que es una ventaja defensiva; pero la misma capacidad está disponible para cualquiera que intente encontrar vulnerabilidades desde el exterior. Espera algunos meses más difíciles mientras la industria se adapte a esta nueva realidad.
Durante el aproximadamente mes que THORChain estuvo pausado, Maya Protocol siguió realizando swaps. El mismo bug latente existía en el código de Maya, pero nunca se activó. Más importante aún, Maya ejecutaba una sola bóveda que el equipo podía verificar de forma independiente como sana; así que la mantuvieron operativa mientras pausaban el churning como precaución, ya que un churn podría haber abierto la misma ruta de exploit.
La consecuencia práctica fue real: los swaps nativos de BTC a ETH permanecieron no disponibles en THORChain durante ese período, pero siguieron disponibles en Maya. Ese es el argumento de redundancia hecho tangible.
“Necesitamos hacer volar el jet con dos motores”, afirmó Aaluxx.
Después del exploit y durante el período TCY anterior, algunas voces plantearon fusionar THORChain y Maya — usando RUNE para comprar CACAO y consolidar en un solo DEX más grande. Aaluxx reconoció que habría sido una decisión razonable a nivel de negocio y aun así la rechazó. Dos DEX independientes y sin permisos que comparten los mismos ideales son una elección de diseño deliberada, no una ineficiencia que deban optimizar por fuera. El costo de la redundancia es real, pero también lo es el costo de un único punto de falla.
La limitación que frena la velocidad de lanzamiento de THORChain no es la falta de código. Es la falta de personas calificadas para revisarlo y desplegarlo.
“Nuestro factor limitante no es la creación de código; es revisarlo y desplegarlo”, afirmó Aaluxx.
Actualmente, solo unas tres personas tienen la profundidad de experiencia requerida para revisar y desplegar cambios en THORChain. Agregar más desarrolladores o más pull requests no acelera automáticamente la entrega: añade carga de revisión a un cuello de botella ya estrecho. El equipo opera con una proporción deliberada de dos a uno: cada pieza de código escrita requiere al menos dos revisiones antes de avanzar.
En el lado de la gobernanza, surgió un problema estructural. Como ahora las propuestas llegan de muchos contribuyentes y no de un único organismo coordinador como Nine Realms, los números de ADR han chocado y las ideas preliminares se han presentado como ADR formales antes de estar listas para construirse.
La solución propuesta es separar por completo la etapa de idea de la etapa de ADR. Un ADR, como lo planteó Aaluxx, debería ser ya una receta terminada: concisa, técnica y construible con los recursos disponibles. Lo que falta es un espacio aguas arriba: un tipo de campo de batalla donde las ideas en bruto se desafían, refinan o se descartan antes de calificar para el estatus de ADR.
“Algunas personas piensan que ‘quiero pasta’ es un ADR. Eso no es un ADR, es un problema. Vengan con una receta”, afirmó Aaluxx.
Más adelante, podrían solicitarse y asignarse números de ADR on-chain mediante node relay, y el primer nodo aprobador asignaría el siguiente número secuencial. Eso haría que la propiedad de una propuesta sea inequívoca sin crear un portero centralizado. Un ADR, vale la pena repetirlo, no es un requisito previo para enviar código: cualquiera puede abrir issues y pull requests en GitLab hoy. Un ADR es una prueba de temperatura que le dice a los operadores de nodos si quieren tiempo de desarrollo pagado invertido en algo.
A pesar de la pausa, las integraciones en todo el ecosistema siguieron avanzando. ShapeShift se ha unido ahora a Symbiosis como participante en vivo en el modelo de tarifa dinámica, y los datos que regresan de ambas están resultando útiles. Se espera que tres o cuatro afiliados adicionales se pongan en línea dentro de una semana, a la espera de la disponibilidad de Chad Barraford para completar las integraciones.
Un consejo de la comunidad reabrió dos conversaciones de integración más grandes. Un DM frío a Randy Bechtold sacó a Robinhood Chain como posible objetivo — y una mirada rápida reveló que está construido sobre Arbitrum, una red que THORChain ya estaba persiguiendo. Eso creó una oportunidad de dos por uno: Bechtold tiene una llamada programada con el equipo de Arbitrum y planea pedir una introducción cálida a Robinhood mientras tanto.
Aaluxx ofreció una nota técnica de cautela sobre Arbitrum: funciona aproximadamente con cuatro bloques por segundo, lo que inunda los nodos con volumen de mensajes de una manera similar a Solana. Maya pasó cerca de un año estabilizando su propio soporte para Arbitrum. La ventaja es que gran parte del trabajo pesado ya está hecho del lado de Maya, dándole a THORChain un camino más corto.
La integración de XMR es la función principal más cercana a salir. Aaluxx está en conversaciones con Least Authority para una auditoría de seguridad — una firma que califica entre las mejores para trabajo en cadenas enfocadas en privacidad. Hay precedentes directos: Zcash financió una auditoría de Least Authority de su integración ZEC-into-Maya, que recientemente se completó con solo hallazgos menores de denegación de servicio y mejoras de calidad de vida, sin bugs importantes. El trabajo de Monero ya superó las pruebas chain-net y una revisión de desarrollador.
Fiel al enfoque habitual del protocolo, el pool de XMR se lanzará primero con liquidez superficial, propiedad del protocolo, y swaps de prueba pequeños, manteniendo los fondos de los usuarios fuera de escena mientras el cliente de la cadena se valida en producción.
“Rompan cosas, pero rómpanlas pequeñas”, afirmó Aaluxx.
ZEC en el lado de THORChain no tiene una línea de tiempo. El cuello de botella es el ancho de banda: reembolsos, trabajo de seguridad, el reinicio de la red y el lanzamiento de Monero compiten por la misma ventana estrecha de revisión y despliegue; y los churns vienen primero.
El enfoque de pagos del ecosistema recibió su propia actualización. Moca, una red de punto de venta y pagos cripto, liquida transacciones a través de Maya Protocol, THORChain y un puñado de otros backends. El objetivo es permitir que comerciantes comunes acepten cripto y liquiden en cripto sin fricciones — con volumen del mundo real fluyendo de vuelta a través de los protocolos como resultado.
La beta es deliberadamente silenciosa, con un lanzamiento el lunes después del próximo, sin un impulso de marketing al principio. El plan es abrir cuentas de negocio, recopilar feedback, ejecutar pagos de prueba reales y cerrar bugs antes de un despliegue más amplio.
“La parte de pagos de Maya ya está con nosotros”, afirmó EricOnchain, Moca.
Los builders interesados en acceso temprano a API pueden contactar directamente a EricOnchain o a la cuenta de Moca.
¿Por qué está pausada actualmente la rotación de bóvedas de THORChain?
Un problema de consenso específicamente ligado al proceso de churning requiere correcciones a nivel de Thornode. Esos cambios son demasiado profundos para enviarlos en una versión puntual, así que la rotación de bóvedas se mantiene pausada hasta que se despliegue la actualización completa v3.20.
¿Qué causó el exploit reciente de THORChain?
Tres bugs antiguos que cada uno por separado era inofensivo se volvieron explotables cuando se activaron en secuencia. La combinación permitió que una de las cinco bóvedas de THORChain quedara comprometida, lo que resultó en que aproximadamente el 20% del TVL se drenara.
¿Cómo mantuvo Maya Protocol los swaps durante la inactividad de THORChain?
Maya estaba ejecutando una sola bóveda que el equipo podía verificar como no comprometida de forma independiente. Al mantener esa bóveda operativa — mientras pausaban el churning como precaución — Maya siguió procesando swaps durante todo el mes de pausa de THORChain.
Noticias relacionadas