O XRP Ledger tem um limite máximo de 100 bilhões de XRP. Por cerca de onze anos, esse limite foi apenas uma sugestão. Em 9 de outubro de 2026, a XRPL Foundation publicou um relatório de divulgação confirmando que uma única transação elaborada poderia ter criado cerca de 18,4 trilhões de XRP gastáveis, aproximadamente 184 vezes o suprimento total, e que o código que permitia isso estava no motor de pagamentos desde novembro de 2015. O bug foi encontrado por um agente de IA, corrigido em três dias e lançado de uma forma que o ledger nunca havia usado antes. Ninguém o explorou. Essa é a boa notícia. Todo o resto da história merece um olhar mais atento.
O que o bug de overflow do XRP Ledger realmente fazia
A falha estava na parte do motor de pagamentos que lida com um pagamento que cruza um livro de ofertas. Quando um pagamento consome muitas ofertas de uma vez, o motor soma os valores que deve a cada proprietário de oferta. Essa adição usava inteiros assinados de 64 bits simples, sem verificação de overflow. Empurre o total além de 2 elevado a 64 e o contador volta para um número pequeno, como um hodômetro de carro que passa de 999999 para 000000.
Aqui está a parte feia. O motor cobrava do comprador o total com wrap, que era minúsculo. Pagava a cada proprietário de oferta o valor total, sem wrap. A diferença entre esses dois números é XRP que não existia um momento antes.
O ledger tem uma rede de segurança exatamente para isso. Uma verificação de invariante chamada XRPNotCreated é executada após cada transação e se recusa a validar qualquer coisa que aumente o total de XRP. O problema é que a invariante rastreava a mudança líquida de XRP usando a mesma aritmética de 64 bits não verificada. Um crédito grande o suficiente também fazia o contador da invariante dar wrap, então uma transação que imprimia trilhões de XRP parecia, para a verificação de segurança, uma queima de taxa rotineira. Dois bugs independentes, escritos com dois anos de diferença, cancelaram a proteção um do outro.
Como 256 ofertas somam 18 trilhões de XRP
A Veria Labs, a empresa de segurança cujo agente de IA encontrou o bug, publicou a aritmética. O ataque usava 256 ofertas. Cada oferta era vendida por 2 elevado a 56, mais um drop de XRP. Multiplique 256 por esse valor e o total chega exatamente a 2 elevado a 64, mais 256 drops. O drop extra por oferta importa: sem ele, a soma dá wrap para exatamente zero, o que o motor rejeitaria como um pagamento seco. Com ele, o comprador é cobrado 256 drops, cerca de 0,000256 XRP, enquanto os 256 proprietários de ofertas recebem coletivamente 2 elevado a 64 drops. Isso é 18.446.744.073.709.551.616 drops, ou aproximadamente 18,45 trilhões de XRP.
O atacante precisava de 256 contas financiadas porque cada conta XRPL é limitada a 100 bilhões de XRP, bem abaixo do valor por oferta dividido em uma conta. Também precisava de algumas centenas de XRP em reservas e taxas de transação, tudo recuperável. Nenhum acesso de validador era necessário. O ataque poderia ser repetido com contas novas. A Veria estimou o valor em risco em cerca de US$ 94 bilhões, mais de sessenta vezes o roubo de US$ 1,5 bilhão da Bybit que atualmente detém o recorde de hack de cripto que realmente aconteceu.
| Ingrediente | Valor | Por que importa |
|---|---|---|
| Ofertas consumidas em um pagamento | 256 | Abaixo do limite de 1.000 ofertas por travessia de livro |
| Preço por oferta | 2^56 + 1 drops | Fica abaixo do limite de 100 bilhões de XRP por conta |
| Total que o motor calculou | 2^64 + 256 drops | Dá wrap para 256 drops em aritmética de 64 bits |
| O que o comprador pagou | 256 drops (0,000256 XRP) | O valor com wrap |
| O que os vendedores receberam | Cerca de 18,45 trilhões de XRP | O valor sem wrap, 184x o suprimento total |
| Custo do atacante | Algumas centenas de XRP, recuperáveis | Reservas mais taxas |
| Acesso de validador necessário | Nenhum | Qualquer conta financiada poderia fazer isso |
Um agente de IA o encontrou numa segunda-feira à noite
O relator oficial é Cayden Liao, da Veria Labs, com o agente de IA da empresa creditado ao lado dele. De acordo com o próprio relato da Veria, o agente foi apontado para o código-fonte do rippled em 21 de setembro, sinalizou ambos os overflows, descobriu que podiam ser encadeados e produziu uma prova de conceito funcional em uma rede local. Um engenheiro fundador foi acordado às 4 da manhã para verificar. Pela manhã de 22 de setembro, a equipe estava confiante o suficiente para registrar o bug através do programa XRPL Bug Bounty, classificando-o como Major. A RippleX o reproduziu no mesmo dia e o elevou para Critical. Realisticamente, a Veria afirma que agentes de codificação de uso geral apontados para o mesmo código após a divulgação não conseguiram encontrá-lo. Considere isso com a costumeira desconfiança de uma empresa que vende a ferramenta que o fez. O ponto mais amplo permanece independentemente. O código de agregação BookStep data de novembro de 2015 e a invariante XRPNotCreated de fevereiro de 2017. O XRPL pagou mais de US$ 1 milhão em recompensas e realizou mais de uma dúzia de auditorias e concursos de auditoria desde 2024. Humanos e empresas de auditoria olharam para este código por uma década e não o viram. O padrão está se tornando familiar. A Coldcard perdeu aproximadamente 1.367 BTC neste verão para um bug de firmware de cinco anos que seu fabricante suspeita ter sido encontrado com assistência de IA. Código antigo não é mais seguro só porque é antigo.Por que a correção pulou a votação dos validadores
É aqui que a história deixa de ser uma vitória de segurança limpa e se torna um argumento de governança. O XRP Ledger normalmente altera as regras de transação por meio de emendas. Uma nova regra é lançada no software desativada, os validadores votam nela, e ela só é ativada após manter mais de 80% de suporte na Lista de Nós Únicos padrão por duas semanas consecutivas. O sistema existe há mais de uma década e nunca foi deliberadamente contornado para uma mudança no processamento de transações.
Até 25 de setembro. A correção do overflow foi lançada diretamente no xrpld 3.4.1 sem portão de emenda. Ela entrou em vigor em cada servidor no momento em que esse servidor foi atualizado. O raciocínio da XRPL Foundation é direto: uma votação de emenda teria publicado a correção, e portanto o bug, por duas semanas antes de entrar em vigor. Qualquer um que lesse o diff teria quinze dias para imprimir 18 trilhões de XRP. A Foundation diz que a decisão foi tomada em conjunto por ela mesma, RippleX, desenvolvedores principais e validadores, e que nenhuma parte isolada poderia ter tomado a decisão sozinha.
A abordagem trouxe seu próprio risco, que o relatório de divulgação admite. Se alguém tivesse tentado o exploit enquanto a rede estava dividida entre servidores corrigidos e não corrigidos, os dois grupos teriam discordado sobre o estado do ledger. No pior caso, a rede para. A equipe julgou uma possível parada preferível a uma explosão certa de suprimento, o que é difícil de contestar. Mais de 80% dos validadores da UNL padrão estavam executando a 3.4.1 horas após o lançamento em 25 de setembro.
| Data | Evento |
|---|---|
| Nov 2015 | Código de soma de ofertas BookStep escrito com adição de 64 bits não verificada |
| Fev 2017 | Invariante XRPNotCreated adicionada, usando a mesma aritmética não verificada |
| 21 Set 2026 | Agente de IA da Veria Labs sinaliza ambos os overflows e os encadeia |
| 22 Set 2026 | Registrado através do XRPL Bug Bounty, reproduzido pela RippleX, elevado para Critical |
| 23 Set 2026 | Correção mesclada privadamente no candidato a lançamento 3.4.1 |
| 25 Set 2026 | xrpld 3.4.1 lançado, mais de 80% dos validadores da UNL padrão atualizados |
| 8 Out 2026 | Veria Labs recebe a recompensa máxima de US$ 250.000 |
| 9 Out 2026 | Relatório de divulgação pública publicado, emenda Batch fix ativada |
| 12 Out 2026 | ZachXBT chama publicamente a recompensa de muito baixa |
A luta pela descentralização que se seguiu
Em resumo, Justin Bons, da Cyber Capital, um crítico de longa data do XRP, usou o episódio para argumentar que comercializar o XRP para o varejo como descentralizado equivale a fraude. Suas reclamações específicas: o lançamento de 25 de setembro foi distribuído apenas como binários compilados, com o código-fonte temporariamente retido, e os operadores foram pressionados a atualizar um binário que não podiam inspecionar. O relatório de divulgação do XRPL confirma que o código-fonte foi publicado depois, embora não diga quando.
Na prática, o contra-argumento veio tanto de operadores de validadores independentes quanto da Foundation. A XRP Kuwait, que opera seu próprio nó, resumiu: coordenação não é o mesmo que controle. Operadores independentes leram o mesmo aviso, chegaram à mesma conclusão e atualizaram. Ninguém os forçou. O Bitcoin fez a mesma coisa, notavelmente com o bug de inflação de 2018 no Bitcoin Core 0.16.x, quando os desenvolvedores lançaram discretamente uma correção antes de explicar o que ela corrigia. Toda chain com um bug sério eventualmente enfrenta a escolha entre transparência e sobrevivência, e todas elas escolheram a sobrevivência. No fim das contas, onde Bons tem um ponto justo é nos binários. Enviar um binário não verificável e pedir aos validadores que o executem imediatamente é um exercício de confiança, por mais justificado que seja. A versão honesta da posição do XRPL é que seu conjunto de validadores confiou o suficiente na Foundation e na RippleX para executar código não revisado por alguns dias. Se você chama isso de descentralizado depende do que você acha que a palavra significa.
US$ 250.000 foi o suficiente para um bug de US$ 94 bilhões?
A Veria Labs recebeu o pagamento máximo do nível crítico do programa XRPL de US$ 250.000 em 8 de outubro. A Veria chamou isso de provavelmente a maior recompensa já paga por um bug encontrado inteiramente por um agente de IA. Quatro dias depois, o investigador de blockchain ZachXBT chamou isso de piada de mau gosto. Seu argumento: um ecossistema cujo tesouro detém bilhões pagou um quarto de milhão por uma descoberta que poderia ter acabado com o ativo. E essa lacuna é exatamente o incentivo que empurra o próximo pesquisador a vender para um atacante. Ele sugeriu sete dígitos como piso e apontou para uma recompensa de sete dígitos supostamente paga no ecossistema Zcash por um bug de falsificação recente. Nem a Ripple nem a Foundation haviam respondido publicamente no momento da redação.
Ambos os lados estão certos sobre coisas diferentes. O programa pagou seu máximo anunciado, o pesquisador divulgou de forma responsável, e a correção chegou antes que qualquer um fora do círculo soubesse. Isso é o sistema funcionando. Também é verdade que US$ 250.000 é 0,27% dos US$ 94 bilhões em risco, e que qualquer atacante com 256 contas e algumas centenas de XRP poderia ter levado os outros 99,73%. Tetos de recompensa escritos quando o XRP valia uma fração de seu valor de mercado atual não escalam com a coisa que protegem.
O que os detentores de XRP e apostadores de cripto devem tirar disso
A correção é do lado do servidor. Sua carteira, suas chaves e seu saldo nunca estiveram envolvidos e nada precisa ser atualizado do seu lado. O limite de suprimento se manteve porque o bug foi pego, não porque a invariante funcionou. A segunda metade dessa frase é a que vale a pena lembrar.
Há três lições práticas aqui. Primeiro, o código estar ativo por dez anos deixou de ser um argumento de segurança. A auditoria assistida por IA está tornando overflows antigos baratos de encontrar, e os atacantes alugam os mesmos modelos que os pesquisadores. Segundo, processos de governança projetados para lançamentos de recursos não são projetados para patches críticos. E toda chain deveria decidir antecipadamente como lidará com o próximo, em vez de improvisar sob pressão. Terceiro, os tetos de recompensa por bugs deveriam acompanhar o valor protegido. Um limite fixo que parecia generoso em 2022 é um convite em 2026. Além disso, para o público de apostas a relevância é simples. O XRP se tornou uma via de depósito padrão em cassinos de cripto porque liquida em quatro segundos por uma fração de centavo. E essa velocidade depende de as regras do ledger estarem corretas. Plataformas que automatizam pagamentos, incluindo a CryptoCasino.Vegas, confiam nas invariantes das chains toda vez que um saque em XRP é concluído sem que um humano olhe. Essas invariantes se mantiveram desta vez por causa de um pesquisador e um agente de IA trabalhando durante a noite, e essa é uma margem mais fina do que o teto de 100 bilhões jamais deixou transparecer.
A análise técnica completa, incluindo ambos os locais de overflow e a aritmética reforçada que os substituiu, está em relatório de divulgação de vulnerabilidade da XRPL Foundation para o xrpld 3.4.1.
