--- title: "Envenenamento de endereço" description: "O envenenamento de endereço insere um destinatário parecido no histórico de transações ou em outra interface aparentemente confiável para que um pagamento posterior seja copiado para o invasor; ele explora a verificação do destinatário, sem alterar o endereço real nem roubar sua chave." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Envenenamento de endereço > Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas. ## Resposta direta O envenenamento de endereço é uma fraude de substituição do destinatário. O invasor gera outro endereço cujo prefixo e sufixo visíveis se parecem com os de um destinatário confiável e o insere no histórico de transações ou em outra interface aparentemente confiável. Ele espera que um remetente copie depois esse endereço parecido e assine um pagamento válido para ele. O ataque não altera o endereço legítimo, não viola sua chave privada nem faz o consenso desviar a transferência. O registro inserido pode resultar de uma transação real de ativo nativo, de uma transferência de token de valor zero compatível com o padrão ou de um log emitido por outro contrato de token. As páginas de atividade de wallets e exploradores são visualizações derivadas: uma linha rotulada como “enviado” pode vir de campos de eventos, não de uma transação externa assinada pelo endereço `from` exibido. Verifique separadamente remetente e destino da transação externa, contrato chamado, contrato emissor do evento, campos indexados e mudanças reais de saldo. O checksum ERC-55 ajuda a detectar alguns erros acidentais de digitação, mas outro endereço do invasor pode ser sintaticamente válido e ter checksum correto. Endereços EVM comuns de 20 bytes também não identificam por si sós a chain pretendida, o ativo, a função do destinatário, o memo de depósito nem a chamada ao contrato. Uma instrução de pagamento segura vincula todos esses fatos ao destino completo. ## Como funciona O invasor observa um padrão público de pagamentos e busca um vanity address que corresponda aos caracteres que a wallet exibe de forma truncada. Fazer alguns caracteres hexadecimais coincidirem não clona uma conta: os bytes ocultos continuam diferentes e o invasor controla a nova chave. Uma transferência minúscula pode inserir esse endereço real no histórico. Separadamente, o ERC-20 exige que transferências de valor zero sejam tratadas como transferências normais e emitam `Transfer`; portanto, um registro de valor zero não comprova, por si só, falsificação, comprometimento, autorização nem perda econômica. Um contrato de token malicioso também pode emitir seu próprio log `Transfer(victim, lookalike, 0)`. Esse log é um dado real do recibo atribuível ao contrato emissor, mas não é um evento do contrato canônico do ativo nem comprova que a vítima assinou a transação externa. Ainda assim, um indexador que classifique atividade por topics de eventos sem contexto suficiente do contrato e da chamada pode apresentar uma linha de saída enganosa. O controle decisivo é a intenção final do pagamento. Ela deve vincular chain e rede, ativo nativo ou contrato exato do token, endereço completo e tipo do destinatário, valor e unidades raw, além de qualquer calldata, memo, destination tag ou período de validade. Endereços de depósito de exchanges, bridges, proxies e rotas de uso único podem ficar obsoletos ou exigir mais que um endereço. Malware de área de transferência e códigos QR comprometidos são ataques distintos, mas a mesma verificação do destino completo detecta a substituição antes da assinatura. Nomes e pagamentos de teste são controles auxiliares, não provas de identidade. Resolva um nome ENS para a chain e o registro pretendidos no momento da assinatura; se um nome reverso for exibido, faça a resolução direta de volta ao mesmo endereço. Um pequeno teste só ajuda quando o destinatário o confirma de forma independente e o pagamento principal reutiliza o mesmo destino fixado. Copiar novamente do histórico descarta essa proteção. Use este fluxo de trabalho: 1. Fixe chain, rede, ativo e contrato exato do token, tipo de destinatário, formato do endereço, valor e qualquer memo, tag, calldata, versão ou expiração com base em uma fonte independente autenticada. 2. Resolva uma vez o nome ou QR, valide formato e checksum e vincule os bytes completos do destino à chain pretendida; confirme diretamente qualquer nome reverso em vez de tratar o rótulo como identidade. 3. Compare o destino com uma allowlist controlada, catálogo de endereços ou fatura assinada, nunca com o histórico; exija aprovação independente ou dupla para destinatário novo ou alterado de forma relevante. 4. Decodifique a transação exata ainda não assinada: diferencie o `to` nativo de um contrato de token ou bridge e inspecione na calldata destinatário, token, valor raw, aprovação, deadline e semântica do destino. 5. Quando apropriado, envie um pequeno teste ao destino fixado e obtenha confirmação independente do destinatário; não copie novamente um endereço do histórico para o pagamento principal. 6. Assine a transferência principal apenas a partir do registro verificado, compare destino e valor completos em uma tela confiável e depois confira recibo, contrato emissor, logs e variações de saldo na chain correta. 7. Se houver suspeita de envenenamento ou envio incorreto, interrompa pagamentos posteriores, preserve hashes e evidências e contate prontamente o serviço destinatário, emissor ou autoridades quando pertinente; trate congelamento, devolução e recuperação como condicionais, nunca garantidos. ## Exemplos - **O truncamento oculta a diferença.** O endereço legítimo `0x12ab1111111111111111111111111111111189ef` e o do invasor `0x12ab9999999999999999999999999999999989ef` aparecem ambos como `0x12ab...89ef`. Eles compartilham `4 + 4 = 8` caracteres hexadecimais exibidos, mas diferem em todos os `32` caracteres centrais. Comparar só as extremidades renderizadas produz uma falsa correspondência; comparar todos os bytes, não. - **Trabalho da busca vanity.** Fazer corresponder `k = 8` caracteres hexadecimais escolhidos exige trabalho esperado de `16^8 = 4,294,967,296` candidatos. A uma velocidade hipotética de `50,000,000 candidates/s`, o tempo esperado é `4,294,967,296 / 50,000,000 = 85.89934592 s`. Isso ilustra um espaço de busca, não um tempo de execução prometido nem um limite de alerta da wallet. - **Log versus estado.** Um contrato de token emite `Transfer(victim, lookalike, 0)`. O saldo da vítima passa de `250,000.000000` para `250,000.000000`, portanto a variação é `0.000000`; um índice de atividade ainda pode exibir uma linha de transferência. Confira o contrato emissor e a autorização da chamada: a linha isolada não comprova movimentação de valor nem assinatura da vítima. - **Um teste deve fixar o destino.** Uma tesouraria planeja `50,000 USDC`, envia `1 USDC` a um endereço verificado, recebe confirmação independente e envia `49,999 USDC` usando o mesmo registro fixado: `1 + 49,999 = 50,000 USDC`. Se a equipe copiar novamente um endereço parecido do histórico para a segunda etapa, o teste deixa de proteger o pagamento de `49,999 USDC`. ## Riscos - O remetente copia um endereço parecido de um histórico envenenado. - Uma interface truncada oculta os caracteres centrais diferentes. - Um prefixo ou sufixo vanity é confundido com identidade do destinatário. - Uma transferência ERC-20 de valor zero cria uma linha de histórico enganosa. - Um token falsificado ou seu log é confundido com atividade do ativo canônico. - Um indexador classifica mal campos de eventos ou os corrige tarde demais. - Nome, símbolo ou ícone de token spam imita um ativo confiável. - Malware da área de transferência substitui um endereço verificado antes da assinatura. - Um catálogo de endereços local ou sincronizado está envenenado ou obsoleto. - Uma allowlist vincula chain, ativo, função ou versão do endereço incorretos. - Um aviso de checksum inválido ou ausente é ignorado. - Um checksum válido é confundido com prova de identidade do destinatário. - A resolução ENS muda, usa o coin type errado ou fica obsoleta. - Um nome reverso é exibido sem confirmação por resolução direta. - Após um teste, o endereço é copiado novamente de uma fonte não confiável. - O endereço de depósito, rede, memo ou tag de um exchange está errado ou expirado. - O destino e a calldata exigida por bridge, proxy ou contrato são mal interpretados. - O signatário verifica apenas texto truncado, até mesmo em dispositivo de hardware. - Uma transferência ao destinatário errado se torna canônica antes da intervenção. - A vítima depende do congelamento discricionário pelo emissor ou de um golpe de recuperação. ## Equívocos comuns - **Envenenamento de endereço significa que wallet, chave ou blockchain foi invadida.** O ataque comum explora a seleção do destinatário enquanto criptografia e consenso válidos executam a intenção assinada errada. - **Uma linha de valor zero deve ser uma transação on-chain falsa.** Transferências compatíveis e logs reais podem ter valor zero; inspecione sua origem e efeito no estado. - **Extremidades iguais mais checksum comprovam o destinatário.** Outro endereço válido pode corresponder aos caracteres visíveis e ter seu próprio checksum válido. - **Um teste bem-sucedido protege automaticamente a próxima transferência.** A proteção se perde se o pagamento principal não reutilizar o destino fixado e confirmado. - **Wallet, validador ou emissor do token sempre pode reverter o pagamento.** Poderes e cooperação para recuperação dependem de ativo, serviço, jurisdição, evidências e tempo. ## Tópicos relacionados - [Golpes de phishing](/pt-br/crypto/phishing-scam/) - [Simulação de transações](/pt-br/crypto/transaction-simulation/) - [Wallet de criptoativos](/pt-br/crypto/wallet/) ## Fontes - [Address poisoning scams](https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/address-poisoning-scams/) - MetaMask Help Center (acesso: 2026-08-13) - [Anatomy of an Address Poisoning Scam](https://www.chainalysis.com/blog/address-poisoning-scam/) - Chainalysis (acesso: 2026-08-13) - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (acesso: 2026-08-13) - [ERC-55: Mixed-case checksum address encoding](https://eips.ethereum.org/EIPS/eip-55) - Ethereum Improvement Proposals (acesso: 2026-08-13) - [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org (acesso: 2026-08-13) - [Resolution](https://docs.ens.domains/resolution/) - ENS Documentation (acesso: 2026-08-13) - [Frequently asked questions](https://ethereum.org/en/community/support/faq/) - ethereum.org (acesso: 2026-08-13) - [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (acesso: 2026-08-13) Source: https://wiki.fcontext.com/pt-br/crypto/address-poisoning/index.mdx