THORChain pausou todas as operações de rotação de cofres após os desenvolvedores identificarem um problema de consenso que ocorre especificamente durante o processo de churning. A equipe de desenvolvimento reorganizou o roadmap em torno de um único lançamento — a atualização v3.20 — que consolida correções de segurança, integração com Monero e implantação do router V6 em uma única atualização coordenada, com foco na implantação na semana seguinte. A pausa decorre de uma vulnerabilidade que exige mudanças profundas no Thornode, as quais não podem ser feitas em uma versão pontual. A consolidação resolve uma lacuna crítica de segurança, ao mesmo tempo em que limita o número de sequências de upgrade de alto risco que a rede precisa executar, especialmente importante diante da capacidade de revisão já esticada na equipe de desenvolvimento.
THORChain Pausa Rotação de Cofres Até a Implantação do v3.20
A rotação de cofres representa um dos mecanismos fundamentais de segurança do THORChain, e atualmente não está em operação. Um problema de consenso surge especificamente durante o processo de churning, e a correção exige mudanças profundas no Thornode que uma versão pontual não conseguiria suportar. Isso levou ao cancelamento do patch originalmente planejado v3.19.4, no mesmo dia em que a equipe discutiu.
A equipe se reuniu para acelerar o v3.20, visando uma altura de atualização para a semana seguinte. Assim que o lançamento for realizado, o plano é reativar a Solana primeiro e, posteriormente, restaurar o churning. Tudo o que estava no escopo do v3.19.4 — incluindo o trabalho com Monero — agora faz parte desse único lançamento maior, junto com o novo código do router V6, que já está pronto e sendo implantado progressivamente. Para os usuários, a experiência após a atualização permanece a mesma: as trocas continuam roteando pelo THORChain Swap normalmente.
A consolidação não é apenas uma medida reativa. Ao agrupar várias melhorias em um único lançamento coordenado, reduz-se o número de vezes que a rede precisa passar por uma sequência de upgrades de alto risco, o que é especialmente relevante quando a capacidade de revisão já está sob pressão.
Três Bugs Encadeados Permitaram o Recente Exploit
O exploit recente não resultou de uma falha catastrófica única. Segundo Aaluxx, cofundador da Maya Protocol e agora desenvolvedor sênior no THORChain, a vulnerabilidade foi uma combinação de três bugs antigos que coexistiam de forma inofensiva no código até que alguém — ou algo — descobrisse que poderiam ser acionados em sequência.
"Era um conjunto de três bugs que, encadeados, eram exploráveis. Cada um deles, isoladamente, era inofensivo", declarou Aaluxx.
Ele descreveu a manhã em que o exploit ocorreu como algo frio, sem emoções. A equipe havia acabado de mesclar patches de TSS de um repositório privado, e seu medo imediato era de que um erro nessa mesclagem tivesse introduzido a vulnerabilidade. Uma checagem rápida descartou essa hipótese: o commit estava intacto, e a causa raiz remonta a um código bem mais antigo. Na verdade, a equipe já havia identificado um bug encadeado semelhante — uma possível double-spend — alguns meses antes, o que indica que o padrão subjacente já estava no radar.
Equipe Detectou Cofre Comprometido por Análise de Parâmetros Criptográficos
A detecção foi tecnicamente elegante. Ao fatorar um dos parâmetros criptográficos de configuração do TSS e escanear por números primos pequenos que não deveriam existir, os desenvolvedores conseguiram identificar se algum cofre havia sido envenenado. No THORChain, um dos cinco cofres foi encontrado como comprometido, explicando por que cerca de 20% do TVL foi drenado, enquanto o valor total permaneceu intacto. O método forneceu à equipe um diagnóstico confiável em uma situação de alta criticidade.
Aaluxx foi direto ao ponto ao falar sobre o aprendizado mais amplo: uma equipe pequena agora pode explorar um código a partir de múltiplos ângulos simultaneamente, o que é uma vantagem defensiva — mas a mesma capacidade também está disponível para qualquer pessoa tentando encontrar vulnerabilidades externamente. Ele espera que os próximos meses sejam difíceis enquanto a indústria se adapta a essa nova realidade.
Maya Protocol Manteve Trocas Durante Pausa de Um Mês
Durante o período de aproximadamente um mês em que o THORChain permaneceu pausado, a Maya Protocol continuou realizando trocas. O mesmo bug latente existia no código da Maya, mas nunca foi acionado. Mais importante, a Maya operava com um único cofre que a equipe podia verificar de forma independente quanto à sua integridade — portanto, manteve-o em operação enquanto pausava o churning como medida de precaução, já que um churn poderia abrir o mesmo vetor de exploit.
A consequência prática foi que trocas nativas BTC-para-ETH permaneceram indisponíveis no THORChain durante esse período, mas continuaram disponíveis na Maya. Essa é uma implementação de redundância.
"Precisamos pilotar o jato com dois motores", afirmou Aaluxx.
Após o exploit e durante o período anterior ao TCY, algumas vozes defenderam a fusão do THORChain com a Maya — usando RUNE para comprar a CACAO e consolidar em um único DEX maior. Aaluxx reconheceu que essa teria sido uma decisão de negócio razoável, mas rejeitou. Dois DEXes independentes, permissionless, compartilhando os mesmos princípios, é uma escolha deliberada de design, não uma ineficiência a ser eliminada. O custo da redundância é real, mas o risco de um ponto único de falha também.
Restrições de Capacidade de Revisão Limitam Velocidade de Desenvolvimento
A principal limitação que desacelera o lançamento do THORChain não é a quantidade de código, mas a quantidade de pessoas qualificadas para revisá-lo e implantá-lo.
"Nosso fator limitante não é criar código, mas revisar e implantar", afirmou Aaluxx.
Atualmente, apenas cerca de três pessoas possuem o conhecimento profundo necessário para revisar e implementar mudanças no THORChain. Adicionar mais desenvolvedores ou mais pull requests não acelera automaticamente o processo — apenas aumenta a carga de revisão sobre um gargalo já estreito. A equipe opera com uma proporção deliberada de dois para um: cada trecho de código escrito exige pelo menos duas revisões antes de avançar.
Equipe Propõe Separar a Fase de Ideia do Processo de ADR
No lado da governança, surgiu um problema estrutural. Com propostas vindo de muitos colaboradores, em vez de um único órgão coordenador como o Nine Realms, os números de ADR se sobrepuseram, e ideias ainda em rascunho foram registradas como ADRs formais antes de estarem prontas para serem construídas.
A solução proposta é separar completamente a fase de geração de ideias da fase de elaboração de ADRs. Como Aaluxx colocou, uma ADR deve ser uma receita pronta: concisa, técnica e viável com os recursos disponíveis. O que falta é um espaço a montante — uma espécie de campo de testes — onde ideias brutas podem ser contestadas, refinadas ou descartadas antes de se qualificarem como ADR.
"Algumas pessoas acham que 'eu quero macarrão' é uma ADR. Isso não é uma ADR, isso é um problema. Venham até nós com uma receita", afirmou Aaluxx.
Mais adiante, os números de ADR poderiam ser solicitados e atribuídos on-chain via relay de node, com o primeiro node aprovador atribuindo o próximo número sequencial. Isso tornaria a posse de uma proposta inequívoca, sem criar um gatekeeper centralizado. Uma ADR, vale repetir, não é pré-requisito para enviar código — qualquer pessoa pode abrir issues e pull requests no GitLab atualmente. Uma ADR é uma checagem de temperatura que informa aos operadores de node se eles querem ou não que o tempo pago do desenvolvedor seja gasto com algo.
ShapeShift Entra no Modelo de Taxa Dinâmica Conforme as Integrações Se Expandem
Apesar da pausa, as integrações no ecossistema continuaram avançando. A ShapeShift agora se juntou à Symbiosis como participante ao vivo no modelo de taxa dinâmica, e os dados retornados de ambos estão se mostrando úteis. Espera-se que mais três ou quatro afiliadas entrem online dentro de uma semana, dependendo da disponibilidade de Chad Barraford para finalizar as integrações.
Uma dica da comunidade reabriu duas discussões maiores sobre integrações. Um DM direto para Randy Bechtold revelou Robinhood Chain como um possível alvo — e uma checagem rápida mostrou que ela é construída na Arbitrum, uma rede que o THORChain já vinha buscando. Isso criou uma oportunidade de duas por uma: Bechtold tem uma call agendada com a equipe da Arbitrum e planeja pedir uma introdução a quente à Robinhood enquanto estiver nisso.
Aaluxx ofereceu uma nota técnica de cautela sobre Arbitrum: ela opera em aproximadamente quatro blocos por segundo, o que sobrecarrega os nodes com volume de mensagens de modo semelhante ao da Solana. A Maya passou cerca de um ano estabilizando seu suporte a Arbitrum. O lado positivo é que o trabalho pesado já foi feito principalmente pela Maya, oferecendo ao THORChain um caminho mais curto.
Integração com Monero Avança Para a Fase de Auditoria de Menor Autoridade
A integração com XMR é a funcionalidade importante mais próxima de ser entregue. Aaluxx está em discussões com a Least Authority para uma auditoria de segurança — uma empresa que ele classifica entre as melhores para trabalhos em privacy chain. Há precedente direto: a Zcash financiou uma auditoria da Least Authority na sua integração ZEC-para-Maya, recentemente concluída com apenas achados menores de negação de serviço e melhorias de qualidade de vida, sem grandes bugs. O trabalho com Monero já passou pelos testes de chain-net e por uma revisão de desenvolvedor.
Seguindo a abordagem usual do protocolo, o pool de XMR será lançado primeiro com liquidez rasa, pertencente ao próprio protocolo, e pequenas trocas de teste, mantendo os fundos dos usuários fora do quadro enquanto o cliente da cadeia se prova em produção.
"Quebre coisas, mas quebre em pequenos pedaços", afirmou Aaluxx.
A integração com ZEC do lado do THORChain não possui um cronograma definido. O gargalo é a largura de banda: reembolsos, trabalho de segurança, reinício da rede e o lançamento do Monero competem pela mesma janela estreita de revisão e implantação, e os churns vêm primeiro.
Moca Lança Beta de Ponto de Venda Cripto via Maya e THORChain
O lado de pagamentos do ecossistema recebeu sua própria atualização. A Moca, uma rede de ponto de venda e pagamentos em cripto, realiza liquidações via Maya Protocol, THORChain e outros backends. O objetivo é permitir que comerciantes comuns aceitem cripto e façam liquidação em cripto sem atritos — com o volume do mundo real retornando pelos protocolos como resultado.
O beta é propositalmente discreto, com lançamento previsto para a segunda-feira da semana que vem, sem campanha de marketing inicial. O plano é abrir contas comerciais, coletar feedback, realizar pagamentos de teste reais e corrigir bugs antes de um rollout mais amplo.
"O lado de pagamentos da Maya está diante de nós", afirmou EricOnchain, da Moca.
Quem são construtores interessados em acesso antecipado à API podem contatar EricOnchain ou a conta da Moca diretamente.
FAQ
Por que a rotação de cofres do THORChain está pausada atualmente?
Um problema de consenso ligado especificamente ao processo de churning exige correções no Thornode. Essas mudanças são profundas demais para uma versão pontual, portanto a rotação de cofres fica pausada até que a atualização completa v3.20 seja implantada.
O que causou o recente exploit do THORChain?
Três bugs antigos, cada um inofensivo isoladamente, se tornaram exploráveis quando acionados em sequência. A combinação permitiu que um dos cinco cofres do THORChain fosse comprometido, esvaziando aproximadamente 20% do TVL.
Como a Maya Protocol manteve as trocas durante a indisponibilidade do THORChain?
A Maya operava com um único cofre que a equipe podia verificar de forma independente quanto à sua integridade. Mantendo esse cofre operacional — enquanto pausava o churning como precaução — a Maya continuou processando trocas durante todo o período de pausa do THORChain, que durou um mês.
