Rastreamento no modelo de contas, de tokens e de NFTs

Na Ethereum e em outras blockchains baseadas no modelo de contas, grande parte do valor em uma fraude ou furto típico nunca aparece como uma simples transferência entre dois endereços. Ele se movimenta dentro de chamadas de contratos, como eventos de tokens cujo conteúdo o próprio contrato decidiu emitir, ou por meio de uma assinatura que a vítima forneceu dias antes. Um perito que rastreia apenas a aba "transações" de um explorador deixará de identificar etapas, descreverá incorretamente quem movimentou os fundos e apresentará valores que a outra parte poderá refutar usando a mesma blockchain, às vezes por um fator de um trilhão.

Quatro lugares em que o valor se movimenta

Cada canal é registrado em um lugar diferente, portanto o registro de cada etapa deve indicar de onde vieram suas evidências.

As transferências internas são a fonte mais comum de etapas não identificadas: um swap que paga ETH nativo, um contrato de encaminhamento ou um contrato de carteira que agrupa operações movimenta ETH por meio de chamadas que não deixam logs. Obtê-las exige um nó com capacidade de rastreamento, geralmente um nó de arquivo, e os nomes dos métodos variam entre clientes (debug_traceTransaction com um rastreador de chamadas em alguns, trace_transaction em outros). Registre o cliente, a versão e o método usados em cada rastro, pois dois rastreadores podem apresentar a mesma execução de maneiras diferentes (as aulas 2.4, 2.9 e 5.1 abordam a decodificação).

Leitura de transferências ERC-20

Um token ERC-20 (EIP-20) é um contrato que mantém um mapeamento de endereços para saldos. Quando alguém "envia USDC", o campo to da transação é o contrato do token (ou um roteador), seu value nativo geralmente é 0, e o destinatário aparece apenas nos dados da chamada e nos logs. Alterações de saldo emitem Transfer(address indexed _from, address indexed _to, uint256 _value), com topic0 0xddf252ad…b3ef em todas as blockchains EVM, remetente e destinatário nos tópicos 1 e 2, e o valor bruto em data.

A identidade do token é o endereço do contrato que emite o log, nunca seu nome ou símbolo: qualquer pessoa pode implantar um contrato chamado "USDC" que emita eventos Transfer perfeitamente formatados. Os eventos também são escritos pelo código do próprio contrato, portanto um contrato malicioso pode emitir eventos Transfer que não correspondem a nenhuma alteração de saldo. Filtre ou sinalize transferências de valor zero e transferências de tokens não listados antes da análise.

Casas decimais e unidades

O log armazena um inteiro em unidades básicas. O valor de casas decimais que o converte em unidades legíveis para humanos não está no evento; leia-o uma vez por contrato usando decimals() e armazene-o com sua fonte.

Aplicar 18 casas decimais a um token de 6 casas decimais subestima os valores por um fator de 10^12; o inverso os superestima pelo mesmo fator. O mesmo ativo pode usar casas decimais diferentes em blockchains diferentes, pois versões transferidas por pontes e reemitidas são contratos separados. Os valores brutos são inteiros de 256 bits (até 78 dígitos), portanto armazene-os como strings ou decimais de alta precisão e faça a divisão apenas na apresentação.

Emissões, queimas e tokens que fogem ao modelo

Emissões são eventos Transfer a partir do endereço zero, e a maioria das queimas são eventos Transfer para ele; enviar tokens para um endereço "morto", como 0x…dEaD, não é uma queima, pois o saldo ainda existe. Alguns tokens fogem dessa convenção com eventos personalizados Mint e Burn, e o contrato WETH original (WETH9) emite Deposit e Withdrawal sem Transfer, portanto um saldo de WETH reconstruído apenas com logs Transfer estará incorreto para qualquer endereço que faça wrapping ou unwrapping.

A regra "saldo = valores de Transfer recebidos menos enviados" também falha nos seguintes casos:

O stETH da Lido é um exemplo conhecido de rebasing: os saldos crescem quando o oráculo do protocolo informa recompensas, sem emissão de Transfer, e as transferências podem deixar para trás 1–2 wei devido ao arredondamento de cotas. Sua versão encapsulada, wstETH, comporta-se como um ERC-20 comum.

