Distribuzione dei detentori e concentrazione

EN fonte principale · P08-L07 · 45 minuti stimati · needs_review

Una classifica degli account token non è una classifica dei proprietari e una classifica dei proprietari non è un elenco di persone. Non riconciliare questi livelli può nascondere concentrazione, contare due volte saldi o attribuire l’inventario di un pool al team di un progetto.

Questa lezione normalizza posizioni grezze, deduplica un’esportazione e aggrega solo proprietari di account supportati dalle prove. P07 si concentrava sulla concentrazione specifica del lancio; qui la competenza consiste nel rendere coerente il dataset contabile prima di interpretarlo.

Definire l’unità di analisi

Scrivere se le righe rappresentano account token, indirizzi di proprietari, posizioni applicative o persone. L’enumerazione Solana degli account token per proprietario è una query nell’ambito del proprietario, con filtro per mint o programma [S08-OWNERS]. Non enumera ogni beneficiario umano.

Una query degli account più grandi restituisce venti account token [S08-LARGEST]. Non è un censimento completo dei proprietari. Un proprietario potrebbe avere diversi account piccoli fuori da quell’insieme, quindi aggregare solo righe restituite può sottostimare il suo totale. Indicare la copertura e non chiamare esaustiva un’esportazione parziale.

Il materiale è deliberatamente esaustivo per un mint in un contesto. Questa completezza è un’ipotesi educativa fornita, non qualcosa inferito da un sito web. Nel lavoro reale, documentare metodo di raccolta, filtri, paginazione e coerenza del contesto prima di affermare copertura completa.

Filtrare prima di sommare

Verificare prima rete e mint su ogni riga. Un’esportazione a livello di programma può contenere diversi mint. Sommare tutte le sue righe può produrre un «totale delle posizioni» impressionante ma privo di significato. Asset diversi non possono condividere un denominatore di offerta solo perché i decimali coincidono.

Distinguere poi importi grezzi e unità visualizzate usando il numero di decimali verificato. Preservare le stringhe di interi. Una riga duplicata non è un secondo saldo. Se lo stesso account appare due volte nella stessa istantanea, deduplicare solo quando i record sono dimostrabilmente identici. Valori in conflitto richiedono un conflitto irrisolto o una scelta definita dell’istantanea.

Account in contesti diversi non devono essere sommati disinvoltamente. Possono rappresentare lo stesso saldo prima e dopo un trasferimento. Un’esportazione unita non è automaticamente un’istantanea. Fissare i record a un limite coerente o etichettare il risultato come incompleto e temporalmente misto.

Aggregare proprietari supportati dalle prove

Dopo filtro e deduplicazione, raggruppare account token per il campo dell’autorità proprietaria fornito per il mint esatto. È una relazione a livello di account, non una scoperta di identità umana. Registrare come è stato decodificato il campo proprietario e verificare che non sia il campo del proprietario-programma di base.

Un’autorità proprietaria può rappresentare custodia o un’applicazione. Un indirizzo di custodia può detenere saldi per molti beneficiari; la loro distribuzione è sconosciuta se i record non la stabiliscono. Viceversa, diversi indirizzi di proprietari possono avere un solo controllore, ma questa aggregazione da sola non lo stabilisce.

Non unire proprietari perché condividono finanziamento, tempistica o un’etichetta. Queste relazioni possono motivare un’ipotesi separata. Denominatore e risultato contabile fornito dovrebbero restare riproducibili senza raggruppamenti speculativi. Unioni non supportate possono trasformare una statistica di concentrazione in un’accusa.

Riconciliare il limite dell’offerta

Per un’istantanea contabile standard completa, confrontare i saldi grezzi filtrati con il totale fornito indipendentemente. Se si riconciliano, ciò sostiene la coerenza interna del dataset. Non stabilisce autenticità dei valori fittizi, né la riconciliazione prova l’assenza di comportamenti speciali di trasferimento.

Se la somma è inferiore, identificare account non restituiti, contesti incompatibili o componenti contabili omesse. Se è superiore, verificare duplicati, righe di mint errato ed errori di unità. Non forzare mai l’uguaglianza inserendo un residuo senza nome poi trattato come detentore reale.

Un residuo dichiarato può essere utile in un dataset parziale, ma resta un aggregato di composizione sconosciuta. Non deve essere classificato come una sola persona o proprietario. Il modello senza residuo dell’esercizio rende esatta la correzione; indagini successive possono richiedere un pannello separato di copertura irrisolta.

Rendere trasparenti categorie e politiche del denominatore

Inventario del pool e saldi in custodia restano posizioni nella distribuzione grezza. Una politica analitica può escluderli per una domanda specifica, ma non rimuove token dall’offerta. Mostrare denominatori originale e rettificato e fornire una ragione per ogni esclusione.

