Cluster di wallet e finanziamento

Master sorgente EN · P07-L06 · 45 minuti stimati · needs_review

Obiettivi di apprendimento:

• Costruire un grafo di finanziamento da trasferimenti riusciti esplicitamente forniti.
• Separare coorti con finanziatore comune da ipotesi di controllo condiviso.
• Calcolare flussi lordi e saldi finali condizionali senza doppio conteggio.

I grafi di finanziamento possono rivelare relazioni che una tabella dei detentori omette, ma possono anche creare false identità convincenti. Un finanziatore comune potrebbe essere un servizio di custodia, un faucet, un account per stipendi o un operatore di lancio. La competenza pratica è preservare gli archi dei trasferimenti trattando interpretazioni di controllo condiviso come ipotesi con alternative.

Definire precisamente nodi e archi

Un grafo di finanziamento inizia con un trasferimento osservato: indirizzo/account sorgente, destinazione, asset, importo, identificatore dell’evento, risultato e contesto temporale. Una freccia dovrebbe significare qualcosa di specifico, come «trasferimento riuscito di cinque unità di quotazione», non soltanto «questi wallet sembrano collegati». Un grafo con belle linee ma significato degli archi non specificato non è prova riproducibile.

Nell’ambito Solana, le strutture delle transazioni distinguono chiavi degli account, informazioni sui firmatari, istruzioni e metadati di risultati/saldi [S-STRUCTURE]. Leggerle sostiene una ricostruzione operativa del trasferimento. Il proprietario che controlla un account token può essere interrogato separatamente [S-OWNERS]. Né un flag di firmatario né un campo proprietario dell’account fornisce un’identità da passaporto.

Distinguere un arco diretto di finanziamento da un percorso con intermediari. Se appare F→A→B, non è identico a F→B. L’account intermedio può combinare fondi di origini non correlate o agire per più utenti. Salvo giustificazione del modello di tracciamento e dei flussi completi, non descrivere l’importo finale come le stesse monete identificabili univocamente.

Separare tre tipi di relazione

Una relazione di finanziamento registra movimento di asset. Una relazione operativa può registrare autorità comune di firma o un ruolo condiviso di programma sostenuto da dati espliciti. Una relazione di controllo umano è un’affermazione molto più forte. Tenere stili di arco o tabelle diversi per ciascuna. Non trasformarle mai tutte in un’etichetta generica di «wallet collegato».

Il finanziamento condiviso è utile per generare ipotesi. Non basta per concludere controllo comune. Lo stesso servizio può finanziare molti clienti indipendenti. Viceversa, indirizzi finanziati indipendentemente possono comunque condividere un controllore. Entrambe le direzioni mostrano perché l’appartenenza automatizzata a un cluster dovrebbe preservare regola e fiducia anziché dichiarare certezza.

Dichiarare la regola del clustering prima di esaminare la conclusione. Per esempio: «raggruppare indirizzi che ricevono unità di quotazione direttamente dalla stessa sorgente nella finestra fornita». Quella regola crea una coorte di finanziamento. Non afferma un cluster d’identità umana. Rinominare di conseguenza il risultato perché un rapporto successivo non erediti accidentalmente un’etichetta esagerata.

Verificare ipotesi rispetto ad alternative

Per ogni relazione inferita, elencare un’alternativa e le prove che la distinguerebbero. Se tre wallet ricevono importi simili e negoziano poco dopo, l’attività coordinata è una spiegazione candidata. Clienti indipendenti che prelevano da un servizio condiviso sono un’altra. Un indicizzatore potrebbe anche assegnare erroneamente un’etichetta alla sorgente. L’analista dovrebbe chiedere quale osservazione distingua effettivamente queste spiegazioni.

Più indizi deboli uguali non sono sempre un indizio più forte. Dieci trasferimenti da un hub di custodia a dieci clienti non diventano prova d’identità perché il grafo è denso. Prove diverse possono essere più informative: autorità condivisa esplicita per un account particolare, dichiarazione riscontrata indipendentemente o meccanismo operativo verificato. Anche queste possono sostenere operazioni congiunte senza identificare un individuo.

Tempismi ripetuti possono essere descritti senza interpretare intenzioni. Un grafo può riportare che il finanziamento precedeva un’operazione di lancio di un breve intervallo osservato. «Conoscevano il lancio in anticipo» è un’affermazione separata. Un’ipotesi di latenza, storia mancante o timestamp grossolano può cambiare l’intervallo apparente.

Delimitare copertura del grafo e quantità tracciate

Ogni grafo ha un ambito: rete, insieme degli asset, finestra di osservazione, numero massimo di passaggi, copertura del fornitore ed esclusioni. Un diagramma a tre passaggi senza storia prima del primo nodo mostra la prima sorgente visibile in quell’analisi, non necessariamente l’origine ultima. Includere percorsi in ingresso irrisolti al limite.

Saldi e quantità transitate differiscono. Sommare tutti i trasferimenti in ingresso può contare due volte fondi che vanno avanti e indietro. Sommare flussi sovrapposti del cluster può contare lo stesso importo più volte su più passaggi. Dire se un totale è flusso lordo in ingresso, flusso netto o saldo di fine finestra. Una didascalia utile nomina sia unità degli archi sia regole di aggregazione.

Anche le etichette dei servizi richiedono uno stato. Se F è soltanto «exchange dichiarato», preservare quell’incertezza. Usare le prove dei trasferimenti indipendentemente dall’etichetta, ma verificare l’interpretazione con e senza classificazione del servizio. Etichette false di entità possono contaminare contemporaneamente molte conclusioni successive.

Il risultato è un rapporto di relazioni onesto su ciò che è stato visto e ciò che è stato inferito. Un cluster è uno strumento di ricerca. Non è un segnale di investimento, prova di collusione o permesso di esporre identità private.

