
No cerne do bitcoin está um livro-razão aberto, então, com a habilidade adequada, qualquer transferência pode ser rastreada de endereço para endereço. Uma indústria inteira cresceu a partir disso: traders rastreiam baleias e entradas em exchanges, especialistas em forense de blockchain ajudam a recuperar fundos roubados, e a conformidade filtra moedas "sujas".
Neste guia, iremos passo a passo através de como analisar transações manualmente, como colocar o trabalho em uma esteira com a ajuda de ferramentas e automação, e também por que mesmo o rastreamento mais avançado dá uma probabilidade em vez de uma resposta de cem por cento.
Deixaremos definições básicas e métricas de mercado de fora do escopo — há um material separado para eles em formato de cartão.
Parte 1. Analisando transações manualmente
Passo 1. Encontrando uma transação pelo TXID
Cada transferência na blockchain tem um identificador único — o TXID, o hash da transação. Este é uma longa string, geralmente de 64 caracteres, que a rede obtém executando todos os dados da transferência — entradas, saídas, quantias e assinaturas — através do algoritmo SHA-256.
É praticamente impossível forjar tal hash: a menor edição dos dados gera uma string completamente diferente, então dois TXIDs idênticos não existem. Em essência, é um "número de recibo" pelo qual qualquer nó na rede pode encontrar e verificar a operação.
A maneira de obter o hash depende do que você já tem:
- se a transferência já foi feita — ela pode ser aberta no histórico de uma carteira ou exchange. Ao lado da operação, geralmente há um link como "Ver no explorador": ele leva à página da transação, onde o identificador é mostrado na íntegra;
- se você só tem o endereço do remetente ou do destinatário — ele é colado na barra de pesquisa de qualquer explorador de blockchain. O histórico do endereço será aberto com todas as transferências; a transação necessária pode ser identificada pelo valor e data, e seu hash encontrado na própria página da transação.
Passo 2. Entendendo a estrutura de uma transação: entradas, saídas e troco
Diferente de uma conta bancária, o bitcoin não armazena o saldo como um único número. A rede funciona no modelo UTXO (unspent transaction output): os fundos existem como "notas" separadas de diferentes denominações, enquanto a carteira armazena apenas as chaves para elas. O saldo disponível é a soma de todas essas saídas controladas pelo proprietário.
Uma "nota" não pode ser gasta parcialmente. Durante um pagamento, tal saída entra na transação na íntegra, e em troca a rede cria duas novas: uma para o destinatário, a segunda como troco de volta para o remetente em um novo endereço.
Vamos tomar um exemplo. Alice tem uma saída de 5 BTC, e ela transfere 0,01 BTC para Bob. No blockchain aparecem uma entrada de 5 BTC, um pagamento de 0,01 BTC e troco de ~4,99 BTC (menos a taxa).
Qualquer observador pode ver toda a operação através de um explorador — um pagamento "redondo" é fácil de distinguir de uma mudança "fracionária". A determinação do endereço de mudança na forense de blockchain é construída com base nessa característica.
Passo 3. Verificando confirmações e o mempool
Uma transação enviada não chega à blockchain instantaneamente. Primeiro, a transferência acaba no mempool — uma fila comum de operações aguardando inclusão em um bloco. Neste estágio, atrasos são possíveis: os mineradores geralmente priorizam operações com uma taxa mais alta, então, com uma taxa muito baixa, uma transferência pode permanecer na fila por muito tempo.
Assim que a operação chega a um bloco, ela recebe sua primeira confirmação. Depois que o registro é incluído em um bloco, ele recebe sua primeira confirmação. Com cada confirmação subsequente, o nível de confiabilidade cresce, e a probabilidade de cancelamento se torna cada vez menor. Para quantias pequenas, uma ou duas confirmações geralmente são suficientes, enquanto para pagamentos grandes é costume esperar por seis.
É conveniente acompanhar em tempo real pelo hash: o explorador mostrará se a transferência está presa na fila, em qual bloco ela acabou, quantas confirmações ela ganhou e qual taxa o remetente pagou. Se a operação estiver presa por muito tempo, a mesma página sugerirá o motivo — na maioria das vezes, uma taxa subestimada.
Passo 4. Rastreando o caminho de uma moeda
Cada entrada de uma nova operação refere-se a uma saída específica de uma das anteriores — pelo seu hash, e pode ter várias entradas e saídas ao mesmo tempo. Portanto, as transferências não formam uma única cadeia, mas uma rede ramificada: as moedas nela convergem e divergem entre endereços.
Ao longo dessa rede, o movimento de fundos pode ser rastreado em ambas as direções — para frente, em direção a novos endereços, e para trás, até a transação coinbase na qual apareceram pela primeira vez como recompensa por um bloco minerado.
Na prática, um analista segue os endereços de saída e observa para onde os fundos foram a seguir. Então, eles repetem o mesmo com os novos endereços — passo a passo, até que uma cadeia completa se forme.
É assim que rotas características emergem na blockchain: uma transferência para uma exchange, a divisão de uma grande quantia em partes, ou a retirada de fundos roubados através de várias carteiras intermediárias.
Exemplo: em 2025, o endereço de um investidor inicial mostrou atividade pela primeira vez após 13 anos de inatividade, transferindo 909 BTC (cerca de $85 milhões) para uma nova carteira. Essas moedas foram recebidas de volta em 2012–2013, quando o preço do bitcoin não excedia alguns dólares.
Tal transferência é visível em qualquer explorador: basta abrir o endereço, seguir as cadeias de saída e ver para onde os fundos se moveram a seguir.
Parte 2. Colocando a análise em um fluxo contínuo
A análise manual é boa quando há uma ou duas transações. Mas o livro-razão é reabastecido a cada segundo, e milhares de transferências não podem ser cobertas a olho nu.
Aqui a automação vem ao resgate: os programas solicitam dados da rede, calculam métricas e enviam uma notificação no momento certo. Vamos olhar para seus três níveis — acesso a dados, análises e monitoramento.
Passo 5. Conectando-se aos dados via API
O primeiro nível é o acesso programático à blockchain através das APIs de nós e exploradores. Esta é uma interface pela qual um script solicita as mesmas informações que poderíamos ver anteriormente na página de transferência (mas sem envolvimento humano e em qualquer volume).
O serviço mempool.space tem duas opções para escolher. A API REST responde a solicitações únicas: status da transação, saldo do endereço, estado do mempool. A API WebSocket mantém uma conexão constante e envia atualizações por conta própria — você pode se inscrever em um endereço e receber um sinal toda vez que uma nova transferência passar por ele.
Para verificações em massa, Blockchair e Bitquery são adequados: eles retornam dados para muitos endereços de uma vez e suportam webhooks.
Passo 6. Automatizando análises
O segundo nível são plataformas que permitem que você escreva uma consulta uma vez e receba um painel pronto em vez de um resultado único.
No Dune, os dados da blockchain são consultados na linguagem SQL e exibidos em gráficos; um relatório sobre fluxos de troca, atividade de baleias ou principais detentores se atualiza sozinho, sem uma consulta repetida.
Flipside é organizado de forma semelhante — também possui um SDK Python gratuito através do qual os dados podem ser puxados diretamente para scripts personalizados.
A principal diferença em relação ao método manual é simples: a consulta é escrita uma vez, mas funciona constantemente. Anteriormente, um analista revisava o gráfico diariamente — agora existem painéis que se atualizam sozinhos.
Passo 7. Configurando monitoramento e alertas
O terceiro nível são as notificações em vez de atualizar a página manualmente. Uma combinação de "API mais bot" monitora os endereços necessários e envia uma notificação assim que os fundos chegam ou saem. É assim que funcionam tanto os alertas públicos sobre grandes negociações de baleias quanto os alertas privados, por exemplo, sobre a retirada de moedas de uma carteira específica.
Um conjunto básico pode ser configurado mesmo sem programação: plataformas como Arkham oferecem alertas prontos sobre transferências e atividades de baleias que chegam por e-mail ou para o aplicativo. Para aqueles que precisam de sua própria lógica de manipulação de eventos, webhooks são adequados — eles enviam automaticamente uma notificação para o servidor quando um evento especificado ocorre.
Parte 3. Rastreio e seus limites
Passo 8. Como funciona a análise forense de blockchain
O auge da automação é o rastreamento de moedas roubadas e a investigação de transações. Motores forenses repetem a lógica da análise manual, mas a aplicam na escala de toda a rede.
No coração dessa tecnologia está o agrupamento de endereços por heurísticas, ou seja, regras de suposição; duas delas são especialmente importantes:
- entrada comum: se vários UTXOs são gastos em uma única transação, eles são com alta probabilidade controlados por um único proprietário;
- determinação de mudança de endereço: pela funcionalidade da Etapa 2 — um pagamento redondo versus mudança fracionária — o mecanismo determina qual dos resultados retornados ao remetente.
Além da agrupamento, é adicionada a reconhecimento de esquemas típicos de lavagem. Isso é, por exemplo, a divisão de somas ou "peeling" — quando pequenas porções são retiradas de uma grande carteira repetidamente.
Em seguida, vem a avaliação de risco e atribuição: ligando agrupamentos a trocas reais, serviços ou indivíduos. Tanto plataformas comerciais (Chainalysis, TRM, Elliptic) quanto motores abertos (GraphSense, BlockSci) fazem isso.
Etapa 9. A automação pode ser confiável
A análise automática tem uma limitação fundamental. O agrupamento fornece uma probabilidade, não um fato. Heurísticas cometem erros: por exemplo, a tecnologia CoinJoin combina deliberadamente os UTXOs de diferentes usuários em uma transação, o que faz com que a regra de entrada comum falhe.
O risco de vazamento de dados também pode ser reduzido manualmente. A função de controle de moedas em carteiras (por exemplo, Sparrow ou Trezor Suite) permite que você escolha qual UTXO gastar: escolha uma saída que corresponda ao valor do pagamento e não misture moedas de diferentes fontes em uma única transação. Isso reduz a mudança e impede que a heurística de entrada comum seja acionada — as próprias pistas nas quais o agrupamento é baseado.
O Bitcoin não fornece anonimato, mas pseudonimato — uma propriedade mais fraca que a análise persistente muitas vezes "rompe", mas nem sempre: o resultado continua sendo uma estimativa, embora bem fundamentada. Como a Chainalysis enfatiza, as heurísticas de atribuição fornecem um resultado probabilístico em vez de certeza, portanto, uma avaliação de risco é apenas uma base para a decisão do analista, não um veredicto.
Portanto, uma conclusão prática. Vale a pena distinguir o agrupamento automático de endereços da atribuição verificada por humanos: o primeiro é uma hipótese, o segundo é uma conclusão. O resultado de uma avaliação de risco é uma razão para examinar mais de perto um endereço, não uma sentença sobre seu proprietário.
***
O livro-razão aberto torna cada transferência de bitcoin rastreável — toda análise on-chain é construída sobre isso. Para o trabalho manual, o básico é suficiente: saber o que é um TXID, entender o modelo UTXO e a mecânica da mudança, ler entradas, saídas e confirmações em um explorador. Isso é suficiente para percorrer cadeias de transações e ver onde os fundos se moveram.
A automação na forma de APIs, painéis SQL e bots não elimina a necessidade desses básicos — ela simplesmente escala o trabalho: o que um analista faz manualmente com uma transação, as ferramentas repetem para toda a rede.
No topo está a análise forense com agrupamento e avaliação de risco. No entanto, ela se baseia em heurísticas probabilísticas e, portanto, fornece hipóteses em vez de provas.
É lógico dominar o tópico de baixo para cima: primeiro o explorador, depois APIs e painéis, e só então ferramentas de análise on-chain especializadas. Ao mesmo tempo, quanto mais profundo o rastreamento, mais importante é distinguir o provável do comprovado.
Fonte: ForkLog

