Distribución y concentración de tenedores

Máster de origen EN · P08-L07 · 45 minutos estimados · needs_review

Una clasificación de cuentas de tokens no es una clasificación de propietarios, y esta no es una lista de humanos. No conciliar esas capas puede ocultar concentración, contar saldos dos veces o atribuir inventario de un pool a un equipo de proyecto.

Esta lección normaliza tenencias brutas, deduplica una exportación y agrega solo propietarios de cuentas respaldados. P07 se centró en concentración específica de lanzamientos; aquí la habilidad es hacer coherente el conjunto contable antes de interpretarlo.

Defina la unidad de análisis

Escriba si las filas representan cuentas de tokens, direcciones de propietarios, posiciones de aplicación o humanos. La enumeración de cuentas de tokens Solana por propietario es una consulta acotada al propietario con filtro de mint o programa [S08-OWNERS]. No enumera todos los beneficiarios humanos.

Una consulta de cuentas más grandes devuelve veinte cuentas de tokens [S08-LARGEST]. No es un censo completo de propietarios. Un propietario podría tener varias cuentas pequeñas fuera de ese conjunto, por lo que agregar solo las filas devueltas puede infravalorar su total. Marque cobertura y no llame exhaustiva a una exportación parcial.

El conjunto de datos es deliberadamente exhaustivo para un mint en un contexto. Esa integridad es un supuesto educativo suministrado, no algo inferido de un sitio web. En trabajo real documente método de recopilación, filtros, paginación y coherencia de contexto antes de afirmar cobertura completa.

Filtre antes de sumar

Primero verifique red y mint en cada fila. Una exportación de todo un programa puede contener varios mints. Sumar todas sus filas puede producir unas «tenencias totales» impresionantes pero sin sentido. Distintos activos no pueden compartir denominador de suministro solo porque coincidan sus decimales.

Luego distinga cantidades brutas y unidades mostradas usando el número verificado de decimales. Conserve cadenas de enteros. Una fila duplicada no es un segundo saldo. Si aparece dos veces la misma cuenta en la misma instantánea, deduplique solo cuando los registros sean demostrablemente idénticos. Valores contradictorios requieren conflicto sin resolver o elección definida de instantánea.

No deben sumarse despreocupadamente cuentas en contextos diferentes. Pueden representar el mismo saldo antes y después de una transferencia. Una exportación fusionada no es automáticamente una instantánea. Fije los registros a un límite coherente o etiquete el resultado como incompleto y mezclado en tiempo.

Agregue propietarios respaldados

Tras filtrar y deduplicar, agrupe cuentas de tokens por el campo suministrado de autoridad propietaria para el mint exacto. Es una relación a nivel de cuenta, no un descubrimiento de identidad humana. Registre cómo se decodificó el campo de propietario y verifique que no sea el campo de propietario de programa base.

Una autoridad propietaria puede representar custodia o aplicación. Una dirección de custodia puede mantener saldos para muchos beneficiarios; su distribución es desconocida salvo que los registros la establezcan. A la inversa, varias direcciones de propietarios pueden tener un controlador, pero esta agregación por sí sola no lo establece.

No fusione propietarios porque compartan financiación, momento o etiqueta. Esas relaciones pueden motivar una hipótesis separada. El denominador y resultado contable suministrado deben seguir reproducibles sin agrupaciones especulativas. Fusiones no respaldadas pueden transformar una estadística de concentración en acusación.

Concilie el límite de suministro

Para una instantánea completa de contabilidad estándar compare saldos brutos filtrados con el total suministrado independientemente. Si concilian, respalda coherencia interna de este conjunto. No establece autenticidad de los valores ficticios, ni la conciliación prueba que no haya comportamientos especiales de transferencia.

Si la suma es menor, identifique cuentas no devueltas, contextos incompatibles o componentes contables omitidos. Si es mayor, compruebe duplicados, filas de mint equivocado y errores de unidades. Nunca fuerce igualdad insertando un residuo sin nombre que luego se trate como tenedor real.

Un residuo declarado puede ser útil en datos parciales, pero sigue siendo un agregado de composición desconocida. No debe clasificarse como un humano o propietario. El modelo sin residuo del ejercicio hace exacta la corrección; investigaciones posteriores pueden necesitar un panel separado de cobertura sin resolver.

Mantenga transparentes categorías y políticas de denominador

Inventario de pool y saldos custodiales siguen siendo tenencias en la distribución bruta. Una política analítica puede excluirlos para una pregunta específica, pero no elimina tokens del suministro. Muestre denominadores originales y ajustados y dé una razón para cada exclusión.

«Concentración de propietarios sin pool» y «concentración de beneficiarios» son diferentes. Excluir una cuenta de pool verificada puede responder la primera. Excluir custodia sin conocer beneficiarios puede ocultar concentración en lugar de resolverla. Proporcione una vista de sensibilidad en lugar de nombrar el número ajustado como el único correcto.

Clasifique filas de cuentas y totales de propietarios por separado. Un propietario puede liderar la clasificación agregada aunque ninguna cuenta individual sea la más grande. Esta es la habilidad clave transferible: aritmética correcta aplicada a la unidad equivocada sigue respondiendo la pregunta equivocada.

Informe de límites junto a porcentajes

Incluya numerador, denominador, unidad de agregación e instantánea. Evite una sola insignia que diga «principal tenedor40%» sin distinguir propietario/cuenta. Una frase más sólida dice «La autoridad propietaria A tiene400 unidades mostradas en dos cuentas,40% del total suministrado de1000 unidades en S0».

