O que aconteceu

A lição anterior explicou que o ataque atingiu os registros de saldo. Mas se a vulnerabilidade foi identificada, por que ela não foi apenas corrigida no ponto específico, mantendo-se a operação? Por que toda a infraestrutura de contratos inteligentes foi paralisada?

No primeiro momento, a vulnerabilidade identificada apontava para um único contrato inteligente, o Payments — especificamente a função que abre novas posições. A apuração técnica seguiu, e confirmou que o problema não estava limitado a ele. Diante disso, a paralisação de toda a infraestrutura de contratos inteligentes ligada ao caso — Factory, Manager, Payments, SubAccounts, Strategies, Network e LPToken — foi adotada como medida de segurança, em conjunto, pela Desenvolvedora de Tecnologia e pelas operações licenciadas afetadas. Quando não se conhece a extensão de um problema, a paralisação integral é a decisão tecnicamente mais prudente — e prática padrão em produtos de tecnologia.

O que é observável on-chain: chamadas ao Payments partiram de um endereço com autorização administrativa, e essa autorização foi posteriormente revogada — a transação de revogação é pública e conferível. A apuração do vetor de comprometimento segue em curso, e este portal não publica conclusão sobre ela antes de estar concluída e ancorada on-chain. Revogar um endereço, por si, não encerra a apuração: seguem em aberto questões que só uma verificação completa responde, como a existência de outros endereços administrativos comprometidos ou de inconsistências residuais em posições ligadas às estratégias antigas. Enquanto essas questões técnicas seguem em aberto, os contratos inteligentes permanecem pausados — e isso nunca impediu a consulta: eles seguem em estado de leitura, verificáveis on-chain a qualquer momento.

Depois, veio uma definição estrutural. Adotando a segurança como premissa, os contratos inteligentes nas versões conhecidas como v4 e v5 permanecerão desligados — mesmo após a execução do procedimento de recovery, e ainda que este tenha pleno sucesso. A v4 não foi atingida pelo ataque: por compartilhar a mesma arquitetura da v5, foi pausada por precaução e segue o mesmo destino. Diferentemente da pausa inicial, adotada enquanto a apuração estava em curso, esta é uma definição registrada oficialmente sobre versões descontinuadas, e não um estado provisório de apuração.

É por isso que existe o processo que você acompanha: em vez de reativar o código antigo, a Engenharia da Desenvolvedora desenvolveu um conjunto novo e separado de contratos inteligentes — os que você usa no processo de recuperação — cuja função é ler o retrato das posições de antes do incidente e executar a disponibilização proporcional, sem depender do caminho onde a vulnerabilidade existiu. É o que a próxima lição explica.