A THORChain suspendeu todas as operações de rotação dos vaults após os developers terem descoberto um problema de consenso que surge especificamente durante o processo de churning. A equipa de desenvolvimento da rede reestruturou o seu roadmap em torno de um único lançamento — a atualização v3.20 — que consolida patches de segurança, integração com Monero e a implementação do router V6 numa única atualização coordenada, com alvo para implantação na semana seguinte. A pausa resulta de uma vulnerabilidade que exige mudanças profundas no Thornode que não podem ser incluídas num point release. A consolidação aborda uma falha crítica de segurança, limitando o número de sequências de upgrade de alto risco que a rede tem de executar, especialmente importante dada a capacidade de revisão esticada entre os membros da equipa de desenvolvimento.
THORChain Pausa a Rotação dos Vaults até à Implantação da v3.20
A rotação de vaults representa um dos mecanismos fundamentais de segurança da THORChain, e a operação encontra-se atualmente parada. Surge um problema de consenso especificamente durante o processo de churning, e a correção exige mudanças suficientemente profundas no Thornode para que um point release não as consiga levar. Isso inviabilizou o patch v3.19.4 originalmente planeado no mesmo dia em que a equipa o discutiu.
A equipa reuniu-se para avançar com a v3.20, visando uma altura de upgrade para a semana seguinte. Assim que o lançamento chegar, o plano é reativar primeiro a Solana e depois restaurar o churning. Tudo o que estava inicialmente previsto para a v3.19.4 — incluindo o trabalho com Monero — passa agora para esse único lançamento maior, juntamente com o novo código do router V6, que já está pronto e a ser implantado progressivamente. Para os utilizadores, a experiência após o upgrade mantém-se igual: as swaps continuam a ser roteadas através da THORChain Swap normalmente.
A consolidação não é puramente reativa. Integrar várias melhorias num único lançamento coordenado limita o número de vezes que a rede tem de passar por uma sequência de upgrade de alto risco, o que é relevante quando a capacidade de revisão já está esticada.
Três Bugs Encadeados Permitaram o Exploit Recente
O exploit recente não resultou de uma falha catastrófica única. De acordo com Aaluxx, cofundador da Maya Protocol e agora um developer sénior na THORChain, a vulnerabilidade foi uma combinação de três bugs mais antigos que tinham coexistido de forma inofensiva na codebase até alguém — ou algo — ter descoberto que podiam ser ativados em sequência.
"Foram três bugs que, encadeados, eram exploráveis. Qualquer um deles, isoladamente, era inofensivo", afirmou Aaluxx.
Ele descreveu a manhã em que o exploit se rompeu como fria. A equipa tinha acabado de fundir patches de TSS de um repositório privado, e o seu medo imediato era que um erro nessa fusão tivesse introduzido a vulnerabilidade. Uma verificação rápida afastou isso: o commit estava intacto, e a causa raiz foi atribuída a código muito mais antigo. A equipa tinha, na verdade, detetado um bug encadeado semelhante — um potencial double-spend — apenas alguns meses antes, o que significa que o padrão subjacente já estava no radar.
A Equipa Detetou um Vault Comprometido Através de Análise de Parâmetros Criptográficos
A deteção foi tecnicamente elegante. Ao fatorizar um dos parâmetros criptográficos da configuração do TSS e ao fazer varrimento por pequenos números primos que não deveriam estar presentes, os developers conseguiram identificar se algum vault em particular tinha sido envenenado. Na THORChain, descobriu-se que um de cinco vaults estava comprometido, o que explica porque cerca de 20% do TVL foi drenado em vez da totalidade. O método deu à equipa um diagnóstico fiável numa situação em que a rapidez na triagem era crítica.
Aaluxx foi direto sobre a lição mais ampla do papel da IA no futuro: uma pequena equipa pode agora explorar uma codebase a partir de muito mais ângulos em simultâneo, o que é uma vantagem defensiva — mas a mesma capacidade está disponível para qualquer pessoa que tente encontrar vulnerabilidades do exterior. Ele espera mais alguns meses difíceis enquanto a indústria se adapta a esta nova realidade.
Maya Protocol Manteve as Swaps Durante a Pausa de um Mês
Durante cerca de um mês em que a THORChain esteve parada, a Maya Protocol continuou a fazer swaps. O mesmo bug latente existia na codebase da Maya, mas nunca foi ativado. Mais importante ainda, a Maya estava a executar um único vault que a equipa podia verificar de forma independente como saudável — por isso manteve-o operacional enquanto fazia uma pausa no churning como precaução, já que um churn poderia ter aberto o mesmo caminho de exploit.
A consequência prática foi real: swaps nativas de BTC para ETH continuaram indisponíveis na THORChain durante esse período, mas mantiveram-se disponíveis na Maya. Este é o argumento da redundância tornado concreto.
"Precisamos de fazer o avião voar com dois motores", afirmou Aaluxx.
Após o exploit e durante o período TCY anterior, algumas vozes defenderam a fusão da THORChain e da Maya — usando RUNE para comprar CACAO e consolidar num único DEX maior. Aaluxx reconheceu que teria sido uma decisão de negócio razoável e mesmo assim rejeitou. Dois DEXes independentes e sem permissões, partilhando os mesmos ideais, é uma escolha de desenho deliberada, não uma ineficiência a otimizar para fora. O custo da redundância é real, mas o custo de um único ponto de falha também o é.
Restrições de Capacidade de Revisão Constrangem a Velocidade de Desenvolvimento
A restrição que abranda a velocidade de lançamento da THORChain não é falta de código. É falta de pessoas qualificadas para a rever e o implementar.
"Nosso fator limitante não é a criação de código; é a revisão e a implementação", afirmou Aaluxx.
Atualmente, apenas cerca de três pessoas têm a profundidade de especialização necessária para rever e implementar mudanças na THORChain. Adicionar mais developers ou mais pull requests não acelera automaticamente a entrega — aumenta a carga de revisão num gargalo já estreito. A equipa opera com um rácio deliberado de dois para um: cada peça de código escrita exige pelo menos duas revisões antes de avançar.
A Equipa Propõe a Separação da Fase de Ideia do Processo de ADR
No lado da governação, surgiu um problema estrutural. Com as propostas agora a chegarem de muitos contribuidores, em vez de um único organismo de coordenação como Nine Realms, os números de ADR colidiram e ideias embrionárias foram registadas como ADR formais antes de estarem prontas para serem construídas.
A correção proposta é separar completamente a fase de ideia da fase de ADR. Uma ADR, como Aaluxx enquadrou, deve já ser uma receita acabada: concisa, técnica e passível de construção com recursos disponíveis. O que falta é um espaço a montante — uma espécie de campo de batalha — onde as ideias brutas são contestadas, refinadas ou descartadas antes de poderem qualificar para o estatuto de ADR.
"Há quem pense que 'quero massa' é uma ADR. Não é uma ADR, é um problema. Venham com uma receita", afirmou Aaluxx.
Mais à frente, os números de ADR poderiam ser pedidos e atribuídos on-chain via node relay, com o primeiro node aprovador a atribuir o próximo número sequencial. Isso tornaria a titularidade de uma proposta inequívoca, sem criar um guardião centralizado. Uma ADR, vale repetir, não é um pré-requisito para fazer avançar código — qualquer pessoa pode abrir issues e pull requests no GitLab hoje. Uma ADR é uma verificação de temperatura que diz aos operadores de nodes se querem tempo de developer pago gasto em algo.
ShapeShift Entra no Modelo de Taxas Dinâmicas à Medida que As Integrações Se Expadem
Apesar da pausa, as integrações por todo o ecossistema continuaram a avançar. A ShapeShift juntou-se agora à Symbiosis como participante em tempo real no modelo de taxas dinâmicas, e os dados que regressam de ambas estão a revelar-se úteis. Espera-se que mais três ou quatro afiliados entrem online dentro de uma semana, dependendo da disponibilidade de Chad Barraford para concluir as integrações.
Uma dica da comunidade reabriu duas conversas maiores sobre integração. Um DM frio para Randy Bechtold fez surgir a Robinhood Chain como um alvo potencial — e uma análise rápida revelou que é construída em Arbitrum, uma rede que a THORChain já vinha a seguir. Isso criou uma oportunidade de dois por um: Bechtold tem uma chamada marcada com a equipa de Arbitrum e planeia pedir uma apresentação morna à Robinhood enquanto isso.
Aaluxx deixou uma nota técnica de cautela sobre Arbitrum: funciona a cerca de quatro blocos por segundo, o que inunda os nodes com volume de mensagens de uma forma semelhante à Solana. A Maya passou cerca de um ano a estabilizar o seu próprio suporte para Arbitrum. O lado positivo é que o trabalho árduo está em grande parte do lado da Maya, dando à THORChain um caminho mais curto.
A Integração com Monero Avança para a Fase de Auditoria de Menor Privilégio
A integração XMR é a funcionalidade maior mais próxima de estar pronta para ser lançada. Aaluxx está em discussões com Least Authority para uma auditoria de segurança — uma empresa que ele classifica entre as melhores para trabalho em cadeias de privacidade. Há um precedente direto: a Zcash financiou uma auditoria da Least Authority para a sua integração ZEC-into-Maya, que recentemente terminou com apenas conclusões menores de negação de serviço e questões de qualidade de vida, sem bugs importantes. O trabalho com Monero já passou nos testes de chain-net e numa revisão de um developer.
Fiel à abordagem habitual do protocolo, a pool de XMR vai lançar primeiro com liquidez rasa, propriedade do protocolo, e pequenos testes de swaps, mantendo os fundos dos utilizadores fora da equação enquanto o cliente da cadeia se prova em produção.
"Partir coisas, mas partir coisas pequenas", afirmou Aaluxx.
No lado da THORChain, o ZEC não tem linha temporal. O gargalo é largura de banda: refunds, trabalho de segurança, o restart da rede e o lançamento de Monero competem pela mesma janela estreita de revisão e implantação, e os churns vêm primeiro.
Moca Lança uma Beta de Ponto de Venda Cripto via Maya e THORChain
O ângulo dos pagamentos no ecossistema ganhou a sua própria atualização. A Moca, uma rede de ponto de venda e pagamentos cripto, liquida transações através da Maya Protocol, THORChain e de uma série de outros backends. O objetivo é permitir que comerciantes comuns aceitem cripto e liquidem em cripto sem fricção — com volume do mundo real a fluir de volta através dos protocolos como resultado.
A beta é deliberadamente discreta, com alvo de lançamento na segunda-feira da semana a seguir, sem impulso de marketing no início. O plano é abrir contas comerciais, recolher feedback, executar pagamentos de teste reais e fechar bugs antes de um rollout mais alargado.
"O lado dos pagamentos da Maya está entre nós", afirmou EricOnchain, da Moca.
Os builders interessados em acesso inicial a APIs podem contactar EricOnchain ou a conta da Moca diretamente.
FAQ
Por que é que a rotação de vaults da THORChain está atualmente pausada?
Um problema de consenso especificamente ligado ao processo de churning exige correções ao nível do Thornode. Essas alterações são demasiado profundas para serem enviadas num point release, por isso a rotação de vaults fica em pausa até a atualização completa v3.20 ser implantada.
O que causou o exploit recente da THORChain?
Três bugs mais antigos que, cada um isoladamente, eram inofensivos tornaram-se exploráveis quando ativados em sequência. A combinação permitiu que um dos cinco vaults da THORChain fosse comprometido, resultando em cerca de 20% do TVL ser drenado.
Como é que a Maya Protocol manteve swaps durante a indisponibilidade da THORChain?
A Maya estava a executar um único vault que a equipa conseguia verificar de forma independente como não comprometido. Ao manter esse vault operacional — enquanto pausava o churning como precaução — a Maya continuou a processar swaps durante todo o período de pausa da THORChain, que durou um mês inteiro.