• Arco diretto: un trasferimento fornito tra nodi specificati.
• Coorte di finanziamento: indirizzi raggruppati con una regola esplicita di finanziamento.
• Ipotesi di cluster: relazione proposta, non accertamento d’identità.
• Nodo di confine: nodo con storia rilevante fuori dalla copertura disponibile.
• Flusso lordo: somma dei trasferimenti senza compensare i ritorni.
• Flusso netto: afflusso direzionale meno deflusso per asset/finestra specificati.

ESEMPIO ILLUSTRATIVE — FIX-P07-06. Tutte le etichette, gli importi di quotazione e i tempi sono fittizi. Sono coperti soltanto questi trasferimenti forniti.

HUB ha un’etichetta di servizio di custodia senza riscontro. Non sono forniti record di firmatari condivisi, identificazione umana o storia precedente di HUB. OUT è un nodo di confine irrisolto.

OBSERVED: HUB finanzia tutti e tre gli indirizzi; W1 e W2 scambiano un’unità in ogni direzione; W3 trasferisce due unità a OUT.

INFERRED: W1/W2/W3 formano una coorte con finanziatore diretto comune secondo la regola dichiarata. Questo non è controllo umano comune.

UNKNOWN: L’origine ultima del finanziamento di HUB e i controllori umani di W1, W2, W3 o OUT.

INSUFFICIENT EVIDENCE: Finanziamento uguale più trasferimenti reciproci non possono stabilire un singolo operatore, manipolazione coordinata o rete di insider. Nemmeno un’etichetta di custodia dimostra una relazione di clientela.

Etichettare una sorgente comune di finanziamento come creatore; presumere che trasferimenti uguali implichino un controllore; colorare tutti gli archi ipotetici come osservati; sommare trasferimenti lordi come saldi; e tracciare «l’origine ultima» oltre la storia mancante.

Applicare la regola del finanziamento diretto da HUB. Calcolare il deflusso lordo di HUB e i saldi di fine finestra di W1/W2/W3 con l’ipotesi esplicita che ciascuno inizi a zero e questi siano gli unici trasferimenti rilevanti, escluse commissioni. Confrontare l’afflusso lordo di W1 con il saldo finale. Scrivere due spiegazioni alternative della coorte.

• Specificare unità ed evento dietro ogni arco osservato.
• Preservare rete, finestra di copertura e limite dei passaggi.
• Separare finanziamento comune, ruoli operativi e identità umana.
• Distinguere flussi lordi/netti e saldi finali.
• Registrare spiegazioni concorrenti ed etichette di fonte non verificate.

Un grafo di finanziamento è più solido quando semantica degli archi, ambito e incertezze sono espliciti. Il finanziamento condiviso sostiene una coorte riproducibile, ma il controllo umano condiviso richiede prove aggiuntive.

Creare cluster con una regola dichiarata. Tenere le ipotesi visibili come ipotesi. Un percorso a monte mancante è un’incognita, non prova di un’origine ultima.

Disegnare FIX-P07-06 come grafo diretto di finanziamento con importi/tempi su archi di trasferimento continui. Tenere tratteggiata l’etichetta del servizio HUB e OUT come confine irrisolto. Posizionare una parentesi ipotetica tratteggiata separata attorno alla coorte con finanziatore diretto etichettata «non proprietà umana». Includere riquadri laterali di afflusso lordo rispetto a saldo finale.

Regole di consegna delle visualizzazioni: blu navy scuro/nero, accenti ciano/blu elettrico/viola, unità e incertezza etichettate esplicitamente. Usare grafici deterministici o SVG, non schermate inventate. A 390 px impilare annotazioni e fornire la tabella dei dati come alternativa testuale; verificare 768 px e desktop in seguito. In arabo localizzare etichette e disposizione con RTL nativo, isolando indirizzi/hash in LTR e mantenendo la direzione reale dei trasferimenti e la cronologia. Usare soltanto il logo ufficiale BlockAssay fornito se viene aggiunto il marchio. Nessuna risorsa visiva o rendering mobile/RTL è dichiarato pronto.

Usare WALLET_INTELLIGENCE soltanto quando rete esatta, asset e campi necessari sono supportati e la loro provenienza è visibile. È un esame educativo in sola lettura, non un’operazione di trading o un lancio di token. Usare il dataset offline fornito se accesso o dati non sono disponibili; le informazioni mancanti restano sconosciute. Una futura azione Apri in BlockAssay richiede instradamento runtime e copertura delle fonti convalidati. Non è fornita alcuna CTA di asset eseguibile per identificatori illustrativi. La partecipazione all’Academy e lo stato commerciale non cambiano mai le osservazioni di Radar.

• Strutture JSON RPC Solana — Firmatari delle transazioni, istruzioni e metadati di saldi/risultati. Verificato 2026-09-30.
• Solana getTokenAccountsByOwner — Enumerazione degli account token per proprietario dell’account; il campo di proprietà non è identità umana. Verificato 2026-09-30.
• Solana getSignaturesForAddress — Firme degli indirizzi referenziati dalla più recente e parametri di paginazione. Verificato 2026-09-30.

Le tabelle e i materiali degli esercizi sono contenuti educativi originali salvo designazione esplicita HISTORICAL. Gli identificatori fittizi sono deliberatamente invalidi come indirizzi blockchain. La documentazione sostiene definizioni dei meccanismi, non i valori inventati degli esercizi. L’esame delle fonti è ricerca editoriale, non una misurazione della blockchain dal vivo. Le fonti possono cambiare; riesaminarle prima della pubblicazione.

P07-L07; proseguire dopo aver completato l’esercizio e rivisto ogni spiegazione del quiz.