Concentração de detentores

Fonte mestra EN · P07-L04 · 45 minutos estimados · needs_review

Objetivos de aprendizagem:

• Calcular concentração bruta e ajustada com denominadores explícitos.
• Agregar contas sob um endereço titular verificado sem inferir identidade humana.
• Explicar exclusões operacionais e sensibilidade a rótulos incertos de custódia.

“Os maiores detentores possuem 70%” soa preciso, mas é incompleto, a menos que explique quem ou o que foi contado, qual denominador foi usado e quais contas foram excluídas. Um cofre de pool, uma conta de custódia de corretora e várias contas controladas por um endereço podem distorcer um gráfico simplista. A habilidade é calcular medidas transparentes de concentração sem alegar que contas de token equivalem a pessoas independentes.

Decidir a medição antes de calculá-la

Comece com identidade do ativo e escopo de observação. O denominador de oferta total, os saldos e a evidência de papel de conta devem descrever a mesma rede/mint e um snapshot compatível. Combinar uma oferta atual com uma tabela mais antiga de saldos cria uma divergência não rotulada. Se alinhamento exato estiver indisponível, declare a aproximação e não finja que o percentual é uma medição contemporânea exata.

O método RPC de maiores contas de token da Solana retorna até 20 contas de token, não uma lista completa de detentores humanos [S-LARGEST]. O modelo de contas da Solana permite várias contas de token para o mesmo mint sob um titular de conta [S-TOKENS]. Esses fatos motivam dois níveis separados de agregação: saldos de contas e controle no nível de endereço. Nenhum sozinho prova titularidade beneficiária final.

Use a lista de maiores contas para identificar candidatos à inspeção, não para inventar uma distribuição completa. Um conjunto de dados somente dos vinte maiores pode sustentar alguns cálculos parciais de concentração, mas não um histograma completo da cauda longa. Um campo de titular não resolvido deve permanecer não resolvido. Não combine endereços apenas porque foram financiados pelo mesmo intermediário.

Calcular várias visões, rotular cada uma

Uma visão bruta usa todos os saldos fornecidos e a oferta total fornecida. Uma visão agregada por endereço combina contas com o mesmo endereço controlador verificado. Uma visão ajustada exclui saldos operacionais identificados para uma finalidade analítica declarada. Cada visão responde a uma pergunta diferente; nenhuma substitui automaticamente as outras.

Considere um cofre de pool contendo 300,000 de 1,000,000 unidades. Ocupa 30% da distribuição bruta de contas. Se o cofre é verificado como custódia de pool, chamá-lo de “uma baleia possui pessoalmente 30%” não tem respaldo. Ainda assim, removê-lo de um gráfico não torna seus ativos irrelevantes: direitos de LP e controles de saque do pool ainda afetam capacidade de mercado.

Um rótulo de corretora apresenta outro problema. Um endereço de custódia pode representar múltiplos usuários, mas um rótulo do provedor não revela a distribuição exata de beneficiários finais. Se o papel é somente declarado, mostre tanto o resultado bruto quanto um resultado opcional de sensibilidade em vez de excluí-lo silenciosamente. Um saldo excluído é um ajuste metodológico, não evidência de que sua exposição econômica desapareceu.

Denominadores podem mudar a conclusão aparente

No conjunto de dados, duas contas controladas pelo endereço OWNER-A contêm 180,000 e 120,000. Seu saldo combinado é 300,000. Contra a oferta total, isso é 30%. Excluir o pool verificado de 300,000 unidades deixa um denominador de 700,000; OWNER-A então representa 42.8571% dos saldos ajustados fora do pool. O numerador não mudou; o denominador mudou.

Se você também exclui a conta de custódia declarada de 100,000 unidades, o denominador ajustado se torna 600,000 e OWNER-A representa 50%. Esta terceira visão é condicionada à exclusão de custódia. Não pode ser chamada de “50% de toda a oferta”. Um relatório claro coloca os números alternativos lado a lado e explica por que diferem.

Concentração não é um veredito sobre intenção. Uma distribuição concentrada pode surgir de alocações, custódia operacional, vesting ou fragmentação deliberada. Contas visíveis dispersas podem ocultar controle compartilhado. A interpretação correta descreve saldos medidos e incerteza residual, não rótulos de “seguro” ou “golpe”.

Inspecionar classificações e sensibilidade

Mantenha um registro de exclusões com conta, quantia, papel, fonte, confiança e razão para exclusão. Custódia de pool exige evidência de papel; um ícone memorável de explorer não basta. Uma afirmação de queima exige igualmente evidência apropriada de blockchain/conta/programa, não um apelido de endereço. Não subtraia pela segunda vez oferta já removida da medida de oferta.

Para comparação educacional, mantenha o snapshot constante e mude uma classificação por vez. Isso torna a sensibilidade reproduzível. Se o resultado ajustado é muito sensível a uma classificação incerta de corretora, a incerteza é material e pertence à conclusão.

Concentração e liquidez interagem, mas permanecem distintas. O saldo de um grande detentor não informa quanto valor de cotação pode ser obtido de uma venda. A profundidade de um pool não identifica se múltiplas contas compartilham controle. A lição anterior fornece um modelo de impacto no preço; esta fornece um limite de contabilização de titularidade.

