O que é um erro de checksum? O Guia de Detecção de Criptografia
Um erro de checksum significa que os dados falharam em um teste matemático. Em criptomoedas, esse teste é muito mais fraco do que a maioria dos usuários imagina. O EIP-55 do Ethereum detecta aproximadamente um erro de digitação a cada quatro mil. O Base58Check do Bitcoin é cerca de mil vezes mais robusto. O Bech32 é ainda mais forte. No entanto, nenhum desses checksums protege uma carteira contra o ataque que, de fato, drenou US$ 713 milhões de carteiras pessoais em 2025, porque o endereço malicioso presente na área de transferência ou no histórico de transações é, em si, uma string válida que passa no checksum. Isso explica o que é um erro de checksum, por que as carteiras de criptomoedas o exibem e por que um checksum sem erros não é garantia de segurança.
Resposta curta sobre erros de checksum em criptografia
Um erro de checksum informa ao usuário que um endereço, arquivo ou frase mnemônica não correspondeu ao teste de integridade interno. A carteira, exchange ou instalador se recusa a executar a ação porque um bit foi invertido, um caractere foi digitado incorretamente ou os dados foram adulterados. Em criptomoedas, o erro detecta erros de digitação e corrupção acidental. Ele não detecta um endereço digitado perfeitamente que o atacante controla. A maior perda documentada em carteiras em 2025, US$ 50 milhões em USDT em dezembro, ocorreu quando uma vítima copiou um endereço com um checksum perfeitamente válido, e o endereço simplesmente pertencia a um golpista.
O que é (e o que não é) um checksum
Imagine um checksum como um pequeno recibo para um pacote muito maior, um bloco de dados reduzido a poucos bytes por um cálculo conhecido. O remetente anexa o checksum original. O destinatário executa o mesmo cálculo, obtém um novo checksum e compara. Se houver correspondência, significa que a integridade dos dados foi mantida. Se não houver correspondência, significa corrupção de dados em algum lugar: um bit invertido na RAM, um download interrompido prematuramente, um caractere digitado incorretamente. A não correspondência é o que as carteiras e os instaladores sinalizam como um erro de checksum. Os valores de checksum calculados não corresponderam ao valor esperado associado aos dados originais (o valor armazenado que o remetente publicou). Nenhum erro de dados passou despercebido, porque a detecção básica de erros e as verificações de integridade foram acionadas.
Mecanicamente, os checksums clássicos são aritméticos, não criptográficos. A variante mais simples divide os dados em palavras e realiza a adição em complemento de um (o truque do "complemento de 1" usado no consagrado checksum TCP/IP da internet, de 1988). Um pouco mais sofisticados são a paridade longitudinal, o algoritmo de Fletcher e os CRCs (verificações de redundância cíclica), todos muito semelhantes entre si. Uma verificação de redundância cíclica é rápida e eficaz para erros de transmissão. Para a integridade de arquivos modernos, a escolha dominante é o Adler-32 (rápido, sem criptografia) ou o MD5 ou SHA (mais lentos, mas muito mais robustos). Ferramentas de software como `sha256sum`, `md5sum` e HashCheck são a forma como a maioria dos usuários realiza uma verificação.
Aqui está o limite. Um checksum pode provar que os dados não foram corrompidos ou adulterados acidentalmente no nível do byte. Nada mais. Ele não pode provar quem criou os dados. O SHA-256, um hash criptográfico, é muito mais forte que um CRC. Mesmo assim, não prova a autoria; para isso, o editor assina o hash com uma chave privada. Usuários de criptomoedas confundem os dois o tempo todo. "O endereço passou na validação do checksum" não é o mesmo que "o endereço pertence à pessoa certa". Qualquer pessoa pode gerar um endereço Ethereum ou Bitcoin válido. Somente o detentor da chave privada controla os fundos. A verificação do checksum confirma que o endereço está bem formado. A qual carteira ele aponta? Essa é uma questão diferente, com uma resposta diferente.
Como funcionam os algoritmos de checksum criptográfico: EIP-55, Base58Check, Bech32
Três esquemas reais dominam o mercado de criptomoedas para o varejo, e cada um foi projetado com uma prioridade diferente.
EIP-55 é o checksum de maiúsculas e minúsculas do Ethereum. Vitalik Buterin e Alex Van de Sande o propuseram em 14 de janeiro de 2016. Ele funciona convertendo o endereço para minúsculas, aplicando um hash Keccak-256 à string em minúsculas e, em seguida, convertendo as letras hexadecimais (A–F) de volta para maiúsculas de acordo com os bits desse hash. Apenas as 15 letras hexadecimais em um endereço típico podem ter suas maiúsculas e minúsculas invertidas, o que confere ao esquema aproximadamente 15 bits de verificação efetivos. O EIP-1191, proposto em março de 2018, estende o EIP-55 com o ID da cadeia, de modo que o checksum de um endereço no Ethereum e em uma cadeia bifurcada como a Rootstock não entrem em conflito.
Base58Check é o esquema legado do Bitcoin. Ele adiciona um checksum de 4 bytes ao final do endereço codificado, calculado como os primeiros 4 bytes do SHA-256 duplo do byte de versão mais a carga útil. O prefixo "1" em um endereço P2PKH corresponde a um byte de versão 0x00; o prefixo "3" em um endereço P2SH corresponde a 0x05. O próprio alfabeto Base58 omite os caracteres visualmente confusos 0, O, I e l. A implementação da lógica de checksum para Base58Check consiste em uma única chamada SHA-256 seguida por uma comparação de 4 bytes.
O Bech32 (BIP-173) é o esquema de endereçamento SegWit de Pieter Wuille e Greg Maxwell, datado de 2017. Seu código BCH de 6 caracteres garante a detecção de todos os erros que afetam até quatro caracteres e mantém a taxa de erros não detectados abaixo de um em um bilhão para corrupções mais longas. Uma descoberta sutil de 2020 (que a inserção ou remoção de um 'q' antes de um 'p' final pode preservar o checksum) motivou o BIP-350 Bech32m, que o Taproot (versão testemunha 1) agora utiliza.
| Plano | Ano | Exemplo de endereço | Verifique o tamanho | Detecção típica de erros de digitação |
|---|---|---|---|---|
| EIP-55 / EIP-1191 | 2016 / 2018 | `0xAbCd...EfGh` | ~15 bits | Aproximadamente 99,97% (1 em cada 4.000 erros) |
| Base58Check (P2PKH) | 2009 | `1A1zP1...` | 32 bits | ~99,99999998% |
| Base58Check (P2SH) | 2012 | `3J98t1...` | 32 bits | ~99,99999998% |
| Bech32 (SegWit v0) | 2017 | `bc1q...` | ~30 bits | ≥99,999999999% em erros de 4 caracteres |
| Bech32m (Raiz) | 2020 | `bc1p...` | ~30 bits | igual, corrige a inserção de qp |
A tabela representa o par de números mais importante do artigo. Considere-os como orçamentos de projeto, não como garantias de segurança.
Por que o EIP-55 detecta apenas 1 erro de digitação em 4.000?
A especificação EIP-55 cita explicitamente a taxa de falhas: a probabilidade de um erro de digitação aleatório em um endereço Ethereum passar pela verificação de integridade é de 0,0247%, ou cerca de uma em 4.049. Isso não é um bug. É o que 15 bits de verificação efetivos proporcionam. O esquema foi uma adaptação de 2016, projetado para ser compatível com o formato de endereço hexadecimal de 40 caracteres existente. A compatibilidade tem um custo: a força de detecção.
Para o funcionamento prático de uma carteira, isso geralmente funciona bem. Um usuário que digita ou cola o endereço uma única vez tem uma probabilidade extremamente alta de ser detectado se cometer um deslize. Um usuário que cola o mesmo endereço corrompido dez vezes seguidas passará pela verificação de checksum todas as vezes, porque o endereço é válido. A diferença de mil vezes em relação ao Base58Check do Bitcoin, e o salto adicional para o Bech32, é o motivo pelo qual uma experiência de usuário (UX) de carteira séria trata a verificação de endereços Ethereum como responsabilidade do usuário, e não do protocolo.
Erros de checksum fora da criptografia: WinRAR, BIOS, firmware, disco rígido
A maioria das pessoas que digitam "erro de checksum" no Google não são usuárias de criptomoedas. Elas estão olhando para o WinRAR, para a tela de inicialização travada do PC ou para um NAS instável. O vocabulário é o mesmo. Mas as consequências são completamente diferentes.
O WinRAR é o clássico. Você baixa um arquivo .rar, extrai-o e aparece uma mensagem de erro de CRC. O arquivo está corrompido. Geralmente, a causa é banal: um download interrompido, uma conexão Wi-Fi instável, um setor defeituoso no disco, ocasionalmente um malware que afetou o arquivo durante a transferência. Baixe novamente da fonte original. Execute o CHKDSK. Se você realmente precisar recuperar o que está lá, a opção "manter arquivos corrompidos" do WinRAR extrairá uma cópia parcial do conteúdo.
Um erro de checksum na BIOS ou CMOS durante a inicialização do PC quase sempre ocorre devido à bateria tipo moeda CR2032 da placa-mãe estar descarregada. Às vezes, uma atualização de firmware com falha corrompe a NVRAM. Outras vezes, o usuário remove um módulo de RAM e a identificação do hardware armazenada não corresponde mais. Recoloque a bateria. Restaure as configurações padrão. O computador inicializa.
ZFS e Btrfs geram erros de checksum quando um disco rígido retorna um bloco que não corresponde ao hash armazenado. Esses erros são literalmente a intenção do projeto: a deterioração silenciosa de dados finalmente vindo à tona.
O que realmente deveria deixar um usuário de criptomoedas apreensivo é um erro de checksum no firmware de uma carteira de hardware. O bootloader da Trezor verifica novamente a assinatura do firmware a cada inicialização. O elemento seguro da Ledger faz o mesmo. "Assinatura inválida" ou "Erro desconhecido (0x6984)" da Ledger durante a instalação é o dispositivo avisando, em alto e bom som, que o firmware detectado não corresponde ao que sua chave raiz espera. Pare. Desconecte. Baixe novamente o firmware do site do fornecedor que você consegue recitar de cor. Qualquer pessoa que ignorar esse aviso acaba de entrar na zona de risco de um ataque à cadeia de suprimentos.
Quando um erro de checksum significa adulteração — e quando não significa.
A principal conclusão deste artigo é que os checksums detectam bem a corrupção aleatória. No entanto, eles são ineficazes contra um atacante que escolheu um endereço válido propositalmente.
O Relatório de Crimes com Criptomoedas da Chainalysis estima que o roubo total de criptomoedas em 2025 chegará a US$ 3,4 bilhões, sendo US$ 1,5 bilhão provenientes do ataque hacker à Bybit. Carteiras pessoais perderam US$ 713 milhões, afetando cerca de 80.000 vítimas em aproximadamente 158.000 incidentes. Quase nenhuma dessas perdas foi causada por erros de digitação em checksums inválidos, pois exchanges e carteiras rejeitam esses erros no campo de entrada. As perdas foram resultado de dois tipos de ataques que checksums válidos não conseguem impedir.
A primeira tática é o envenenamento de endereço. O atacante envia uma pequena transação de teste a partir de um endereço recém-gerado, projetado para compartilhar os primeiros e últimos caracteres de um endereço de contato frequente da vítima. Na próxima vez que a vítima copiar um endereço do histórico de transações, o endereço falsificado estará no topo da lista. O endereço possui um checksum perfeitamente válido. A carteira mostra saldo positivo. Os fundos vão para o atacante. Um dado da Chainalysis, citado pela Carnegie Mellon, estima que haverá 270 milhões de tentativas de envenenamento de endereço em 2025, visando 17 milhões de vítimas potenciais. O incidente de 20 de dezembro de 2025, no qual um trader perdeu US$ 50 milhões em USDT, ocorreu aproximadamente 26 minutos após a vítima enviar uma pequena transação de teste; o teste não a salvou, porque o endereço envenenado já havia sido inserido no histórico.
O segundo tipo de malware são os sequestradores de área de transferência. Malwares como a campanha GitVenom, documentada pela Kaspersky, substituem silenciosamente qualquer endereço criptográfico copiado para a área de transferência por um endereço controlado pelo atacante. As perdas estimadas apenas com o GitVenom chegaram a aproximadamente US$ 485.000 no final de 2024, com vítimas no Brasil, Turquia e Rússia. Novamente, o endereço substituído possui um checksum válido. A carteira não apresenta nenhum sinal suspeito. Dados críticos, o destino de uma grande transferência, passam pela camada de integridade porque nunca foram alterados ou corrompidos; foram substituídos por algo igualmente válido.
| Ataque de 2025 | Mecanismo | A verificação de integridade impediu isso? |
|---|---|---|
| Envenenamento de endereços (US$ 50 milhões em dólares americanos, 20 de dezembro de 2025) | Endereço falsificado semelhante no histórico de transações | Não — o endereço falsificado possui um checksum EIP-55 válido. |
| Sequestradores de área de transferência (GitVenom, aproximadamente US$ 485 mil) | O malware substitui o endereço copiado | Não — o endereço substituído é válido. |
| Golpes com bots MEV usando o tema ChatGPT (mais de 30 ETH, mais de 100 vítimas) | Contrato recomendado por IA esvazia a carteira | Não — o checksum não tem nada a ver com a intenção do contrato. |
| Golpes com auxílio de IA em geral | 4,5 vezes mais rentável do que os esquemas tradicionais | Não — depende de engenharia social, não de erros de digitação nos endereços. |
Um checksum verde significa que o endereço está bem formado. Isso não significa que ele seja seu. Essa distinção é a informação mais importante que um usuário de criptomoedas pode tirar deste artigo.
Frase-semente BIP-39: por que palavras válidas ainda falham na verificação de soma de verificação?
As frases-semente BIP-39 também possuem um checksum, o que surpreende as pessoas durante a recuperação. O esquema codifica os últimos bits do SHA-256 sobre a entropia da carteira na palavra final da frase. Uma frase-semente de 12 palavras carrega apenas 4 bits de checksum. Uma frase-semente de 24 palavras carrega 8. Para 12 palavras, isso significa que apenas cerca de uma escolha aleatória da última palavra em dezesseis passará na validação. "Tenho certeza de que minha frase-semente está correta, mas a carteira a rejeita" é, na grande maioria das vezes, um erro de digitação no início da frase ou uma palavra incorreta da lista BIP-39 de 2.048 palavras.
O lado do hardware é mais rigoroso. A Trezor e a Ledger verificam novamente as assinaturas do firmware a cada inicialização por meio de código de elemento seguro, e não no host. Uma incompatibilidade de assinatura é tratada como adulteração e o firmware se recusará a executar. Esse é o comportamento correto. Qualquer pessoa que se depare com um erro de checksum ou de assinatura de firmware em uma carteira de hardware deve considerá-lo um alerta, não uma falha.
Como verificar e corrigir um erro de checksum: boas práticas
A lista de verificação é curta. É a mesma para a maioria das carteiras e corretoras.
Endereço Ethereum. Copie do canal verificado da contraparte (o perfil público dela, não uma mensagem direta do Telegram). Cole. Deixe a carteira validar. Envie US$ 1 como transação de teste. Aguarde a confirmação. Em seguida, envie o valor total. A Kraken armazena todos os endereços ETH salvos no formato EIP-55 por padrão. A Binance e a Coinbase rejeitam endereços com checksum inválido na etapa de envio, antes que qualquer transmissão atinja a blockchain. O MetaMask usa o formato EIP-55 por padrão e exibe um aviso para endereços editados manualmente; historicamente, ele também aceitava endereços totalmente em minúsculas, o que gerou diversas reclamações em fóruns do GitHub ao longo dos anos.
Endereço Bitcoin. Prefira o formato Bech32 (`bc1...`) aos formatos legados `1...` e `3...` quando a contraparte o suportar. A capacidade de detecção de erros é significativamente maior e o formato do endereço é mais difícil de ser interpretado incorretamente.
Download de arquivos. Binário da carteira, imagem de firmware para carteira de hardware, ISO do Linux. Calcule o hash SHA-256 localmente. Compare com o valor assinado pelo editor, não com a cópia impressa ao lado do link de download. Um ataque do tipo "homem no meio" que controla a página de download pode trocar ambos. Mantenha um backup de qualquer arquivo verificado do qual você realmente dependa. Detectar erros posteriormente é muito mais fácil quando uma cópia confiável está armazenada em um pen drive ou impressa em papel.
Erro de checksum ou assinatura no firmware da carteira de hardware. Não ignore. Baixe novamente a partir do URL documentado pelo fornecedor. Tente usar um cabo diferente. Tente usar uma porta USB diferente. Reinicie o Ledger Live ou o Trezor Suite. Se o erro persistir, entre em contato com o suporte do fornecedor. Pesquisas por "corrigir Ledger 0x6984" em fóruns de terceiros são onde os atacantes aguardam.
Uma frase para lembrar: um checksum válido prova que os dados não foram corrompidos acidentalmente. Não prova que os dados são exatamente o que você queria enviar.
