Clusters de carteiras e financiamento

Fonte mestra EN · P07-L06 · 45 minutos estimados · needs_review

Objetivos de aprendizagem:

• Construir um grafo de financiamento a partir de transferências bem-sucedidas explicitamente fornecidas.
• Separar coortes de financiador comum de hipóteses de controle compartilhado.
• Calcular fluxos brutos e saldos finais condicionais sem contagem dupla.

Grafos de financiamento podem revelar relações que uma tabela de detentores omite, mas também podem criar falsas identidades convincentes. Um financiador comum pode ser um serviço de custódia, um faucet, uma conta de folha de pagamento ou um operador de lançamento. A habilidade prática é preservar arestas de transferência tratando interpretações de controle compartilhado como hipóteses com alternativas.

Definir nós e arestas precisamente

Um grafo de financiamento começa com uma transferência observada: endereço/conta de origem, destino, ativo, quantia, identificador do evento, resultado e contexto temporal. Uma seta deve significar algo específico, como “transferência bem-sucedida de cinco unidades de cotação”, não apenas “estas carteiras parecem conectadas”. Um grafo com linhas bonitas, mas significado de aresta não especificado, não é evidência reproduzível.

No escopo Solana, estruturas de transação distinguem chaves de conta, informação de signatários, instruções e metadados de resultado/saldo [S-STRUCTURE]. Lê-las apoia uma reconstrução operacional de transferência. O titular controlador de uma conta de token pode ser consultado separadamente [S-OWNERS]. Nem um indicador de signatário nem um campo de titular de conta fornece uma identidade de passaporte.

Distinga uma aresta direta de financiamento de uma rota com intermediários. Se F→A→B aparece, não é idêntico a F→B. A conta intermediária pode combinar fundos de origens não relacionadas ou agir para vários usuários. A menos que o modelo de rastreamento e os fluxos completos justifiquem isso, não descreva a quantia final como as mesmas moedas identificáveis de forma única.

Separar três tipos de relação

Uma relação de financiamento registra movimento de ativos. Uma relação operacional pode registrar autoridade comum de assinatura ou papel compartilhado de programa sustentado por dados explícitos. Uma relação de controle humano é uma afirmação muito mais forte. Mantenha estilos diferentes de aresta ou tabelas para cada uma. Nunca transforme as três em um rótulo genérico de “carteira vinculada”.

Financiamento compartilhado é útil para gerar hipóteses. Não basta para concluir controle comum. O mesmo serviço pode financiar muitos clientes independentes. Inversamente, endereços financiados independentemente ainda podem compartilhar um controlador. Ambas as direções mostram por que uma associação automatizada a cluster deve preservar sua regra e confiança em vez de alegar certeza.

Declare a regra de agrupamento antes de inspecionar a conclusão. Por exemplo: “agrupar endereços que recebem unidades de cotação diretamente da mesma origem na janela fornecida”. Essa regra cria uma coorte de financiamento. Não afirma um cluster de identidade humana. Renomeie o resultado de acordo para que um relatório posterior não herde acidentalmente um rótulo exagerado.

Testar hipóteses contra alternativas

Para cada relação inferida, liste uma alternativa e a evidência que a distinguiria. Se três carteiras recebem quantias semelhantes e negociam logo depois, atividade coordenada é uma explicação candidata. Clientes independentes sacando de um serviço compartilhado é outra. Um indexador também pode atribuir incorretamente um rótulo de origem. O analista deve perguntar qual observação realmente discrimina entre essas explicações.

Mais da mesma pista fraca nem sempre é uma pista mais forte. Dez transferências de um hub de custódia para dez clientes não se tornam prova de identidade porque o grafo é denso. Evidência diferente pode ser mais informativa: autoridade compartilhada explícita para uma conta específica, divulgação corroborada independentemente ou um mecanismo operacional verificado. Mesmo estas podem apoiar operações conjuntas sem identificar um indivíduo.

Momentos repetidos podem ser descritos sem interpretar intenção. Um grafo pode relatar que financiamento precedeu uma negociação de lançamento por um intervalo observado curto. “Eles conheciam o lançamento antecipadamente” é uma afirmação separada. Um pressuposto de latência, histórico ausente ou timestamp grosseiro pode mudar o intervalo aparente.

Delimitar cobertura do grafo e quantidades rastreadas

Todo grafo tem um escopo: rede, conjunto de ativos, janela de observação, contagem máxima de saltos, cobertura de provedor e exclusões. Um diagrama de três saltos sem histórico antes de seu primeiro nó mostra a primeira origem visível nessa análise, não necessariamente a origem final. Inclua caminhos de entrada não resolvidos no limite.

Saldos e volume de fluxo diferem. Somar todas as transferências de entrada pode contar duas vezes fundos que vão e voltam. Somar fluxos sobrepostos de cluster pode contar a mesma quantia várias vezes em múltiplos saltos. Diga se um total é fluxo bruto de entrada, fluxo líquido ou saldo ao fim da janela. Uma legenda útil de grafo nomeia tanto unidades de aresta quanto regras de agregação.

Rótulos de serviço também precisam de um estado. Se F é apenas “corretora declarada”, preserve essa incerteza. Use a evidência de transferência independentemente do rótulo, mas teste a interpretação com e sem classificação de serviço. Rótulos falsos de entidade podem contaminar muitas conclusões posteriores de uma vez.

