Groupes de portefeuilles et financement

Source maître EN · P07-L06 · 45 minutes estimées · needs_review

Objectifs d’apprentissage :

• Construire un graphe de financement à partir de transferts réussis explicitement fournis.
• Distinguer les cohortes à financeur commun des hypothèses de contrôle partagé.
• Calculer les flux bruts et soldes finaux conditionnels sans double comptage.

Les graphes de financement peuvent révéler des relations qu’un tableau de détenteurs manque, mais aussi créer des identités fausses convaincantes. Un financeur commun pourrait être un service de garde, un robinet de distribution, un compte de paie ou un opérateur de lancement. La compétence pratique est de préserver les arêtes de transfert tout en traitant les interprétations de contrôle partagé comme des hypothèses avec alternatives.

Définir précisément les nœuds et arêtes

Un graphe de financement commence par un transfert observé : adresse/compte source, destination, actif, montant, identifiant d’événement, résultat et contexte temporel. Une flèche doit signifier quelque chose de précis, comme « transfert réussi de cinq unités de cotation », pas seulement « ces portefeuilles semblent liés ». Un graphe aux belles lignes mais sans sens précisé des arêtes n’est pas une preuve reproductible.

Dans le périmètre Solana, les structures de transaction distinguent clés de compte, informations de signataire, instructions et métadonnées de résultat/solde [S-STRUCTURE]. Les lire étaye une reconstruction opérationnelle des transferts. Le propriétaire contrôlant un compte de jetons peut être interrogé séparément [S-OWNERS]. Ni un indicateur de signataire ni un champ propriétaire de compte ne fournit une identité de passeport.

Distinguer une arête directe de financement d’un chemin avec intermédiaires. Si F→A→B apparaît, ce n’est pas identique à F→B. Le compte intermédiaire peut combiner des fonds d’origines sans rapport ou agir pour plusieurs utilisateurs. À moins que le modèle de traçage et les flux complets le justifient, ne pas décrire le montant final comme les mêmes pièces identifiables de façon unique.

Distinguer trois types de relations

Une relation de financement consigne un mouvement d’actif. Une relation opérationnelle peut consigner une autorité de signature commune ou un rôle de programme partagé étayé par des données explicites. Une relation de contrôle humain est une affirmation beaucoup plus forte. Garder des styles d’arêtes ou tableaux distincts pour chacune. Ne jamais transformer les trois en un libellé générique unique de « portefeuille lié ».

Le financement partagé est utile pour générer des hypothèses. Il ne suffit pas pour conclure à un contrôle commun. Le même service peut financer de nombreux clients indépendants. Inversement, des adresses financées indépendamment peuvent partager un contrôleur. Ces deux directions montrent pourquoi l’appartenance automatisée à un groupe doit préserver sa règle et sa confiance au lieu de revendiquer une certitude.

Déclarer la règle de regroupement avant d’inspecter la conclusion. Par exemple : « regrouper les adresses recevant directement des unités de cotation de la même source dans la fenêtre fournie ». Cette règle crée une cohorte de financement. Elle n’affirme pas un groupe d’identité humaine. Renommer le résultat en conséquence afin qu’un rapport en aval n’hérite pas accidentellement d’un libellé excessif.

Tester les hypothèses contre les alternatives

Pour chaque relation déduite, lister une alternative et les preuves qui les distingueraient. Si trois portefeuilles reçoivent des montants similaires et négocient peu après, une activité coordonnée est une explication candidate. Des clients indépendants retirant depuis un service partagé en sont une autre. Un indexeur pourrait aussi attribuer incorrectement un libellé de source. L’analyste doit demander quelle observation départage réellement ces explications.

Davantage du même indice faible n’est pas toujours un indice plus fort. Dix transferts d’un centre de garde à dix clients ne deviennent pas une preuve d’identité parce que le graphe est dense. Des preuves différentes peuvent être plus informatives : autorité partagée explicite pour un compte particulier, divulgation corroborée indépendamment ou mécanisme opérationnel vérifié. Même celles-ci peuvent étayer des opérations conjointes sans identifier un individu unique.

Les répétitions temporelles peuvent être décrites sans interpréter l’intention. Un graphe peut rapporter que le financement a précédé une transaction de lancement d’un court intervalle observé. « Ils connaissaient le lancement à l’avance » est une affirmation distincte. Une hypothèse de latence, un historique manquant ou un horodatage grossier peut changer l’intervalle apparent.

Borner la couverture du graphe et les quantités tracées

Chaque graphe a un périmètre : réseau, ensemble d’actifs, fenêtre d’observation, nombre maximal de sauts, couverture du fournisseur et exclusions. Un schéma à trois sauts sans historique avant son premier nœud montre la première source visible dans cette analyse, pas nécessairement l’origine ultime. Inclure les chemins entrants non résolus à la limite.

Soldes et volumes de passage diffèrent. Additionner tous les transferts entrants peut compter deux fois des fonds allant et revenant. Additionner les flux de groupes qui se chevauchent peut compter le même montant plusieurs fois sur plusieurs sauts. Dire si un total est un flux entrant brut, un flux net ou un solde de fin de fenêtre. Une légende de graphe utile nomme à la fois les unités d’arête et les règles d’agrégation.

Les libellés de services exigent aussi un statut. Si F est seulement « plateforme d’échange déclarée », préserver cette incertitude. Utiliser les preuves de transfert indépendamment du libellé, mais tester l’interprétation avec et sans classification de service. Les faux libellés d’entité peuvent contaminer de nombreuses conclusions en aval à la fois.

Le résultat est un rapport de relations honnête sur ce qui a été vu et ce qui a été déduit. Un groupe est un dispositif de recherche. Ce n’est pas un signal d’investissement, une preuve de collusion ou une autorisation de révéler des identités privées.

