Distribution et concentration des détenteurs

Source maître EN · P08-L07 · 45 minutes estimées · needs_review

Un classement de comptes de jetons n’est pas un classement de propriétaires, et un classement de propriétaires n’est pas une liste d’humains. Ne pas rapprocher ces couches peut masquer la concentration, compter deux fois les soldes ou attribuer les stocks d’un pool à une équipe de projet.

Cette leçon normalise les avoirs bruts, déduplique un export et agrège uniquement les propriétaires de comptes étayés. P07 traitait la concentration propre au lancement ; ici, la compétence est de rendre cohérent le jeu comptable avant de l’interpréter.

Définir l’unité d’analyse

Écrire si les lignes représentent comptes de jetons, adresses propriétaires, positions applicatives ou humains. L’énumération Solana de comptes de jetons par propriétaire est une requête dans le périmètre d’un propriétaire, avec filtre de mint ou programme [S08-OWNERS]. Elle n’énumère pas chaque bénéficiaire humain.

Une requête des plus grands comptes renvoie vingt comptes de jetons [S08-LARGEST]. Ce n’est pas un recensement complet des propriétaires. Un propriétaire pourrait avoir plusieurs petits comptes hors de cet ensemble, donc agréger seulement les lignes renvoyées peut sous-estimer son total. Marquer la couverture et ne pas appeler un export partiel exhaustif.

Le jeu est délibérément exhaustif pour un mint dans un contexte. Cette exhaustivité est une hypothèse pédagogique fournie, pas une déduction d’un site. Dans le travail réel, documenter méthode de collecte, filtres, pagination et cohérence de contexte avant d’affirmer une couverture complète.

Filtrer avant de sommer

Vérifier d’abord réseau et mint sur chaque ligne. Un export à l’échelle d’un programme peut contenir plusieurs mints. Sommer toutes ses lignes peut produire un « total d’avoirs » impressionnant mais sans sens. Des actifs différents ne peuvent partager un dénominateur d’offre simplement parce que leurs décimales correspondent.

Puis distinguer montants bruts et unités affichées avec le nombre vérifié de décimales. Préserver les chaînes d’entiers. Une ligne dupliquée n’est pas un second solde. Si le même compte apparaît deux fois dans le même instantané, dédupliquer uniquement lorsque les enregistrements sont manifestement identiques. Des valeurs contradictoires exigent un conflit non résolu ou un choix défini d’instantané.

Les comptes de contextes différents ne doivent pas être additionnés à la légère. Ils peuvent représenter le même solde avant et après transfert. Un export fusionné n’est pas automatiquement un instantané. Fixer les enregistrements à une limite cohérente ou étiqueter le résultat incomplet et mélangé dans le temps.

Agréger les propriétaires étayés

Après filtrage et déduplication, regrouper les comptes de jetons selon le champ fourni d’autorité propriétaire pour le mint exact. C’est une relation au niveau des comptes, pas une découverte d’identité humaine. Consigner comment le champ propriétaire a été décodé et vérifier que ce n’est pas le champ de programme propriétaire de base.

Une autorité propriétaire peut représenter une garde ou une application. Une adresse de garde peut détenir des soldes pour de nombreux bénéficiaires ; leur distribution est inconnue à moins que des enregistrements l’établissent. Inversement, plusieurs adresses propriétaires peuvent avoir un contrôleur unique, mais cette agrégation seule ne l’établit pas.

Ne pas fusionner les propriétaires parce qu’ils partagent financement, moment ou libellé. Ces relations peuvent motiver une hypothèse distincte. Le dénominateur et le résultat comptable fourni doivent rester reproductibles sans regroupement spéculatif. Des fusions non étayées peuvent transformer une statistique de concentration en accusation.

Rapprocher la limite d’offre

Pour un instantané comptable standard complet, comparer soldes bruts filtrés et total fourni indépendamment. S’ils se rapprochent, cela étaye la cohérence interne de ce jeu. Cela n’établit pas l’authenticité des valeurs fictives, et le rapprochement ne prouve pas l’absence de comportements spéciaux de transfert.

Si la somme est inférieure, identifier comptes non renvoyés, contextes incompatibles ou composantes comptables omises. Si elle est supérieure, tester doublons, lignes du mauvais mint et erreurs d’unité. Ne jamais forcer l’égalité en insérant un résidu sans nom ensuite traité comme détenteur réel.

Un résidu déclaré peut être utile dans un jeu partiel, mais reste un agrégat de composition inconnue. Il ne doit pas être classé comme un humain ou propriétaire unique. Le modèle sans résidu de l’exercice rend la correction exacte ; des investigations ultérieures pourraient exiger un panneau distinct de couverture non résolue.

Garder catégories et politiques de dénominateur transparentes

Stocks de pool et soldes en garde restent des avoirs dans la distribution brute. Une politique analytique peut les exclure pour une question spécifique, mais ne retire pas les jetons de l’offre. Montrer dénominateurs original et ajusté et donner un motif pour chaque exclusion.

« Concentration de propriétaires hors pool » et « concentration de bénéficiaires » sont différentes. Exclure un compte de pool vérifié peut répondre à la première. Exclure la garde sans connaître les bénéficiaires peut masquer la concentration plutôt que la résoudre. Fournir une vue de sensibilité plutôt que nommer le nombre ajusté comme seul correct.

Classer les lignes de comptes et totaux de propriétaires séparément. Un propriétaire peut mener le classement agrégé même si aucun compte individuel n’est le plus grand. C’est la compétence clé à transférer : une arithmétique correcte appliquée à la mauvaise unité répond encore à la mauvaise question.

Rapporter les limites avec les pourcentages

