Uma falha no XRP Ledger poderia criar XRP que o protocolo normalmente proíbe emitir. Corrigida no xrpld 3.4.1, a vulnerabilidade foi divulgada em 9 de outubro. As equipes da rede afirmam não ter encontrado nenhuma evidência de exploração em uma rede pública.
O risco afetava a integridade da moeda, e não apenas uma carteira. O incidente também levanta uma questão de governança: como implementar uma correção urgente sem deixar uma vulnerabilidade explorável durante a votação dos validadores?
Em resumo
- A Veria Labs descreve uma demonstração capaz de criar aproximadamente 18,45 trilhões de XRP, em ambiente de testes.
- A correção foi distribuída antes da publicação dos detalhes; as equipes não identificaram nenhuma exploração pública.
- Os operadores devem usar o xrpld 3.4.1 ou uma versão posterior compatível.
XRP: um número impressionante, não um roubo constatado
A manutenção do protocolo já estava no centro da proposta de remover a bridge nativa XLS-38 do XRP Ledger. Desta vez, o problema envolve diretamente a possibilidade de criar o ativo nativo. Não se trata de um token de terceiros imitando seu nome.
Em sua análise técnica publicada em 10 de outubro, a Veria Labs estima sua demonstração em aproximadamente 18,4467 trilhões de XRP. Em comparação com as 100 bilhões de unidades iniciais, isso representa aproximadamente 184 vezes a oferta inicial. Trata-se de uma comparação de quantidades, não de uma estimativa de receitas realizáveis.
A Veria também apresenta uma capitalização de mercado de US$ 94 bilhões como exposição potencial. Esse valor não corresponde a uma perda constatada. Uma emissão fraudulenta dessa magnitude poderia prejudicar a confiança e o preço; não há base para afirmar que essas unidades encontrariam compradores pelo preço anterior.
O relatório oficial de divulgação diferencia claramente a capacidade reproduzida em testes de uma exploração pública. A ausência de evidências reportadas, contudo, não constitui uma garantia absoluta sobre todo o histórico da rede.
Dois controles cegados pelo mesmo cálculo
A Veria localiza o problema na soma dos valores durante o processamento de ordens. Um número inteiro de computador tem capacidade limitada: se o programa não verificar o overflow, o resultado pode ficar incorreto. Nesse caso, o total debitado poderia deixar de corresponder aos valores creditados.
A documentação sobre invariantes do XRPL, no entanto, descreve um segundo controle, executado antes do registro das alterações. Ele deve impedir, entre outras coisas, que uma transação crie XRP e verificar os limites dos saldos.
Dois mecanismos de proteção não representam necessariamente duas defesas independentes. Segundo a análise da Veria, o controle global também usava um contador suscetível a overflow. Assim, poderia validar um resultado contábil já distorcido. A lição vai além desse protocolo: testar uma regra de negócio não basta quando sua verificação compartilha a fragilidade do cálculo inicial.
Essa é uma distinção importante em relação às permissões de criação de tokens em um smart contract. Uma emissão autorizada por um administrador e uma emissão causada por um bug no mecanismo nativo são problemas diferentes.
Por que a urgência alterou a votação
O processo normal de emenda exige o apoio de mais de 80% dos validadores confiáveis durante duas semanas. Sua importância é concreta: fazer com que uma nova regra seja aplicada no mesmo ponto do histórico, em vez de permitir que várias versões processem uma transação de maneiras diferentes.
Essa coordenação ajuda a esclarecer o debate entre controle operacional e descentralização. A rapidez de uma decisão, por si só, não indica quem pode impor as regras de uma rede de forma duradoura.
No caso da falha de emissão, as equipes optaram pela aplicação imediata após a atualização. Elas explicam que esperar teria exposto publicamente o bug antes de sua neutralização. A escolha criou um risco temporário de divergência entre versões, assumido diante do perigo de uma emissão fraudulenta.
O tema se relaciona, sem confundir as arquiteturas, às discussões sobre intervenções de emergência após um ataque. A questão não é apenas ter condições de agir rapidamente, mas explicar qual exceção está sendo usada e por quê.
Duas correções, dois cronogramas
O anúncio de 25 de setembro apresentou a versão 3.4.1 como uma atualização de emergência. O texto já detalhava o reforço dos cálculos aritméticos, mas manteve temporariamente o código-fonte em sigilo por razões de segurança.
O relatório de outubro também trata de outra falha, relacionada ao encapsulamento de transações Batch. Ela não afetou fundos na mainnet antes da correção. O problema seguiu um cronograma diferente: a emenda fixBatchV1_2 entrou em vigor em 9 de outubro.
Por isso, é importante não misturar os dois eventos. A correção do mecanismo de pagamentos foi aplicada com a atualização do servidor; a outra mudança dependia da ativação de uma emenda.
O que os operadores precisam verificar
A publicação atual no GitHub confirma que as versões antigas que não incluem a nova emenda estão agora bloqueadas para acompanhar a rede. A medida esperada dos operadores de servidores é atualizar o software e, em seguida, verificar sua sincronização e a continuidade do serviço.
A documentação lembra que um servidor bloqueado por uma emenda não consegue mais determinar corretamente a validade dos registros nem participar do consenso. Assim, uma aplicação pode ter uma interface funcional e ainda depender de um servidor que se tornou inadequado.
Para o leitor, a verificação importante é diferente: distinguir uma correção efetivamente distribuída, uma demonstração de pesquisa e um incidente financeiro constatado. Nossa análise se baseia nos documentos dos mantenedores e pesquisadores; não executamos a demonstração de forma independente.
O que vem a seguir será medido pela qualidade da implementação e dos controles, não apenas pelo número de XRP teoricamente criáveis. Uma regra de oferta limitada só é confiável quando o software que a aplica, suas proteções e os procedimentos de atualização funcionam em conjunto.