O resultado é um relatório de relações honesto sobre o que foi visto e o que foi inferido. Um cluster é um instrumento de pesquisa. Não é um sinal de investimento, prova de conluio ou permissão para expor identidades privadas.

• Aresta direta: uma transferência fornecida entre nós especificados.
• Coorte de financiamento: endereços agrupados por uma regra explícita de financiamento.
• Hipótese de cluster: uma relação proposta, não uma descoberta de identidade.
• Nó de limite: nó com histórico relevante fora da cobertura disponível.
• Fluxo bruto: soma de transferências sem compensar devoluções.
• Fluxo líquido: entrada direcional menos saída para o ativo/janela especificados.

EXEMPLO ILLUSTRATIVE — FIX-P07-06. Todos os rótulos, quantias de cotação e tempos são fictícios. Somente estas transferências fornecidas são cobertas.

HUB tem um rótulo não corroborado de serviço de custódia. Nenhum registro de compartilhamento de signatários, identificação humana ou histórico anterior de HUB é fornecido. OUT é um nó de limite não resolvido.

OBSERVED: HUB financia os três endereços; W1 e W2 trocam uma unidade em cada direção; W3 transfere duas unidades para OUT.

INFERRED: W1/W2/W3 formam uma coorte de financiador direto comum sob a regra declarada. Isso não é controle humano comum.

UNKNOWN: A origem final de financiamento de HUB e os controladores humanos de W1, W2, W3 ou OUT.

INSUFFICIENT EVIDENCE: Financiamento igual mais transferências recíprocas não podem estabelecer um operador único, manipulação coordenada ou rede de insiders. Um rótulo de custódia tampouco prova uma relação de cliente.

Rotular uma origem comum de financiamento como o criador; presumir que transferências iguais implicam um controlador; colorir todas as arestas de hipótese como observadas; somar transferências brutas como saldos; e rastrear “origem final” além de histórico ausente.

Aplique a regra de financiamento direto por HUB. Calcule saída bruta de HUB e saldos de W1/W2/W3 ao fim da janela sob o pressuposto explícito de que cada um começa em zero e estas são as únicas transferências relevantes, excluindo taxas. Compare entrada bruta de W1 com seu saldo final. Escreva duas explicações alternativas para a coorte.

• Especificar unidade e evento por trás de cada aresta observada.
• Preservar rede, janela de cobertura e limite de saltos.
• Separar financiamento comum, papéis operacionais e identidade humana.
• Distinguir fluxos brutos/líquidos e saldos finais.
• Registrar explicações concorrentes e rótulos não verificados de origem.

Um grafo de financiamento é mais forte quando sua semântica de arestas, escopo e incertezas são explícitos. Financiamento compartilhado apoia uma coorte reproduzível, mas controle humano compartilhado exige evidência adicional.

Agrupe por uma regra divulgada. Mantenha hipóteses visíveis como hipóteses. Um caminho anterior ausente é um desconhecido, não prova de uma origem final.

Desenhar FIX-P07-06 como grafo direcionado de financiamento com quantias/tempos em arestas sólidas de transferência. Manter rótulo de serviço de HUB hachurado e OUT como limite não resolvido. Colocar uma chave separada tracejada de hipótese ao redor da coorte de financiador direto rotulada 'não é titularidade humana'. Incluir painéis laterais de entrada bruta versus saldo final.

Regras de entrega visual: azul-marinho escuro/preto, detalhes ciano/azul elétrico/violeta, unidades e incerteza explicitamente rotuladas. Use gráficos determinísticos ou SVG, não capturas de tela fabricadas. Em 390 px, empilhe anotações e forneça a tabela de dados como alternativa textual; verifique 768 px e desktop depois. Em árabe, localize rótulos e layout com RTL nativo, isolando endereços/hashes em LTR e mantendo a direção real das transferências e a cronologia. Use somente o logo oficial BlockAssay fornecido se identidade visual for adicionada. Nenhum recurso visual ou renderização mobile/RTL é alegado pronto.

Use WALLET_INTELLIGENCE somente quando rede exata, ativo e campos necessários forem compatíveis e sua procedência for visível. Esta é uma inspeção educacional somente de leitura, não uma operação ou lançamento de token. Use o conjunto de dados offline fornecido se acesso ou dados estiverem indisponíveis; informação ausente permanece desconhecida. Uma futura ação Abrir na BlockAssay precisa de roteamento de runtime validado e cobertura de fontes. Nenhum CTA executável de ativo é fornecido para identificadores ilustrativos. Participação na Academy e status comercial nunca mudam observações do Radar.

• Estruturas JSON do RPC Solana — Signatários de transação, instruções e metadados de saldo/resultado. Verificada em 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeração de contas de token por titular de conta; campo de titularidade não é identidade humana. Verificada em 2026-09-30.
• Solana getSignaturesForAddress — Assinaturas de endereço referenciado do mais recente para o mais antigo e parâmetros de paginação. Verificada em 2026-09-30.

As tabelas e os conjuntos de dados dos exercícios são material educacional original, salvo quando explicitamente designados HISTORICAL. Identificadores fictícios são deliberadamente inválidos como endereços de blockchain. Documentação apoia definições de mecanismos, não valores inventados dos exercícios. Inspeção de fontes é pesquisa editorial, não medição de blockchain ao vivo. Fontes podem mudar; revise novamente antes da publicação.

P07-L07; prossiga após concluir o exercício e revisar cada explicação do quiz.