Antes de relatar fluxos de tokens, faça a conciliação: identifique inequivocamente o token pelo endereço do contrato e pelo ID da blockchain; reconstrua os saldos relevantes a partir dos logs Transfer até o bloco de corte; compare-os com balanceOf, e as emissões menos as queimas com totalSupply(), nesse bloco; e explique cada diferença ou declare-a como uma limitação. Eventos de tokens são declarações feitas pelo código do contrato; consultas de estado as verificam.

Aprovações, transferFrom e drainers

O ERC-20 permite que um proprietário autorize um agente autorizado a gastar com approve(spender, amount), que emite Approval(owner, spender, value). O agente autorizado a gastar, normalmente um roteador de DEX ou um pool de empréstimos, chama posteriormente transferFrom(owner, recipient, amount), e no Transfer resultante o campo from é o proprietário cujos tokens foram movimentados, não a conta que enviou a transação. Aprovações ilimitadas (2^256 − 1, 64 dígitos hexadecimais f) permitem que o agente autorizado a gastar movimente todo o saldo do proprietário a qualquer momento. Os limites autorizados nem sempre podem ser reconstruídos a partir dos eventos (a biblioteca amplamente copiada da OpenZeppelin deixou de emitir um novo Approval quando transferFrom consome um limite autorizado na versão 5.0), portanto leia allowance(owner, spender) no bloco de interesse.

Um drainer é um kit de phishing que convence uma vítima a conceder um direito de gasto e depois o utiliza. A ação da vítima é uma das seguintes:

1. uma transação de aprovação on-chain, muitas vezes ilimitada, assinada e enviada pela vítima;
2. uma assinatura permit off-chain (EIP-2612), que o atacante submete e pela qual paga gas; a especificação permite que qualquer endereço submeta um permit válido, e um permit bem-sucedido define o limite autorizado e emite um evento Approval em uma transação que a vítima nunca enviou;
3. uma assinatura para um contrato de aprovação compartilhado que a vítima já havia aprovado e que então autoriza a transferência.

O contrato do drainer então chama transferFrom e divide os valores obtidos. Um estudo de He e colegas da Zhejiang University e da Mohamed bin Zayed University of Artificial Intelligence (Desvendando a economia clandestina: uma análise aprofundada do phishing com drainer como serviço na Ethereum, 2025), abrangendo março de 2023 a abril de 2025, constatou que a divisão mais comum era de 20% para o operador do kit e 80% para o afiliado que conduzia a campanha de phishing. Uma divisão fixa repetida entre muitas vítimas é um padrão forte, mas continua sendo uma inferência sobre os papéis até que outras evidências a confirmem.

Parte das evidências, portanto, está fora da blockchain. Com autorização legal, o dispositivo da vítima pode conter o histórico de navegação do site de phishing e o registro de solicitações de assinatura da carteira, que, juntos, permitem datar a ação da vítima (aula 7.3). Assinaturas off-chain não deixam nada na blockchain até serem usadas, portanto o intervalo entre a assinatura e a drenagem pode ser longo.

Rastreamento demonstrado: um drainer com permit

Uma vítima relata a perda de 25.000 USDC. O perito decodifica as transações relevantes a partir de um nó com capacidade de rastreamento:

tx 0x3b9e…a417  bloco 24,598,331  status 1  remetente 0xD7c4…19
  chamada  0xD7c4…19 -> 0x8f2A…c3 (contrato, não verificado)
  log 41  token 0xA0b8…eB48  Approval  proprietário 0x5e1C…2e  agente autorizado 0x8f2A…c3  valor 25000000000
  log 42  token 0xA0b8…eB48  Transfer  de 0x5e1C…2e  para 0x0dE3…7a  valor 5000000000
  log 43  token 0xA0b8…eB48  Transfer  de 0x5e1C…2e  para 0xAf10…d0  valor 20000000000

tx 0x77c0…5b12  bloco 24,598,402  status 1  remetente 0xAf10…d0
  log 7   token 0xA0b8…eB48  Transfer  de 0xAf10…d0  para 0x9c3B…e1 (pool)  valor 20000000000
  log 9   token WETH         Transfer  de 0x9c3B…e1  para 0x4d1F…80 (roteador)  valor 7.9e18
  rastro [0,3]  CALL  0x4d1F…80 -> 0xF5a9…31  valor 7.9 ETH

tx 0x1e44…c9a0  bloco 24,598,460  status 1  remetente 0xF5a9…31
  valor de nível superior  0xF5a9…31 -> 0x2bD1…f6  7.89 ETH

