Concentration des détenteurs

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

Objectifs d’apprentissage :

• Calculer la concentration brute et ajustée avec des dénominateurs explicites.
• Agréger les comptes selon une adresse propriétaire vérifiée sans déduire d’identité humaine.
• Expliquer les exclusions opérationnelles et la sensibilité aux libellés incertains de garde.

« Les principaux détenteurs possèdent 70% » semble précis mais reste incomplet sans expliquer qui ou quoi a été compté, quel dénominateur a été utilisé et quels comptes ont été exclus. Un coffre de pool, un compte de garde de plateforme d’échange et plusieurs comptes contrôlés par une adresse peuvent déformer un graphique simpliste. La compétence consiste à calculer des mesures transparentes de concentration sans affirmer que les comptes de jetons équivalent à des personnes indépendantes.

Décider de la mesure avant de la calculer

Commencer par une identité d’actif et un périmètre d’observation. Le dénominateur d’offre totale, les soldes et les preuves de rôle de compte doivent décrire le même réseau/mint et un instantané compatible. Combiner une offre actuelle avec un tableau de soldes ancien crée une discordance non étiquetée. Si l’alignement exact est indisponible, indiquer l’approximation et ne pas prétendre que le pourcentage est une mesure contemporaine exacte.

La méthode RPC des plus grands comptes de jetons de Solana renvoie jusqu’à 20 comptes de jetons, pas une liste complète de détenteurs humains [S-LARGEST]. Le modèle de compte Solana permet plusieurs comptes de jetons pour le même mint sous un propriétaire de compte [S-TOKENS]. Ces faits motivent deux niveaux d’agrégation distincts : soldes de comptes et contrôle au niveau d’adresse. Aucun de ces niveaux ne prouve à lui seul la propriété bénéficiaire ultime.

Utiliser la liste des plus grands comptes pour identifier des candidats à inspecter, pas pour inventer une distribution complète. Un jeu limité aux vingt premiers peut étayer certains calculs partiels de concentration mais pas un histogramme complet de la longue traîne. Un champ propriétaire non résolu doit le rester. Ne pas fusionner des adresses simplement parce qu’elles ont été financées par le même intermédiaire.

Calculer plusieurs vues et étiqueter chacune

Une vue brute utilise tous les soldes fournis et l’offre totale fournie. Une vue agrégée par adresse combine les comptes avec la même adresse de contrôle vérifiée. Une vue ajustée exclut les soldes opérationnels identifiés dans un but analytique déclaré. Chaque vue répond à une question différente ; aucune ne remplace automatiquement les autres.

Considérons un coffre de pool détenant 300,000 sur 1,000,000 unités. Il occupe 30% de la distribution brute des comptes. Si le coffre est vérifié comme garde de pool, dire « une baleine possède personnellement 30% » n’est pas étayé. Pourtant, le retirer d’un graphique ne rend pas ses actifs sans pertinence : les droits LP et contrôles de retrait du pool affectent encore la capacité de marché.

Un libellé de plateforme d’échange pose un autre problème. Une adresse de garde peut représenter plusieurs utilisateurs, mais un libellé de fournisseur ne révèle pas la distribution exacte des propriétaires bénéficiaires. Si le rôle n’est que déclaré, montrer le résultat brut et un résultat facultatif de sensibilité plutôt que l’exclure silencieusement. Un solde exclu est un ajustement méthodologique, pas une preuve que son exposition économique a disparu.

Les dénominateurs peuvent changer la conclusion apparente

Dans le jeu, deux comptes contrôlés par l’adresse OWNER-A détiennent 180,000 et 120,000. Leur solde combiné est 300,000. Par rapport à l’offre totale, cela représente 30%. Exclure le pool vérifié de 300,000 unités laisse un dénominateur de 700,000 ; OWNER-A représente alors 42.8571% des soldes ajustés hors pool. Le numérateur n’a pas changé ; le dénominateur oui.

Si l’on exclut aussi le compte de garde déclaré de 100,000 unités, le dénominateur ajusté devient 600,000 et OWNER-A représente 50%. Cette troisième vue est conditionnelle à l’exclusion de garde. On ne peut l’appeler « 50% de toute l’offre ». Un rapport clair place les nombres alternatifs côte à côte et explique pourquoi ils diffèrent.

La concentration n’est pas un verdict d’intention. Une distribution concentrée peut provenir d’allocations, de garde opérationnelle, d’acquisition progressive ou de fragmentation délibérée. Des comptes visibles dispersés peuvent cacher un contrôle partagé. La bonne interprétation décrit les soldes mesurés et l’incertitude résiduelle, pas des libellés « sûr » ou « arnaque ».