Inclure numérateur, dénominateur, unité d’agrégation et instantané. Éviter un badge unique disant « premier détenteur40% » sans distinction propriétaire/compte. Une phrase plus solide dit « L’autorité propriétaire A détient400 unités affichées sur deux comptes,40% du total fourni de1000 unités à S0. »

Rien dans ce calcul n’identifie un initié, ne prévoit des ventes ni n’estime la richesse bénéficiaire. Une grande autorité propriétaire peut être observée sans connaître le contrôle humain. L’exercice est noté sur comptabilité et périmètre, pas sur l’attribution d’un verdict haussier ou baissier par l’analyste.

• Déduplication : retrait d’enregistrements répétés prouvés.
• Agrégation de propriétaires : regroupement de comptes par autorité propriétaire étayée.
• Couverture : étendue des enregistrements inclus.
• Résidu : différence non allouée, pas nécessairement un détenteur unique.
• Bénéficiaire : ayant droit sous-jacent dont les avoirs peuvent différer de l’autorité de garde.
• Vue de sensibilité : recalcul selon une politique explicitement différente.

ILLUSTRATIVE — FIX-P08-07. SIM-SOL-A / MINT-D, d=2, S0. Les lignes cibles uniques sont exhaustives pour le jeu comptable standard. L’offre brute 100,000 signifie 1000 jetons affichés.

La politique E exclut uniquement P1. Une politique distincte de sensibilité F exclut aussi C1 ; aucune donnée de bénéficiaires n’étaye un classement de personnes.

OBSERVED dans le jeu : H6 répète H2 ; H7 a le mauvais mint. A est l’autorité propriétaire fournie pour deux comptes token de la cible.

INFERRED: Les soldes cibles uniques totalisent 100,000 unités brutes. Les400 jetons de A dépassent chaque compte ordinaire individuel ; sa part d’offre brute est 40%.

UNKNOWN: Bénéficiaires de garde, identité humaine de A et tout contrôle partagé avec B.

INSUFFICIENT EVIDENCE: Relations de financement ou libellés ne peuvent justifier davantage de fusions de propriétaires. Les politiques d’exclusion n’établissent pas les avoirs en circulation au niveau des personnes.

Sommer des lignes de mauvais mint, compter des entrées dupliquées d’export, regrouper par programme propriétaire, classer un résidu comme personne unique, fusionner selon des libellés et cacher les exclusions derrière un pourcentage de détenteur.

Filtrer/dédupliquer l’export, rapprocher de l’offre et classer comptes uniques et autorités propriétaires. Calculer la part de A selon offre totale, politique E et sensibilité F. Indiquer quel classement peut être appelé classement de détenteurs humains.

• Filtrer réseau et mint exacts.
• Dédupliquer uniquement les répétitions prouvées.
• Normaliser les unités brutes.
• Regrouper le bon champ propriétaire.
• Rapprocher une couverture cohérente.
• Publier exclusions et dénominateur.
• Garder l’attribution humaine distincte.

L’analyse de distribution commence par l’intégrité du jeu. Un filtrage correct et une agrégation de propriétaires peuvent changer les classements sans changer l’offre.

Comptes, autorités propriétaires et humains sont des unités différentes. Les dénominateurs ajustés sont des politiques. Le rapprochement étaye la cohérence interne, pas l’identité ni l’intention.

Montrer les lignes d’entrée avec H6/H7 visiblement rejetées pour raisons distinctes ; total brut rapproché 100,000. Classements de comptes et propriétaires côte à côte. Trois panneaux de part A40%,57.1429%,66.6667% avec dénominateurs1000/700/600 et note de garde inconnue.

Distribution illustrative de comptes et autorités propriétaires ; aucune attribution de contrôle humain.

Utiliser du SVG/HTML déterministe ou des graphiques avec alternatives textuelles, bleu marine foncé/noir et accents mesurés cyan, bleu électrique et violet. Étiqueter chaque quantité et incertitude. À 390px, empiler les panneaux ; la vérification 768px/ordinateur et RTL arabe reste un travail futur sur les actifs. Garder les identifiants LTR et les axes factuels/sens des arêtes inchangés. Utiliser uniquement la marque officielle BlockAssay fournie si une identité de marque est ajoutée. Les deux enregistrements sont des spécifications, pas des actifs livrés.

Utiliser RADAR pour l’objectif pédagogique circonscrit de la leçon uniquement si la prise en charge du réseau, l’identité exacte, les champs et la provenance sont vérifiés. Ce contenu n’affirme aucun point de terminaison d’exécution ni capacité de fournisseur. Utiliser le jeu hors ligne intégré sans accès payant. Les données manquantes restent inconnues ; aucune connexion de portefeuille, signature de transaction, lancement de jeton ou transaction en direct n’est requis. Les progrès Academy, paiements et recommandations ne changent jamais les preuves Radar. Un Passeport diagnostique préserve observations et limites, pas une prévision de prix ni un certificat de sécurité.

• Solana getTokenLargestAccounts — Vingt plus grands comptes de jetons ; pas une distribution exhaustive de détenteurs humains. Vérifié le 2026-09-30.
• Solana getTokenAccountsByOwner — Énumération dans le périmètre du propriétaire filtrée par mint ou programme. Vérifié le 2026-09-30.
• Solana getTokenSupply — Offre brute, décimales et contexte de réponse RPC ; pas une définition d’offre en circulation. Vérifié le 2026-09-30.

La documentation étaye les mécanismes, pas les valeurs fictives du jeu. Tous les exemples et enregistrements d’exercice sont du matériel original ILLUSTRATIVE, figé dans ce fichier. S0/S1 sont des libellés synthétiques de contexte ; observedAt est null car aucune mesure de registre en direct ou historique n’a été collectée. Réexaminer la documentation et le comportement réellement déployé avant toute publication ou intégration.

P08-L08 après l’exercice corrigé et l’examen du quiz.