Distribuição de detentores e concentração

Fonte mestra EN · P08-L07 · 45 minutos estimados · needs_review

Uma classificação de contas de token não é classificação de proprietários, e uma classificação de proprietários não é lista de humanos. Não reconciliar essas camadas pode ocultar concentração, contar saldos duas vezes ou atribuir estoque de um pool à equipe do projeto.

Esta lição normaliza posições brutas, remove duplicatas de uma exportação e agrega apenas proprietários de contas sustentados pela evidência. P07 focou concentração específica de lançamentos; aqui a habilidade é tornar o conjunto contábil coerente antes de interpretá-lo.

Defina a unidade de análise

Escreva se linhas representam contas de token, endereços de proprietários, posições de aplicações ou humanos. A enumeração Solana de contas de token por proprietário é consulta no escopo do proprietário, com filtro de mint ou programa [S08-OWNERS]. Não enumera todo beneficiário humano.

Uma consulta de maiores contas retorna vinte contas de token [S08-LARGEST]. Não é censo completo de proprietários. Um proprietário pode ter várias contas pequenas fora desse conjunto, portanto agregar apenas linhas retornadas pode subestimar seu total. Marque cobertura e não chame exportação parcial de exaustiva.

O conjunto de dados é deliberadamente exaustivo para um mint em um contexto. Essa completude é premissa educacional fornecida, não algo inferido de um site. Em trabalho real, documente método de coleta, filtros, paginação e consistência de contexto antes de alegar cobertura completa.

Filtre antes de somar

Primeiro verifique rede e mint em cada linha. Uma exportação de todo o programa pode conter vários mints. Somar todas as linhas pode produzir impressionantes, mas sem sentido, “posições totais”. Ativos diferentes não podem compartilhar denominador de oferta só porque suas casas decimais correspondem.

Depois distinga quantidades brutas de unidades exibidas usando o número verificado de casas decimais. Preserve strings de inteiros. Linha duplicada não é segundo saldo. Se a mesma conta aparece duas vezes no mesmo retrato, remova duplicatas somente quando os registros forem demonstravelmente idênticos. Valores conflitantes exigem conflito não resolvido ou escolha definida de retrato.

Contas em contextos diferentes não devem ser somadas casualmente. Podem representar o mesmo saldo antes e depois de transferência. Exportação mesclada não é automaticamente retrato. Fixe registros a um limite coerente ou rotule o resultado como incompleto e misturado no tempo.

Agregue proprietários sustentados pela evidência

Após filtrar e remover duplicatas, agrupe contas de token pelo campo fornecido de autoridade proprietária para o mint exato. Isso é relação no nível de contas, não descoberta de identidade humana. Registre como o campo proprietário foi decodificado e verifique que não é o campo básico de proprietário do programa.

Uma autoridade proprietária pode representar custódia ou aplicação. Um endereço de custódia pode deter saldos para muitos beneficiários; sua distribuição é desconhecida salvo se registros a estabelecerem. Por outro lado, vários endereços de proprietários podem ter um controlador, mas isso não é estabelecido apenas por esta agregação.

Não funda proprietários porque compartilham financiamento, timing ou rótulo. Essas relações podem motivar hipótese separada. O denominador e resultado contábil fornecidos devem permanecer reproduzíveis sem agrupamento especulativo. Fusões sem suporte podem transformar estatística de concentração em acusação.

Reconcilie o limite da oferta

Para um retrato completo de contabilidade padrão, compare saldos brutos filtrados com o total fornecido independentemente. Se reconciliam, isso sustenta consistência interna deste conjunto de dados. Não estabelece autenticidade dos valores fictícios, nem a reconciliação prova ausência de comportamentos especiais de transferência.

Se a soma for menor, identifique contas não retornadas, contextos incompatíveis ou componentes contábeis omitidos. Se maior, teste duplicatas, linhas de mint errado e erros de unidade. Nunca force igualdade inserindo residual sem nome que depois é tratado como detentor real.

Um residual declarado pode ser útil em conjunto parcial, mas permanece agregado de composição desconhecida. Não deve ser classificado como humano ou proprietário único. O modelo sem residual do exercício torna a correção exata; investigações posteriores podem exigir painel separado de cobertura não resolvida.

Mantenha categorias e políticas de denominador transparentes

Estoque do pool e saldos de custódia permanecem posições na distribuição bruta. Uma política analítica pode excluí-los para pergunta específica, mas não remove tokens da oferta. Mostre denominadores originais e ajustados e dê uma razão para cada exclusão.

“Concentração de proprietários fora do pool” e “concentração de beneficiários” são diferentes. Excluir conta de pool verificada pode responder à primeira. Excluir custódia sem conhecer beneficiários pode esconder concentração em vez de resolvê-la. Forneça visão de sensibilidade em vez de nomear o número ajustado como unicamente correto.

Classifique linhas de contas e totais de proprietários separadamente. Um proprietário pode liderar a classificação agregada mesmo quando nenhuma conta individual é a maior. Esta é a habilidade central de transferência: aritmética correta aplicada à unidade errada ainda responde à pergunta errada.

Relate limites junto às porcentagens

Inclua numerador, denominador, unidade de agregação e retrato. Evite selo único “maior detentor40%” sem distinção proprietário/conta. Uma frase mais forte diz “Autoridade proprietária A detém400 unidades exibidas em duas contas,40% do total fornecido de1000 unidades em S0”.