• Arête directe : un transfert fourni entre des nœuds précisés.
• Cohorte de financement : adresses regroupées par une règle explicite de financement.
• Hypothèse de groupe : relation proposée, pas constat d’identité.
• Nœud de limite : nœud dont l’historique pertinent dépasse la couverture disponible.
• Flux brut : somme des transferts sans compensation des retours.
• Flux net : entrée directionnelle moins sortie pour l’actif/la fenêtre précisés.

ILLUSTRATIVE EXEMPLE — FIX-P07-06. Tous les libellés, montants de cotation et temps sont fictifs. Seuls ces transferts fournis sont couverts.

HUB a un libellé de service de garde non corroboré. Aucun enregistrement de partage de signataires, identification humaine ou historique antérieur de HUB n’est fourni. OUT est un nœud de limite non résolu.

OBSERVED: HUB finance les trois adresses ; W1 et W2 échangent une unité dans chaque direction ; W3 transfère deux unités à OUT.

INFERRED: W1/W2/W3 forment une cohorte à financeur direct commun selon la règle déclarée. Ce n’est pas un contrôle humain commun.

UNKNOWN: Origine ultime du financement de HUB et contrôleurs humains de W1, W2, W3 ou OUT.

INSUFFICIENT EVIDENCE: Un financement égal et des transferts réciproques ne peuvent établir un opérateur unique, une manipulation coordonnée ou un réseau d’initiés. Un libellé de garde ne prouve pas non plus une relation client.

Étiqueter une source de financement commune comme créateur ; supposer que des transferts égaux impliquent un contrôleur unique ; colorer toutes les arêtes d’hypothèse comme observées ; additionner les transferts bruts comme soldes ; et tracer l’« origine ultime » au-delà de l’historique manquant.

Appliquer la règle de financement direct par HUB. Calculer le flux sortant brut de HUB et les soldes de fin de fenêtre de W1/W2/W3 selon l’hypothèse explicite que chacun commence à zéro et que ce sont les seuls transferts pertinents, hors frais. Comparer le flux entrant brut de W1 à son solde final. Écrire deux explications alternatives de la cohorte.

• Préciser l’unité et l’événement derrière chaque arête observée.
• Préserver réseau, fenêtre de couverture et limite de sauts.
• Distinguer financement commun, rôles opérationnels et identité humaine.
• Distinguer flux bruts/nets et soldes finaux.
• Consigner les explications concurrentes et libellés de sources non vérifiés.

Un graphe de financement est le plus solide lorsque le sens de ses arêtes, son périmètre et ses incertitudes sont explicites. Le financement partagé étaye une cohorte reproductible, mais un contrôle humain partagé exige des preuves supplémentaires.

Regrouper selon une règle divulguée. Garder les hypothèses visibles comme hypothèses. Un chemin amont manquant est une inconnue, pas une preuve d’origine ultime.

Dessiner FIX-P07-06 comme graphe dirigé de financement avec montants/temps sur des arêtes de transfert pleines. Garder le libellé de service HUB hachuré et OUT comme limite non résolue. Placer une accolade distincte en pointillés d’hypothèse autour de la cohorte à financeur direct, étiquetée « pas une attribution de propriété à des personnes ». Inclure des encadrés de flux entrant brut contre solde final.

Règles de livraison visuelle : bleu marine foncé/noir, accents cyan/bleu électrique/violet, unités et incertitude explicitement étiquetées. Utiliser des graphiques déterministes ou du SVG, pas des captures fabriquées. À 390 px, empiler les annotations et fournir le tableau de données comme alternative textuelle ; vérifier 768 px et l’ordinateur plus tard. En arabe, localiser les libellés et la mise en page en RTL natif, tout en isolant les adresses/hachages en LTR et en conservant le sens réel des transferts et la chronologie. Utiliser uniquement le logo officiel BlockAssay fourni si une identité de marque est ajoutée. Aucun actif visuel ni rendu mobile/RTL n’est revendiqué prêt.

Utiliser WALLET_INTELLIGENCE uniquement lorsque le réseau exact, l’actif et les champs requis sont pris en charge et que leur provenance est visible. C’est une inspection pédagogique en lecture seule, pas une transaction ni un lancement de jeton. Utiliser le jeu hors ligne fourni si l’accès ou les données sont indisponibles ; les informations manquantes restent inconnues. Une future action Ouvrir dans BlockAssay exige un routage d’exécution et une couverture de sources validés. Aucun appel à l’action d’actif exécutable n’est fourni pour les identifiants illustratifs. La participation à Academy et le statut commercial ne changent jamais les observations Radar.

• Structures JSON RPC Solana — Signataires, instructions et métadonnées de solde/résultat des transactions. Vérifié le 2026-09-30.
• Solana getTokenAccountsByOwner — Énumération des comptes de jetons par propriétaire de compte ; le champ de propriété n’est pas une identité humaine. Vérifié le 2026-09-30.
• Solana getSignaturesForAddress — Signatures d’adresses référencées du plus récent au plus ancien et paramètres de pagination. Vérifié le 2026-09-30.

Les tableaux et jeux d’exercice sont du matériel pédagogique original sauf désignation explicite HISTORICAL. Les identifiants fictifs sont délibérément invalides comme adresses de blockchain. La documentation étaye les définitions des mécanismes, pas les valeurs inventées des exercices. L’inspection des sources est une recherche éditoriale, pas une mesure de chaîne en direct. Les sources peuvent changer ; les réexaminer avant publication.

P07-L07 ; poursuivre après avoir terminé l’exercice et examiné chaque explication du quiz.