Nada de este cálculo identifica a alguien con información privilegiada, pronostica ventas ni estima riqueza de beneficiarios. Puede observarse una gran autoridad propietaria sin conocer control humano. El ejercicio se evalúa por contabilidad y alcance, no por si el analista asigna veredicto alcista o bajista.

• Deduplicación: eliminación de registros repetidos probados.
• Agregación de propietarios: agrupación de cuentas por autoridad propietaria respaldada.
• Cobertura: extensión de registros incluidos.
• Residuo: diferencia no asignada, no necesariamente un tenedor.
• Beneficiario: titular subyacente de derechos cuyas tenencias pueden diferir de la autoridad de custodia.
• Vista de sensibilidad: recálculo bajo una política explícitamente diferente.

ILLUSTRATIVE — FIX-P08-07. SIM-SOL-A / MINT-D, d=2, S0. Las filas únicas del objetivo son exhaustivas para el conjunto de contabilidad estándar. Suministro bruto 100,000 significa 1000 tokens mostrados.

La política E excluye solo P1. Una política de sensibilidad separada F también excluye C1; ningún dato de beneficiarios respalda una clasificación a nivel de personas.

OBSERVED en el conjunto de datos: H6 repite H2; H7 tiene el mint equivocado. A es la autoridad propietaria suministrada para dos cuentas de tokens del objetivo.

INFERRED: Los saldos únicos del objetivo suman 100,000 unidades brutas. Los400 tokens de A superan cada cuenta ordinaria individual; su participación en suministro bruto es 40%.

UNKNOWN: Beneficiarios de custodia, identidad humana de A y cualquier control compartido con B.

INSUFFICIENT EVIDENCE: Relaciones de financiación o etiquetas no justifican más fusiones de propietarios. Políticas de exclusión no establecen tenencias circulantes a nivel de personas.

Sumar filas de mint equivocado, contar entradas duplicadas de exportación, agrupar por propietario de programa, clasificar un residuo como una persona, fusionar por etiquetas y ocultar exclusiones tras un porcentaje de tenedor.

Filtre/deduplique la exportación, concilie con suministro y clasifique cuentas únicas y autoridades propietarias. Calcule participación de A bajo suministro total, política E y sensibilidad F. Indique qué clasificación puede llamarse de tenedores humanos.

• Filtre red y mint exactos.
• Deduplique solo repeticiones probadas.
• Normalice unidades brutas.
• Agrupe el campo correcto de propietario.
• Concilie cobertura coherente.
• Publique tanto exclusiones como denominador.
• Mantenga separada la atribución humana.

El análisis de distribución empieza por integridad de datos. Filtrado correcto y agregación de propietarios pueden cambiar clasificaciones sin cambiar suministro.

Cuentas, autoridades propietarias y humanos son unidades diferentes. Los denominadores ajustados son políticas. La conciliación respalda coherencia interna, no identidad ni intención.

Muestre filas de entrada con H6/H7 visiblemente rechazadas por razones distintas; total bruto conciliado 100,000. Clasificaciones de cuentas y propietarios lado a lado. Tres paneles de participación de A40%,57.1429%,66.6667% con denominadores1000/700/600 y nota de custodia desconocida.

Distribución ilustrativa de cuentas y autoridades propietarias; sin atribución de control humano.

Use SVG/HTML deterministas o gráficos con alternativas textuales, azul marino oscuro/negro y cian, azul eléctrico y violeta moderados. Etiquete cada cantidad e incertidumbre. A 390px apile los paneles; la verificación a 768px/escritorio y RTL en árabe sigue siendo trabajo futuro de los recursos. Mantenga los identificadores LTR y los ejes/direcciones de aristas factuales sin cambios. Use solo la marca oficial BlockAssay proporcionada si se añade identidad de marca. Ambos registros son especificaciones, no recursos entregados.

Use RADAR para el propósito educativo acotado de la lección solo si se verifican la compatibilidad de la red, la identidad exacta, los campos y la procedencia. Este contenido no afirma ningún endpoint de runtime ni capacidad de proveedor. Use el conjunto de datos sin conexión incorporado sin acceso de pago. Los datos ausentes siguen siendo desconocidos; no se requiere conexión de cartera, firma de transacción, lanzamiento de tokens ni operación en vivo. El progreso, los pagos y las referencias de Academy nunca cambian la evidencia de Radar. Un Pasaporte de Diagnóstico conserva observaciones y límites, no una predicción de precios ni un certificado de seguridad.

• Solana getTokenLargestAccounts — Veinte cuentas de tokens más grandes; no distribución exhaustiva de titulares humanos. Revisado 2026-09-30.
• Solana getTokenAccountsByOwner — Enumeración por propietario filtrada por mint o programa. Revisado 2026-09-30.
• Solana getTokenSupply — Suministro bruto, decimales y contexto de respuesta RPC; no una definición de suministro circulante. Revisado 2026-09-30.

La documentación respalda mecanismos, no valores de conjuntos ficticios. Todos los ejemplos y registros de ejercicios son material original ILLUSTRATIVE, congelado en este archivo. S0/S1 son etiquetas de contexto sintéticas; observedAt es null porque no se recopiló ninguna medición de un registro de cadena en vivo ni histórico. Vuelva a revisar la documentación y el comportamiento efectivamente desplegado antes de cualquier publicación o integración.

P08-L08 después de revisar el ejercicio resuelto y el cuestionario.