Nada neste cálculo identifica alguém de dentro, prevê vendas ou estima riqueza de beneficiários. Uma grande autoridade proprietária pode ser observada sem conhecer controle humano. O exercício é avaliado por contabilidade e escopo, não por atribuir veredito de alta ou baixa.

• Remoção de duplicatas: remoção de registros comprovadamente repetidos.
• Agregação por proprietário: agrupamento de contas por autoridade proprietária sustentada pela evidência.
• Cobertura: extensão dos registros incluídos.
• Residual: diferença não alocada, não necessariamente um detentor.
• Beneficiário: titular subjacente cujas posições podem diferir da autoridade de custódia.
• Visão de sensibilidade: recálculo sob política explicitamente diferente.

ILLUSTRATIVE — FIX-P08-07. SIM-SOL-A / MINT-D, d=2, S0. Linhas únicas do alvo são exaustivas para o conjunto de contabilidade padrão. Oferta bruta 100,000 significa 1000 tokens exibidos.

A política E exclui apenas P1. Uma política de sensibilidade separada F também exclui C1; nenhum dado de beneficiário sustenta classificação no nível de pessoas.

OBSERVED no conjunto de dados: H6 repete H2; H7 tem mint errado. A é a autoridade proprietária fornecida para duas contas de tokens do alvo.

INFERRED: Saldos únicos do alvo totalizam 100,000 unidades brutas. Os400 tokens de A excedem cada conta comum individual; sua participação na oferta bruta é 40%.

UNKNOWN: Beneficiários da custódia, identidade humana de A e qualquer controle compartilhado com B.

INSUFFICIENT EVIDENCE: Relações de financiamento ou rótulos não justificam outras fusões de proprietários. Políticas de exclusão não estabelecem posições circulantes no nível de pessoas.

Somar linhas de mint errado, contar entradas duplicadas da exportação, agrupar por proprietário do programa, classificar residual como pessoa única, fundir por rótulos e ocultar exclusões atrás de porcentagem de detentor.

Filtre/remova duplicatas da exportação, reconcilie com oferta e classifique contas únicas e autoridades proprietárias. Calcule participação de A sob oferta total, política E e sensibilidade F. Declare qual classificação pode ser chamada de classificação de detentores humanos.

• Filtre rede e mint exatos.
• Remova apenas repetições comprovadas.
• Normalize unidades brutas.
• Agrupe o campo proprietário correto.
• Reconcilie cobertura coerente.
• Publique exclusões e denominador.
• Mantenha atribuição humana separada.

Análise de distribuição começa com integridade do conjunto de dados. Filtragem correta e agregação por proprietário podem mudar classificações sem mudar oferta.

Contas, autoridades proprietárias e humanos são unidades diferentes. Denominadores ajustados são políticas. Reconciliação sustenta consistência interna, não identidade nem intenção.

Mostre linhas de entrada com H6/H7 visivelmente rejeitadas por razões distintas; total bruto reconciliado 100,000. Classificações de contas e proprietários lado a lado. Três painéis de participação de A40%,57.1429%,66.6667% com denominadores1000/700/600 e nota de custódia desconhecida.

Distribuição ilustrativa de contas e autoridade de proprietário; nenhuma atribuição de controle humano.

Use SVG/HTML determinístico ou gráficos com alternativas textuais, azul-marinho escuro/preto e ciano, azul elétrico e violeta discretos. Rotule cada quantidade e incerteza. Em 390px empilhe painéis; a verificação em 768px/desktop e RTL árabe permanece trabalho futuro dos recursos visuais. Mantenha identificadores em LTR e eixos factuais/direções das arestas inalterados. Use apenas a marca oficial BlockAssay fornecida se identidade visual for adicionada. Ambos os registros são especificações, não recursos entregues.

Use RADAR para o propósito educacional delimitado da lição somente se suporte à rede, identidade exata, campos e procedência forem verificados. Nenhum endpoint de runtime ou capacidade de provedor é afirmado por este conteúdo. Use o conjunto de dados offline incorporado sem acesso pago. Dados ausentes permanecem desconhecidos; nenhuma conexão de carteira, assinatura de transação, lançamento de token ou operação ao vivo é necessária. Progresso na Academy, pagamentos e indicações nunca mudam evidências do Radar. Um Passaporte Diagnóstico preserva observações e limites, não uma previsão de preço ou certificado de segurança.

• Solana getTokenLargestAccounts — Vinte maiores contas de token; não é distribuição exaustiva de detentores humanos. Verificada em 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeração no escopo do proprietário, filtrada por mint ou programa. Verificada em 2026-09-30.
• Solana getTokenSupply — Oferta bruta, casas decimais e contexto da resposta RPC; não é definição de oferta circulante. Verificada em 2026-09-30.

A documentação apoia mecanismos, não valores fictícios do conjunto de dados. Todos os exemplos e registros dos exercícios são material ILLUSTRATIVE original, fixado neste arquivo. S0/S1 são rótulos de contexto sintéticos; observedAt é null porque nenhuma medição de registro ao vivo ou histórico foi coletada. Revise novamente a documentação e o comportamento realmente implantado antes de qualquer publicação ou integração.

P08-L08 após o exercício resolvido e a revisão do quiz.