A primeira transação não foi enviada pela vítima. Seu remetente chamou um contrato não verificado, que submeteu o permit da vítima (log 41, um limite autorizado de 25.000 USDC com 6 casas decimais) e retirou 5.000 e 20.000 USDC do endereço da vítima na mesma transação (logs 42 e 43). Os valores conferem: 5.000 + 20.000 = 25.000, uma divisão de 20/80. Um relatório afirmando que "a vítima enviou 25.000 USDC" descreveria incorretamente um evento que a chave da vítima nunca assinou. Na segunda transação, o destinatário da maior parcela trocou seus 20.000 USDC por meio de um pool; o roteador fez o unwrapping de 7,9 WETH e enviou 7,9 ETH para um novo endereço. Essa etapa aparece apenas no rastro na posição [0,3]: um perito que lesse apenas os logs perderia o rastro dos fundos nesse ponto. Na terceira transação, o novo endereço enviou 7,89 ETH, mantendo cerca de 0,01 ETH, dos quais pagou gas, para 0x2bD1…f6, que encaminha seus depósitos para uma carteira quente de uma exchange.

Todos os fluxos aqui são de grau A: registrados na blockchain e verificáveis a partir de um nó. Os papéis de operador e afiliado são inferências a partir da divisão. A classificação como depósito de exchange é uma única heurística até que a exchange a confirme e, a partir daí, o rastreamento continua conforme descrito na aula 3.4.

Registro de uma etapa intermediada por contrato

O registro de etapa da aula 3.2 precisa de campos adicionais em blockchains baseadas em contas: o índice do log ou a posição no rastro, pois uma transação pode conter dezenas de transferências; o endereço do contrato do token, suas casas decimais e o valor inteiro bruto; o remetente da transação, além de from e to da transferência, pois frequentemente são partes diferentes; e o status da transação, já que transações revertidas deixam rastros, mas nenhuma transferência permanente.

Duas armadilhas de identidade são específicas dos tokens. Tokens falsificados copiam o nome e o símbolo de uma stablecoin real; apenas o endereço do contrato mostra qual é genuíno. O envenenamento de endereços envia transferências de valor zero, de valores ínfimos ou falsas a partir de um endereço semelhante a um que a vítima utiliza, na esperança de que ela o copie do histórico. Sempre compare os endereços completos, nunca apenas os primeiros e últimos caracteres.

Stablecoins e visibilidade do emissor

Transferências de stablecoins são eventos comuns de tokens e podem ser rastreadas de forma determinística, com duas características adicionais. Primeiro, os contratos das principais stablecoins lastreadas em moeda fiduciária dão ao emissor uma função de congelamento (lista de bloqueio), de modo que um saldo que ainda não foi movimentado pode, às vezes, ser bloqueado mais rapidamente do que por qualquer ordem judicial (aula 10.1). Segundo, o emissor vê a mesma blockchain que todos os demais e mantém registros de identidade apenas de seus clientes diretos, normalmente aqueles que emitem e resgatam tokens: ele pode confirmar quais endereços congelou e quem emitiu ou resgatou, não quem controla o endereço de um detentor comum. Registre a blockchain e o endereço do contrato em cada etapa com stablecoins: o mesmo símbolo existe em muitas blockchains, e uma versão transferida por ponte é um contrato separado que o congelamento do emissor original talvez não alcance. Grandes fluxos de stablecoins na Tron são abordados na aula 5.4.

NFTs e padrões multitoken

Um token ERC-721 atribui a cada ID de token exatamente um proprietário. Seu Transfer(address,address,uint256) tem o mesmo topic0 do ERC-20, pois indexed não faz parte da assinatura, mas o ID do token é indexado: um Transfer ERC-721 tem quatro tópicos e dados vazios, enquanto um Transfer ERC-20 tem três tópicos com o valor nos dados. Um decodificador baseado apenas no topic0 interpreta IDs de tokens como valores. ApprovalForAll permite que um operador, geralmente um contrato de marketplace, movimente todos os tokens que o proprietário possui em uma coleção, e um phishing que obtenha essa aprovação pode esvaziar uma coleção em uma única transação: é o primeiro evento a verificar quando uma vítima relata NFTs furtados. Para confirmar qual padrão um contrato declara implementar, chame supportsInterface (ERC-165): 0x80ac58cd para ERC-721, 0xd9b67a26 para ERC-1155, 0x2a55205a para o padrão de royalties ERC-2981. Coleções antigas podem ser anteriores aos padrões: os CryptoPunks (2017) usam eventos personalizados, como PunkTransfer e PunkBought, invisíveis para um decodificador exclusivo de ERC-721.