• Concentração de contas: saldos agregados por ID de conta de token.
• Agregação por endereço: saldos combinados por endereço controlador verificado.
• Beneficiário final: uma pessoa/entidade final, não estabelecida somente por um endereço.
• Exclusão operacional: uma remoção analítica divulgada de uma visão específica.
• Denominador: população de oferta/saldos usada para o percentual.
• Análise de sensibilidade: resultados sob classificações alternativas explícitas.

EXEMPLO ILLUSTRATIVE — FIX-P07-04. O conjunto completo fictício totaliza 1,000,000 unidades base. Todo ID é um rótulo sintético.

OTHER é um agregado para reconciliação total, não um único detentor ou conta de token classificada. Não deve ser inserido em um ranking de maiores detentores como uma carteira.

OBSERVED: Contas fornecidas A-TA1 e A-TA2 compartilham OWNER-A neste conjunto de dados; sua soma é 300,000.

INFERRED: OWNER-A tem 30% do total de unidades fornecidas e 42.8571% da população ajustada fora do pool sob as exclusões declaradas.

UNKNOWN: Quantos humanos controlam OWNER-A ou os saldos não resolvidos/em custódia.

INSUFFICIENT EVIDENCE: O conjunto de dados não pode estabelecer o maior detentor humano, fraude, distribuição segura ou receita realizável de venda. O rótulo de X-TA é insuficiente para uma exclusão incondicional de beneficiário final.

Contar contas de token como pessoas; classificar OTHER como uma carteira; esquecer agregação de endereço comum; misturar snapshots de oferta; subtrair queimas alegadas duas vezes; e apresentar um percentual ajustado como percentual de toda a oferta.

Calcule as participações bruta e com exclusão de pool de OWNER-A. Calcule a participação combinada de OWNER-A e OWNER-B contra a oferta total e contra o denominador com exclusão de pool. Depois avalie a exclusão adicional de X-TA como caso de sensibilidade.

• Confirmar ativo exato e snapshot compatível.
• Reconciliar todas as quantias fornecidas com a população declarada.
• Agregar titulares de contas verificados; não inferir humanos.
• Manter visões bruta, ajustada e de sensibilidade separadas.
• Publicar registro de exclusões e cobertura não resolvida.

Um percentual de concentração é inseparável de sua unidade de agregação, denominador e exclusões. Cálculos transparentes apoiam investigação; contagens opacas de detentores convidam à falsa confiança.

Use visões de conta e endereço para perguntas diferentes. Nunca apague incerteza com um rótulo de custódia. Mostre como uma mudança de denominador afeta o resultado.

Criar uma barra de reconciliação para um milhão de unidades, uma chave separada de agregação de OWNER-A e painéis de denominadores bruto/fora do pool/custódia condicional. Usar preenchimento hachurado para X-TA e OTHER; nunca rotulá-los como humanos independentes conhecidos. Imprimir numerador e denominador sob cada percentual.

Regras de entrega visual: azul-marinho escuro/preto, detalhes ciano/azul elétrico/violeta, unidades e incerteza explicitamente rotuladas. Use gráficos determinísticos ou SVG, não capturas de tela fabricadas. Em 390 px, empilhe anotações e forneça a tabela de dados como alternativa textual; verifique 768 px e desktop depois. Em árabe, localize rótulos e layout com RTL nativo, isolando endereços/hashes em LTR e mantendo a direção real das transferências e a cronologia. Use somente o logo oficial BlockAssay fornecido se identidade visual for adicionada. Nenhum recurso visual ou renderização mobile/RTL é alegado pronto.

Use RADAR somente quando rede exata, ativo e campos necessários forem compatíveis e sua procedência for visível. Esta é uma inspeção educacional somente de leitura, não uma operação ou lançamento de token. Use o conjunto de dados offline fornecido se acesso ou dados estiverem indisponíveis; informação ausente permanece desconhecida. Uma futura ação Abrir na BlockAssay precisa de roteamento de runtime validado e cobertura de fontes. Nenhum CTA executável de ativo é fornecido para identificadores ilustrativos. Participação na Academy e status comercial nunca mudam observações do Radar.

• Solana getTokenLargestAccounts — Resposta de maiores contas é limitada a 20 contas de token, não todos os titulares. Verificada em 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeração de contas de token por titular de conta; campo de titularidade não é identidade humana. Verificada em 2026-09-30.
• Ativos Solana: mints e contas de token — Identidade do mint, titularidade de contas de token e papéis distintos de mint/criação. Verificada em 2026-09-30.

As tabelas e os conjuntos de dados dos exercícios são material educacional original, salvo quando explicitamente designados HISTORICAL. Identificadores fictícios são deliberadamente inválidos como endereços de blockchain. Documentação apoia definições de mecanismos, não valores inventados dos exercícios. Inspeção de fontes é pesquisa editorial, não medição de blockchain ao vivo. Fontes podem mudar; revise novamente antes da publicação.

P07-L05; prossiga após concluir o exercício e revisar cada explicação do quiz.