«Concentrazione dei proprietari esclusi i pool» e «concentrazione dei beneficiari» sono diverse. Escludere un account pool verificato può rispondere alla prima. Escludere la custodia senza conoscere i beneficiari può nascondere concentrazione anziché risolverla. Fornire una vista di sensibilità anziché presentare il numero rettificato come l’unico corretto.

Classificare separatamente righe degli account e totali dei proprietari. Un proprietario può guidare la classifica aggregata anche se nessun singolo account è il più grande. È la competenza trasferibile chiave: aritmetica corretta applicata all’unità sbagliata risponde comunque alla domanda sbagliata.

Riportare limiti insieme alle percentuali

Includere numeratore, denominatore, unità di aggregazione e istantanea. Evitare un singolo distintivo «primo detentore40%» senza distinzione proprietario/account. Una frase più precisa dice «L’autorità proprietaria A detiene400 unità visualizzate su due account,40% del totale fornito di1000 unità a S0».

Nulla in questo calcolo identifica un insider, prevede vendite o stima il patrimonio dei beneficiari. Una grande autorità proprietaria può essere osservata senza conoscere il controllo umano. L’esercizio è valutato su contabilità e ambito, non sull’assegnazione da parte dell’analista di un verdetto rialzista o ribassista.

• Deduplicazione: rimozione di record ripetuti provati.
• Aggregazione per proprietario: raggruppamento di account per autorità proprietaria supportata dalle prove.
• Copertura: estensione dei record inclusi.
• Residuo: differenza non allocata, non necessariamente un solo detentore.
• Beneficiario: titolare sottostante dei diritti le cui posizioni possono differire dall’autorità di custodia.
• Vista di sensibilità: ricalcolo secondo una politica esplicitamente diversa.

ILLUSTRATIVE — FIX-P08-07. SIM-SOL-A / MINT-D, d=2, S0. Le righe obiettivo uniche sono esaustive per il materiale contabile standard. Offerta grezza 100,000 significa 1000 token visualizzati.

La politica E esclude solo P1. Una politica di sensibilità separata F esclude anche C1; nessun dato sui beneficiari sostiene una classifica a livello di persone.

OBSERVED nel materiale: H6 ripete H2; H7 ha il mint errato. A è l’autorità proprietaria fornita per due account token dell’obiettivo.

INFERRED: i saldi obiettivo unici totalizzano 100,000 unità grezze. I400 token di A superano ogni singolo account ordinario; la sua quota dell’offerta grezza è 40%.

UNKNOWN: beneficiari della custodia, identità umana di A ed eventuale controllo condiviso con B.

INSUFFICIENT EVIDENCE: relazioni di finanziamento o etichette non possono giustificare ulteriori unioni di proprietari. Le politiche di esclusione non stabiliscono posizioni circolanti a livello di persone.

Sommare righe del mint errato, contare voci di esportazione duplicate, raggruppare per proprietario-programma, classificare un residuo come una persona, unire in base a etichette e nascondere esclusioni dietro una percentuale del detentore.

Filtrare/deduplicare l’esportazione, riconciliare con l’offerta e classificare account unici e autorità proprietarie. Calcolare la quota di A secondo offerta totale, politica E e sensibilità F. Indicare quale classifica possa essere chiamata classifica dei detentori umani.

• Filtrare rete e mint esatti.
• Deduplicare solo ripetizioni provate.
• Normalizzare unità grezze.
• Raggruppare il campo proprietario corretto.
• Riconciliare copertura coerente.
• Pubblicare sia esclusioni sia denominatore.
• Tenere separata l’attribuzione umana.

L’analisi della distribuzione parte dall’integrità del dataset. Filtro corretto e aggregazione per proprietario possono cambiare classifiche senza cambiare offerta.

Account, autorità proprietarie e persone sono unità diverse. I denominatori rettificati sono politiche. La riconciliazione sostiene coerenza interna, non identità o intento.

Mostrare righe di input con H6/H7 visibilmente respinte per ragioni distinte; totale grezzo riconciliato 100,000. Classifiche degli account e dei proprietari affiancate. Tre pannelli della quota di A40%,57.1429%,66.6667% con denominatori1000/700/600 e nota sulla custodia sconosciuta.

Distribuzione illustrativa di account e autorità proprietarie; nessuna attribuzione del controllo umano.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Solana getTokenLargestAccounts — Venti account token più grandi; non distribuzione esaustiva dei detentori umani. Verificato 2026-09-30.
• Solana getTokenAccountsByOwner — Enumerazione nell’ambito del proprietario filtrata per mint o programma. Verificato 2026-09-30.
• Solana getTokenSupply — Offerta grezza, decimali e contesto della risposta RPC; non una definizione di offerta circolante. Verificato 2026-09-30.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L08 dopo l’esercizio svolto e la revisione del quiz.