O ERC-1155 reúne muitos tipos de tokens em um único contrato, cada um com um id e uma quantidade por detentor. Seus eventos TransferSingle (topic0 0xc3d58168…0f62) e TransferBatch (0x4a39dc06…f7fb) contêm um operador, a conta que realiza a transferência, portanto uma venda em marketplace mostra o marketplace como operador e o vendedor como from. Emissões e queimas usam o endereço zero. Eventos em lote contêm arrays de IDs e valores; um TransferBatch deve se tornar uma linha por ID, ou a maior parte do volume de um contrato com muitos lotes desaparecerá silenciosamente.

Vendas, royalties e fluxos de wash trading

Um evento Transfer não tem preço: proprietários movimentam NFTs entre suas próprias carteiras, emprestam-nos, distribuem-nos por airdrop e os vendem com pagamentos off-chain. Uma venda é uma inferência a partir de um pagamento na mesma transação e, idealmente, do evento de liquidação do marketplace. O Seaport, usado pela OpenSea e por outros, emite OrderFulfilled com uma oferta (o que o criador da ordem entrega) e uma contrapartida (o que o criador e os destinatários de taxas recebem): em um anúncio vendido por 10 ETH, a contrapartida paga 9,45 ETH ao vendedor, 0,05 ETH (0,5%) a um endereço de taxas e 0,5 ETH (5%) ao criador. Quando um vendedor aceita uma oferta de compra, o ofertante é o comprador, que oferece WETH. O preço por item de um pacote é uma alocação e deve ser identificado como tal. Os royalties ERC-2981 são informativos (a OpenSea, por exemplo, tornou as taxas de criador opcionais para novas coleções a partir de 31 de agosto de 2023), portanto meça os royalties efetivamente pagos, não a taxa anunciada.

NFTs podem disfarçar uma transferência de valor como uma venda: um agente de lavagem de dinheiro compra, com fundos ilícitos, um NFT de uma carteira que também controla, e os valores recebidos parecem renda de negociação. A etapa de pagamento transporta o valor: acompanhe o ETH ou a stablecoin pagos ao vendedor e trate a movimentação do NFT como contexto. Sinais de wash trading incluem ciclos fechados (A → B → A), um financiador comum do comprador e do vendedor, uma saída comum para os valores recebidos, uma posição combinada sem risco, autofinanciamento por meio de empréstimos instantâneos ou pagamentos na mesma transação e preços muito acima da faixa da coleção. O CryptoPunk 9998 é o caso famoso: em 28 de outubro de 2021, ele foi "vendido" por cerca de 124.457 ETH (aproximadamente US$ 532 milhões) quando, conforme explicaram os criadores da coleção, o comprador o comprou de si mesmo com dinheiro emprestado e devolvido na mesma transação. Um estudo revisado por pares (La Morgia et al., IEEE ICDCS 2023) constatou que o wash trading representava cerca de 85% do volume na LooksRare, que recompensava o volume negociado com tokens. Uma consulta por tokens recomprados por seu vendedor anterior produz pistas, não constatações; a confiança aumenta quando sinais independentes convergem (aula 6.5).

Foco no exame: os quatro canais em que o valor se movimenta em blockchains baseadas em contas e onde cada um é registrado; por que transferências internas precisam de um nó com capacidade de rastreamento e por que o cliente, a versão e o método são registrados; identificação de tokens pelo endereço do contrato, conversão com as casas decimais corretas e as armadilhas de tokens falsificados e envenenamento de endereços; convenções de emissão e queima e os tokens que fogem a elas (WETH, taxa sobre transferência, rebasing), com conciliação em relação a balanceOf e totalSupply; approve, transferFrom, permit EIP-2612 e divisões de drainers como inferência sobre papéis; leitura e conciliação de um rastro decodificado de drainer; campos adicionais no registro de etapas; congelamentos de stablecoins e os limites da visibilidade do emissor; tópicos ERC-721 versus ERC-20, ApprovalForAll, operador e lotes ERC-1155; o fato de que uma transferência não tem preço; acompanhamento da etapa de pagamento em fluxos de wash trading com NFTs.