Índice
O que o concurso Sherlock realmente encontrou
O bug de alteração do lote que poderia ter esvaziado as contas
Exploit silencioso de delegação de permissão
Por que ambas as reescritas foram enviadas em uma única versão
Auditoria antes do lançamento versus patch após a exploração
O que isso significa para o discurso institucional da XRPL
O caso oposto: por que os céticos não estão convencidos
O que assistir
O que a auditoria de Sherlock do XRP Ledger encontrou?
Qual foi o bug crítico da alteração do Lote?
Como funcionou a vulnerabilidade de Delegação de Permissão?
Algum fundo foi perdido por causa dessas vulnerabilidades?
O que é Sherlock e como funciona seu modelo de auditoria?
Como o modelo de segurança do XRPL difere do da Ethereum?
Quais recursos o XRP Ledger versão 3.3.0 inclui?
Essa auditoria torna o XRPL um investimento seguro?
Um concurso de auditoria comunitária de US$ 550.000 descobriu duas vulnerabilidades críticas nos recursos do XRP Ledger que poderiam ter drenado contas de usuário sem chaves privadas. As descobertas revelam como o modelo de auditoria antes do lançamento da Ripple diverge acentuadamente da norma patch após a exploração da indústria criptográfica mais ampla.
Resumo
O concurso de auditoria de duas semanas de Sherlock, que abriu em 13 de abril de 2026, descobriu 96 vulnerabilidades válidas em cinco alterações propostas do XRP Ledger, incluindo 2 bugs críticos e 6 de alta gravidade, antes que qualquer um deles chegasse à rede principal.
A Ripple pagou US$ 309.000 em recompensas RLUSD de um prêmio de US$ 550.000, marcando a primeira colaboração entre Sherlock e Ripple e um dos maiores concursos de auditoria de 2026.
A descoberta mais grave foi uma falha de validação de assinatura na emenda Batch que teria permitido que os invasores executassem transações de qualquer conta sem manter suas chaves privadas, identificada pela primeira vez em 19 de fevereiro de 2026, pelo pesquisador Pranamya Keshkamat e pela ferramenta de IA Apex da Cantina.
Um bug crítico separado na Delegação de Permissão permitiu que atores mal-intencionados drenassem silenciosamente os saldos XRP por meio de cobranças repetidas de taxas em transações delegadas inválidas, porque o código verificou as permissões antes de verificar as assinaturas.
As explorações da DeFi excederam US$ 840 milhões em mais de 50 incidentes apenas nos primeiros cinco meses de 2026, um aumento de 70% ano a ano, e 70% dos contratos explorados foram auditados, mas não monitoraram pós-implantação.
XRP Ledger versão 3.3.0 enviada em 6 de agosto de 2026, com cinco alterações propostas e um patch de limpeza empacotado. No papel, parecia um lançamento de infraestrutura de rotina. Por baixo, a atualização representou a conclusão de uma manopla de segurança de seis meses que pegou dois bugs de drenagem da conta, reescreveu duas implementações de recursos inteiras do zero e pagou centenas de milhares de dólares a pesquisadores externos que encontraram problemas que a equipe interna havia perdido. O processo levanta uma questão importante para a indústria mais ampla de blockchain: se o Ripple pode capturar falhas críticas antes da implantação, por que tanta criptografia ainda trata as auditorias de segurança como uma caixa de seleção pós-lançamento?
Esta peça detalha o que as duas vulnerabilidades críticas realmente eram em um nível técnico, examina como o pipeline de auditoria-voto-ativação se compara aos modelos de segurança das cadeias concorrentes e avalia se as descobertas fortalecem ou prejudicam o caso do XRPL como infraestrutura de nível institucional.
O que o concurso Sherlock realmente encontrou
O escopo cobriu cinco pilares da próxima funcionalidade XRPL: Transações em Lote, Delegação de Permissão, integração de Token Multiuso (MPT) DEX, Transferências Confidenciais para MPTs e Taxas e Reservas Patrocinados. Sherlock, uma empresa de segurança Web3 que classifica os pesquisadores por desempenho e estrutura compromissos como concursos contraditórios, abriu a auditoria em 13 de abril de 2026, com um prêmio de US$ 550.000 RLUSD. A página do concurso na plataforma de Sherlock listou o compromisso como “XRP Ledger – Concurso de abril de 2026 – 550.000 RLUSD”, sinalizando que a Ripple pagou as recompensas em sua própria stablecoin.
Ao longo de duas semanas, os participantes enviaram relatórios que revelaram 96 descobertas válidas: 2 críticas, 6 altas, 29 médias e 59 questões de baixa gravidade. A Ripple distribuiu US$ 309.000 em RLUSD para os contribuintes. O pool restante cobriu os custos operacionais de Sherlock e as descobertas de nível inferior que não atenderam ao limite de pagamento.
O concurso marcou a primeira colaboração formal entre Sherlock e Ripple, e chegou em um momento em que o pipeline de recursos do XRP Ledger estava se expandindo mais rápido do que em qualquer ponto de sua história. Cinco emendas enviadas simultaneamente significaram cinco superfícies de ataque distintas, cada uma com sua própria lógica de transação, modelo de autorização e requisitos criptográficos. Para contextualizar, o modelo de concurso de auditoria de Sherlock foi usado anteriormente por protocolos, incluindo Aave, Euler e Olympus DAO, mas um engajamento cobrindo código de nível de protocolo C++ para um blockchain de camada um era atípico para uma plataforma mais comumente associada a contratos inteligentes Solidity.
A própria distribuição de gravidade conta uma história. As 29 descobertas de gravidade média sugerem uma categoria de bugs que não comprometeriam individualmente as contas, mas poderiam criar um comportamento inesperado em sequências de transações específicas. Os 59 problemas de baixa gravidade provavelmente incluem preocupações com a qualidade do código, lacunas de documentação e casos de borda que podem se agravar em condições contraditórias. Os dois bugs críticos e seis de alta gravidade, no entanto, representavam vulnerabilidades exploráveis que justificavam correção imediata.
O bug de alteração do lote que poderia ter esvaziado as contas
A vulnerabilidade mais perigosa foi anterior ao concurso Sherlock em dois meses. Em 19 de fevereiro de 2026, o pesquisador de segurança Pranamya Keshkamat e a ferramenta autônoma de auditoria de IA da Cantina Apex identificaram de forma independente uma falha de validação de assinatura na emenda original do Batch enquanto ainda estava em sua fase de votação do validador.
A falha técnica foi precisa. As Transações em Lote permitem que até oito operações sejam executadas atomicamente sob uma única transação externa. O código de validação de assinatura da transação externa continha uma condição de saída antecipada que poderia ser satisfeita sem verificar adequadamente quem estava autorizando as transações internas. Na prática, um invasor poderia ter construído uma transação em lote contendo operações de pagamento internas direcionadas a uma conta de vítima, drenando-a até seu saldo de reserva, sem nunca manter as chaves privadas dessa conta. A mesma lacuna lógica teria permitido operações AccountSet, TrustSet ou AccountDelete não autorizadas.
O relatório de divulgação de vulnerabilidade publicado no xrpl.org detalhou a mecânica: a verificação do signatário na transação externa poderia ser passada sem confirmar que a entidade que enviou o lote realmente controlava as contas referenciadas nas transações internas. Isso significava que o recurso de atomicidade projetado para melhorar a experiência do usuário poderia ter sido armado para esvaziar qualquer conta na rede em uma única transação.
RippleX respondeu com uma liberação de emergência. A versão Rippled 3.1.1, publicada em 23 de fevereiro de 2026, quatro dias após a descoberta, marcou a alteração original do Batch e sua correção complementar BatchInnerSigs como não suportadas, impedindo que os validadores votassem ou ativassem. Nenhum fundo foi perdido porque a emenda ainda não havia liberado o limite de 80% do validador necessário para a ativação. A substituição, BatchV1_1, foi enviada na versão 3.3.0 com a condição de saída antecipada removida, protetores de autorização adicionais adicionados e o escopo de verificação de assinatura apertado para verificar cada transação interna contra o signatário correto de forma independente.
Exploit silencioso de delegação de permissão
A segunda vulnerabilidade crítica operou através de um mecanismo mais sutil. Uma divulgação de setembro de 2025 documentou como a implementação original da Delegação de Permissão permitiu que um invasor sangrasse silenciosamente o saldo XRP de uma conta de vítima sem acessar suas chaves.
O exploit foi baseado em um recurso de design do processamento de transações do XRP Ledger que existe desde os primeiros dias da rede. No XRPL, uma transação que falha com um erro de classe “tec” ainda incorre em uma taxa, enquanto os erros detectados anteriormente no pipeline, antes da verificação da assinatura, não. Essa distinção existe porque as falhas da classe tec indicam transações que foram devidamente formadas e assinadas, mas falharam por razões lógicas de negócios, e a taxa evita spam. O código original da Delegação de Permissão verificou se uma conta de delegado tinha a permissão relevante antes de verificar a assinatura da transação. Um invasor poderia enviar repetidamente transações inválidas assinadas off-line com taxas elevadas contra uma conta delegada, e cada transação com falha ainda deduziria a taxa do saldo da vítima.
O impacto econômico teria se agravado rapidamente. Como o invasor poderia definir taxas arbitrariamente altas nessas transações, um ataque sustentado poderia drenar uma conta muito mais rápido do que as taxas de transação normais sugeririam. A vítima veria seu saldo diminuindo sem pagamentos de saída correspondentes, dificultando o diagnóstico do ataque sem examinar os metadados brutos da transação.
A correção reclassificou o erro relevante de tec para ter e reordenou os cheques para que nenhuma taxa possa ser deduzida antes que a verificação da assinatura seja aprovada. A alteração de substituição, PermissionDelegationV1_1, carrega uma designação padrão "Não" no registro 3.3.0, o que significa que os validadores devem votar ativamente para habilitá-la. Esse padrão conservador reflete a sensibilidade da falha original: mesmo após a reescrita, o Ripple optou por exigir opt-in do validador explícito para o recurso.
ÚLTIMA HORA: XRP Ledger sustenta mais de 140 TPS e bloqueia com até 987 transações durante a grande onda de atividade de hoje, mantendo taxas de nível de centavo e liquidação de 3-4 segundos pic.twitter.com/yaAyCH4wGy
— crypto.news (@cryptodotnews) 10 de abril de 2026
Por que ambas as reescritas foram enviadas em uma única versão
Empacotar duas emendas reescritas de segurança ao lado de três recursos inteiramente novos em uma versão foi uma escolha deliberada. RippleX publicou xrpld 3.3.0 em 6 de agosto de 2026, com o código para todas as seis propostas (incluindo uma emenda de limpeza agrupada chamada fixCleanup3_3_0) presentes, mas nenhuma delas ativada. Sob o processo de alteração do XRP Ledger, cada proposta deve sustentar mais de 80% do suporte ao validador por duas semanas consecutivas antes de entrar em operação.
Essa separação entre a disponibilidade de código e a ativação de recursos é uma vantagem estrutural que a maioria das plataformas de contratos inteligentes não tem. No Ethereum, um contrato implantado está ativo no momento em que atinge o blockchain. No XRPL, o código pode ser enviado, submetido a uma revisão adicional durante a janela de votação e ainda ser bloqueado se os validadores perderem a confiança. As reescritas do Lote e da Delegação de Permissão já haviam sobrevivido ao concurso Sherlock, uma nova auditoria de Halborn que não encontrou problemas críticos ou de alto risco e meses de testes internos. O período de votação adiciona mais uma camada de defesa antes que qualquer código toque em fundos reais.
A versão também retirou cinco emendas legadas, incluindo Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve e fixUniversalNumber, removendo caminhos de código mortos que poderiam se acumular como superfície de ataque latente ao longo do tempo.
As cinco alterações de recursos em 3.3.0 representam a expansão única mais ampla dos recursos do XRPL até o momento. As Transferências Confidenciais trazem criptografia EC-ElGamal e provas de conhecimento zero para Tokens Multiuso, protegendo saldos individuais e valores de transferência da visualização pública, preservando o acesso à conformidade para partes autorizadas. As Taxas Patrocinadas permitem que os aplicativos cubram os custos de rede em nome dos usuários, abordando o atrito de integração que manteve os aplicativos voltados para o consumidor fora das redes descentralizadas. O DynamicMPT permite que os emissores modifiquem as propriedades do token após a criação, apoiando a evolução dos requisitos regulatórios e comerciais. Juntamente com as reescritas de Lote e Delegação de Permissão, esses recursos visam um público específico: instituições financeiras regulamentadas que precisam de privacidade, liquidação atômica e operações delegadas sem sacrificar a auditabilidade.
Você também pode gostar: XRP Ledger implanta correções de bugs depois que a investigação de segurança descobre falhas
Auditoria antes do lançamento versus patch após a exploração
O contraste entre a abordagem da Ripple e o histórico de segurança da indústria mais ampla é nítido. As explorações da DeFi excederam US$ 840 milhões em mais de 50 incidentes nos primeiros cinco meses de 2026, um aumento de 70% ano a ano em relação ao mesmo período de 2025. Atores ligados à Coreia do Norte representaram 76% das perdas globais de hackers de criptografia nos primeiros quatro meses do ano. E a estatística mais condenate: 70% dos contratos explorados foram auditados, mas não tinham qualquer forma de monitoramento pós-implantação. Apenas 4% dos projetos rastreados combinaram auditorias, recompensas por bugs ativos e controles de monitoramento de terceiros juntos.
O ecossistema Ethereum, lar da maior concentração de valor de contrato inteligente, opera sob um modelo de segurança fundamentalmente diferente. Os contratos são implantados na rede principal por meio de uma transação imutável. Se uma vulnerabilidade aparecer depois, as opções são limitadas: implantar um novo contrato e migrar usuários, implementar um padrão de atualização de proxy que introduz sua própria superfície de ataque ou aceitar o risco. O hack da ponte Wormhole de 2022 custou US$ 320 milhões porque uma função de verificação obsoleta permaneceu no código de produção. A exploração de Ronin em agosto de 2024 custou US$ 12 milhões porque uma atualização de contrato não conseguiu inicializar os pesos do operador corretamente. Em ambos os casos, auditorias foram realizadas; as falhas aconteceram após a implantação.
O hack KelpDAO em 18 de abril de 2026, que drenou aproximadamente US$ 293 milhões, foi a maior exploração DeFi do ano. A exploração do Drift Protocol em Solana em 1o de abril, que custou cerca de US$ 286 milhões, foi a maior já registrada nessa cadeia. Esses números não são eventos marginais. Eles representam a taxa de falha de linha de base de uma indústria que perdeu coletivamente US$ 16,69 bilhões para hackers, explorações de ponte e incidentes de segurança, de acordo com dados da DeFiLlama.
O processo de votação de emenda da XRPL inverte essa sequência. O código é enviado em uma versão, mas os recursos permanecem inativos até que os validadores os aprovem. Durante a janela de votação, pesquisadores, operadores de nós e auditores concorrentes podem examinar a base de código ao vivo com o contexto completo. Se surgir um problema, os validadores simplesmente retêm seus votos. Sem patch de emergência, sem migração, sem contrato de procuração. O bug do Batch de fevereiro de 2026 seguiu exatamente esse caminho: a emenda estava em sua fase de votação, a vulnerabilidade foi identificada e um lançamento de emergência impediu a ativação. Fundos zero em risco, zero impacto no usuário.
Isso não quer dizer que o modelo XRPL seja impecável. O processo de alteração funciona para recursos de nível de protocolo, mas não se estende a aplicativos construídos em cima do livro-razão. Uma linha de confiança mal codificada ou integração MPT ainda pode perder fundos. E o limite de validador de 80% cria seus próprios riscos: se poucos validadores atualizarem para uma nova versão, os patches de segurança legítimos podem parar. Mas para mudanças no protocolo principal, o pipeline de auditoria-voto-ativação representa uma postura de segurança materialmente diferente do que implantar e esperar.
NOVO: A Coinbase habilitou o Trade at Settlement para futuros de $XRP em 1o de maio, colocando XRP ao lado de Bitcoin, Ethereum, ouro e petróleo bruto para negociação de bloco institucional pic.twitter.com/d00uPssPxy
— crypto.news (@cryptodotnews) 3 de maio de 2026
O que isso significa para o discurso institucional da XRPL
A Ripple passou 2026 construindo uma pilha de infraestrutura institucional em um ritmo agressivo. A aquisição de US$ 1,25 bilhão da Hidden Road, uma corretora principal multiativos renomeada como Ripple Prime, deu à empresa uma rampa regulamentada para finanças tradicionais. A RLUSD alcançou uma capitalização de mercado de US$ 1,72 bilhão em menos de um ano e moveu mais de US$ 18 bilhões em volume de transações apenas durante o primeiro trimestre. A Goldman Sachs divulgou uma posição de US$ 153,8 milhões em quatro ETFs XRP. A Ripple garantiu uma licença completa de Instituição de Dinheiro Eletrônico de Luxemburgo em fevereiro, permissões da Autoridade de Conduta Financeira do Reino Unido em janeiro e uma licença de Provedor de Serviços de Criptoativos MiCA em 6 de julho.
Os recursos institucionais do DeFi que chegam à versão 3.3.0 são a contrapartida técnica para esse impulso de desenvolvimento de negócios. As Transferências Confidenciais abordam os requisitos de privacidade dos bancos que não podem expor os detalhes da transação em um livro-razão público. As Taxas Patrocinados resolvem o atrito de integração que manteve os aplicativos bancários de varejo fora das redes descentralizadas. A Delegação de Permissão, uma vez que sua reescrita limpa o processo de votação, permite o tipo de modelos de acesso controlado que os departamentos de conformidade exigem.
Mas a adoção institucional depende da confiança, e a confiança na infraestrutura blockchain, em última análise, se resume ao histórico de segurança. O fato de a Ripple ter detectado dois bugs críticos, reescrito duas implementações de recursos inteiros, pago a pesquisadores externos US$ 309.000 para encontrar problemas e ainda entregou todos os cinco recursos dentro do cronograma é um ponto de venda institucional mais forte do que qualquer recurso individual. Isso sugere uma cultura de segurança onde encontrar bugs é recompensado e onde o envio é subordinado à verificação.
Mais de 300 instituições financeiras em 55 países usam atualmente a RippleNet, com corredores de Liquidez Sob Demanda ativos em mais de 70 mercados. Para essas instituições, os resultados da auditoria de Sherlock não são abstratos. Eles são evidências de que o código que executa seus pagamentos transfronteiriços foi testado por pesquisadores adversários com incentivos financeiros para quebrá-lo. O roteiro de resistência quântica de quatro fases da Ripple, visando a conclusão até 2028, sinaliza ainda mais que a empresa está projetando horizontes temporais medidos em décadas, não ciclos de implantação.
O caso oposto: por que os céticos não estão convencidos
O argumento mais forte contra a leitura demais na auditoria de Sherlock vai em duas direções.
Primeiro, encontrar 96 bugs antes do lançamento pode ser enquadrado como evidência de testes completos ou evidência de desenvolvimento desleixado. Ambas as vulnerabilidades Batch e Delegação de Permissão estavam nas implementações originais, o que significa que elas limparam a revisão interna antes que pesquisadores externos as pegassem. O bug Batch de fevereiro de 2026 não foi identificado pela própria equipe da Ripple, mas por um pesquisador independente e uma ferramenta de IA. Se os auditores externos forem a principal rede de segurança, o processo de desenvolvimento interno pode ter lacunas de qualidade que eventualmente produzirão uma vulnerabilidade que nenhum revisor externo detecta a tempo.
Em segundo lugar, a força do modelo de emenda XRPL, a capacidade de impedir a ativação durante a janela de votação, também é uma restrição de velocidade. A disposição da Ethereum de implantar e iterar permitiu um ritmo de inovação que a XRPL não pode igualar. As cinco emendas na versão 3.3.0 estão em ciclos de desenvolvimento e revisão há meses. A emenda original do Batch foi proposta em 2025. Para protocolos que competem pela atenção do desenvolvedor em mercados em rápida evolução, um pipeline de segurança de seis meses pode ser muito lento para atrair o ecossistema de construção que impulsiona os efeitos da rede.
Há também um risco de concentração no conjunto de validadores. O limite de ativação de 80% significa que um número relativamente pequeno de validadores, muitos dos quais são operados por entidades com laços estreitos com a Ripple, controlam se as emendas entram em vigor. Os críticos argumentam que esta não é uma governança verdadeiramente descentralizada, mas um processo de aprovação com curadoria vestido com linguagem consensual. Quando o próprio validador da Ripple votou “sim” nas emendas de empréstimo nas últimas semanas, destacou quanta influência a empresa mantém sobre sua rede nominalmente descentralizada.
Finalmente, o pagamento de US$ 309.000 de um pool de US$ 550.000 levanta uma questão prática sobre o alinhamento dos incentivos. Pesquisadores de segurança de primeira linha comandam taxas que excedem o que os modelos de concurso normalmente pagam por hora de esforço. Se os auditores mais habilidosos pularem os concursos XRPL porque o pagamento esperado por descoberta é menor do que os compromissos privados, a revisão adversária pode ser ampla, mas não profunda o suficiente para capturar os vetores de ataque mais sofisticados.
Essas objeções têm peso. O XRP foi negociado perto de US$ 1,03 no final de julho de 2026, cerca de 71% abaixo de sua alta de US$ 3,65 em 17 de julho de 2025, sugerindo que o mercado ainda não precificou a narrativa institucional. Se o histórico de segurança se traduz em adoção depende de fatores além da qualidade do código: clareza regulatória, posicionamento competitivo contra as soluções Ethereum layer-2 e se as instituições se preocupam mais com auditorias pré-implantação do que com o tamanho do ecossistema.
JUST IN: Ripple expande sua presença em Washington, D.C. com um escritório maior. O movimento reflete o compromisso de longo prazo com o engajamento construtivo, regras claras da estrada e inovação financeira responsável https://t.co/1K0bS8tXrfpic.twitter.com/0Ba2eb0Cvp
— crypto.news (@cryptodotnews) 3 de junho de 2026
O que assistir
Limites de votação do validador para as cinco alterações 3.3.0: se BatchV1_1 e PermissionDelegationV1_1 limparem 80% do suporte dentro do primeiro ciclo de votação, isso sinaliza a confiança do validador nas reescritas. Uma barraca sugeriria preocupações persistentes sobre o código reescrito.
Relatórios de bugs pós-ativação: o verdadeiro teste do rigor da auditoria Sherlock vem depois que os recursos são lançados. Nenhuma descoberta crítica nos primeiros 90 dias validaria o modelo de pré-lançamento; qualquer vulnerabilidade pós-ativação prejudicaria toda a tese.
Adoção do RLUSD em Transferências Confidenciais: o uso institucional de stablecoin em trilhos blindados confirmaria a demanda por acordo compatível com privacidade. As métricas de volume no primeiro trimestre após a ativação serão o sinal mais claro de se os bancos estão prontos para transações em um livro-razão público com garantias de privacidade.
O próximo compromisso XRPL de Sherlock: se a Ripple continua com concursos de auditoria contraditórias para emendas futuras ou reverte para auditorias privadas tradicionais indicará o quão profundamente o modelo de pré-lançamento está incorporado na cultura de desenvolvimento.
Incidentes de segurança da cadeia concorrente: cada grande exploração no Ethereum ou Solana que remonta a uma vulnerabilidade pós-implantação fortalece o caso para o pipeline de ativação de auditoria-voto da XRPL. A comparação é tão forte quanto o fracasso contínuo da indústria em adotar processos semelhantes.
Leia mais: XRPL está silenciosamente construindo DeFi institucional
O que a auditoria de Sherlock do XRP Ledger encontrou?
O concurso de auditoria de duas semanas, que começou em 13 de abril de 2026, descobriu 96 vulnerabilidades válidas em cinco alterações XRPL propostas: 2 críticas, 6 altas, 29 médias e 59 questões de baixa gravidade. A Ripple pagou US$ 309.000 em recompensas RLUSD de um prêmio de US$ 550.000. Todas as descobertas foram abordadas antes de qualquer um dos recursos afetados serem ativados na rede principal.
Qual foi o bug crítico da alteração do Lote?
A alteração original do Batch continha uma falha de validação de assinatura que permitia que um invasor executasse transações internas de qualquer conta sem manter suas chaves privadas. O bug foi uma condição de saída antecipada na verificação de assinatura da transação externa que poderia ser satisfeita sem a verificação de autorização adequada. O pesquisador Pranamya Keshkamat e a ferramenta de IA da Cantina Apex a identificaram em 19 de fevereiro de 2026. RippleX corrigiu na versão de lançamento de emergência 3.1.1 quatro dias depois.
Como funcionou a vulnerabilidade de Delegação de Permissão?
A implementação original verificou as permissões do delegado antes de verificar as assinaturas da transação. No XRPL, as transações que falham com erros de classe “tec” ainda incorrem em taxas. Um invasor poderia enviar repetidamente transações inválidas com taxas elevadas contra uma conta delegada, drenando seu saldo XRP sem nunca segurar suas chaves. A correção reclassificou o tipo de erro e reordenou as verificações de verificação.
Algum fundo foi perdido por causa dessas vulnerabilidades?
Nenhum fundo foi perdido. Ambas as vulnerabilidades críticas foram identificadas antes de suas respectivas alterações serem ativadas na rede principal. O bug do Lote foi detectado durante a fase de votação do validador, e a falha de Delegação de Permissão foi divulgada e corrigida antes da ativação. O processo de alteração do XRP Ledger, que requer 80% de suporte ao validador por duas semanas consecutivas, forneceu um buffer estrutural que impediu a exploração.
O que é Sherlock e como funciona seu modelo de auditoria?
Sherlock é uma empresa de segurança Web3 que estrutura auditorias como concursos adversários, classificando pesquisadores por desempenho e oferecendo incentivos financeiros por meio de prêmios. O envolvimento XRP Ledger foi a primeira colaboração de Sherlock com a Ripple e um dos maiores concursos de auditoria de 2026. O modelo difere das auditorias privadas tradicionais, convidando ampla participação de pesquisadores de segurança independentes competindo por recompensas, o que revela uma gama mais ampla de vetores de ataque do que uma pequena equipe interna pode cobrir.
Como o modelo de segurança do XRPL difere do da Ethereum?
O processo de alteração do XRPL separa a implantação do código da ativação do recurso. Novos recursos são lançados em uma versão de software, mas permanecem inativos até que os validadores votem para ativá-los, criando uma janela de revisão onde as vulnerabilidades podem ser capturadas sem patches de emergência. Os contratos inteligentes do Ethereum estão ativos na implantação, e corrigir vulnerabilidades requer a implantação de novos contratos, a migração de usuários ou a implementação de atualizações de proxy. Nos primeiros cinco meses de 2026, as explorações da DeFi excederam US$ 840 milhões, e 70% dos contratos explorados foram auditados, mas não tinham monitoramento pós-implantação.
Quais recursos o XRP Ledger versão 3.3.0 inclui?
A versão 3.3.0, lançada em 6 de agosto de 2026, contém código para cinco alterações de recursos e um patch de limpeza. Os recursos incluem Transferências Confidenciais para Tokens Multiuso usando provas de conhecimento zero, Transações em Lote reescritas para liquidação atômica de várias operações, Delegação de Permissão reescrita para acesso controlado à conta, Taxas Patrocinados permitindo que os aplicativos cubram os custos do usuário e DynamicMPT permitindo que os emissores modifiquem as propriedades do token após a criação.
Essa auditoria torna o XRPL um investimento seguro?
A auditoria Sherlock reflete um rigoroso processo de segurança de pré-lançamento, mas a qualidade do código é um fator entre os muitos que influenciam os resultados do investimento. O XRP foi negociado perto de US$ 1,03 no final de julho de 2026, cerca de 71% abaixo de sua alta de ciclo, e o desempenho do mercado depende dos desenvolvimentos regulatórios, taxas de adoção institucional, dinâmica competitiva e condições macroeconômicas. Esta é uma análise educacional, não um conselho de investimento. Isenção de responsabilidade: Este artigo foi publicado em 14 de agosto de 2026. Destina-se apenas a fins educacionais e informativos e não deve ser interpretado como aconselhamento financeiro, de investimento ou jurídico. Os mercados de criptomoedas são voláteis e apresentam riscos substanciais. Os leitores devem realizar suas próprias pesquisas e consultar profissionais qualificados antes de tomar qualquer decisão de investimento.
#Xrp🔥🔥 #XRPGoal #XRPPredictions