Inspecter les classifications et la sensibilité

Tenir un registre d’exclusion avec compte, montant, rôle, source, confiance et motif d’exclusion. La garde de pool exige des preuves de rôle ; une icône mémorable d’explorateur ne suffit pas. Une affirmation de destruction exige pareillement des preuves appropriées de chaîne/compte/programme, pas un surnom d’adresse. Ne pas soustraire une seconde fois une offre déjà retirée de la mesure d’offre.

Pour la comparaison pédagogique, garder l’instantané constant et changer une classification à la fois. Cela rend la sensibilité reproductible. Si le résultat ajusté est très sensible à une classification incertaine de plateforme d’échange, cette incertitude est substantielle et appartient à la conclusion.

Concentration et liquidité interagissent mais restent distinctes. Le solde d’un grand détenteur ne dit pas combien de valeur de cotation peut être obtenue d’une vente. La profondeur d’un pool n’identifie pas si plusieurs comptes partagent un contrôle. La leçon précédente fournit un modèle d’impact sur le prix ; celle-ci fournit une limite de comptabilisation de propriété.

• Concentration par compte : soldes agrégés par identifiant de compte de jetons.
• Agrégation par adresse : soldes combinés par adresse de contrôle vérifiée.
• Propriétaire bénéficiaire : personne/entité ultime, non établie par une adresse seule.
• Exclusion opérationnelle : retrait analytique divulgué d’une vue particulière.
• Dénominateur : population d’offre/soldes utilisée pour le pourcentage.
• Analyse de sensibilité : résultats selon des classifications alternatives explicites.

ILLUSTRATIVE EXEMPLE — FIX-P07-04. Le jeu fictif complet totalise 1,000,000 unités de base. Chaque identifiant est un libellé synthétique.

OTHER est un agrégat de rapprochement total, pas un détenteur unique ni un compte de jetons classé. Il ne doit pas être inséré dans un classement des principaux détenteurs comme un portefeuille unique.

OBSERVED: Les comptes fournis A-TA1 et A-TA2 partagent OWNER-A dans ce jeu ; leur somme est 300,000.

INFERRED: OWNER-A a 30% des unités totales fournies et 42.8571% de la population ajustée hors pool selon les exclusions déclarées.

UNKNOWN: Combien d’humains contrôlent OWNER-A ou les soldes non résolus/en garde.

INSUFFICIENT EVIDENCE: Le jeu ne peut établir le plus grand détenteur humain, une fraude, une distribution sûre ou des produits de vente réalisables. Le libellé de X-TA est insuffisant pour une exclusion inconditionnelle de propriétaire bénéficiaire.

Compter les comptes de jetons comme des personnes ; classer OTHER comme un portefeuille unique ; oublier l’agrégation d’adresses communes ; mélanger les instantanés d’offre ; soustraire deux fois des destructions alléguées ; et présenter un pourcentage ajusté comme pourcentage de toute l’offre.

Calculer les parts brutes et hors pool de OWNER-A. Calculer la part combinée de OWNER-A et OWNER-B par rapport à l’offre totale et au dénominateur hors pool. Puis évaluer l’exclusion supplémentaire de X-TA comme cas de sensibilité.

• Confirmer l’actif exact et un instantané compatible.
• Rapprocher tous les montants fournis à la population déclarée.
• Agréger les propriétaires de comptes vérifiés ; ne pas déduire d’humains.
• Garder les vues brute, ajustée et de sensibilité distinctes.
• Publier le registre d’exclusion et la couverture non résolue.

Un pourcentage de concentration est indissociable de son unité d’agrégation, de son dénominateur et de ses exclusions. Des calculs transparents étayent l’investigation ; des décomptes opaques de détenteurs invitent à une fausse confiance.

Utiliser les vues par compte et par adresse pour des questions différentes. Ne jamais effacer l’incertitude avec un libellé de garde. Montrer comment un changement de dénominateur affecte le résultat.

Créer une barre de rapprochement pour un million d’unités, une accolade séparée d’agrégation OWNER-A et des panneaux de dénominateurs brut/hors pool/garde conditionnelle. Utiliser un remplissage hachuré pour X-TA et OTHER ; ne jamais les étiqueter comme humains indépendants connus. Imprimer numérateur et dénominateur sous chaque pourcentage.

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 RADAR 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.

• Solana getTokenLargestAccounts — La réponse des plus grands comptes est limitée à 20 comptes de jetons, pas tous les propriétaires. 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.
• Actifs Solana : mint et comptes de jetons — Identité du mint, propriété des comptes de jetons et rôles distincts de mint/création. 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-L05 ; poursuivre après avoir terminé l’exercice et examiné chaque explication du quiz.