Holder distribution and concentration

EN source master · P08-L07 · 45 minutes estimated · needs_review

A token-account leaderboard is not an owner leaderboard, and an owner leaderboard is not a list of humans. Failing to reconcile those layers can hide concentration, double-count balances or attach a pool's inventory to a project team.

This lesson normalizes raw holdings, deduplicates an export and aggregates only supported account owners. P07 focused on launch-specific concentration; here the skill is making the accounting dataset coherent before interpreting it.

Define the unit of analysis

Write whether rows represent token accounts, owner addresses, application positions or humans. Solana token-account enumeration by owner is an owner-scoped query, with a mint or program filter [S08-OWNERS]. It does not enumerate every human beneficiary.

A largest-account query returns twenty token accounts [S08-LARGEST]. It is not a complete owner census. An owner might have several small accounts outside that set, so aggregating only returned rows can understate that owner's total. Mark coverage and do not call a partial export exhaustive.

The fixture is deliberately exhaustive for one mint at one context. That completeness is a supplied educational assumption, not something inferred from a website. In real work, document collection method, filters, pagination and context consistency before claiming full coverage.

Filter before summing

First verify network and mint on every row. A program-wide export can contain several mints. Summing all its rows can produce an impressive but meaningless “total holdings.” Different assets cannot share a supply denominator merely because their decimals match.

Then distinguish raw amounts and displayed units using the verified decimal count. Preserve integer strings. A duplicated row is not a second balance. If the same account appears twice at the same snapshot, deduplicate only when the records are demonstrably identical. Conflicting values require an unresolved conflict or a defined snapshot choice.

Accounts at different contexts must not be casually added. They may represent the same balance before and after a transfer. A merged export is not automatically a snapshot. Pin records to a coherent boundary or label the result as incomplete and time-mixed.

Aggregate supported owners

After filtering and deduplication, group token accounts by the supplied owner authority field for the exact mint. This is an account-level relationship, not a discovery of human identity. Record how the owner field was decoded and verify that it is not the base program-owner field.

An owner authority can represent custody or an application. A custody address can hold balances for many beneficiaries; their distribution is unknown unless records establish it. Conversely, several owner addresses may have one controller, but that is not established by this aggregation alone.

Do not merge owners because they share funding, timing or a label. Those relationships may motivate a separate hypothesis. The denominator and supplied accounting result should remain reproducible without speculative clustering. Unsupported merges can transform a concentration statistic into an accusation.

Reconcile the supply boundary

For a complete standard accounting snapshot, compare filtered raw balances with the independently supplied total. If they reconcile, that supports internal consistency of this dataset. It does not establish authenticity of the fictional values, nor does reconciliation prove there are no special transfer behaviors.

If the sum is smaller, identify unreturned accounts, incompatible contexts or omitted accounting components. If larger, test duplicates, wrong-mint rows and unit mistakes. Never force equality by inserting an unnamed residual that is then treated as a real holder.

A declared residual can be useful in a partial dataset, but it remains an aggregate of unknown composition. It must not be ranked as one human or owner. The exercise's no-residual model makes the correction exact; later investigations may require a separate unresolved-coverage panel.

Keep categories and denominator policies transparent

Pool inventory and custodial balances remain holdings in the raw distribution. An analytical policy may exclude them for a specific question, but it does not remove tokens from supply. Show original and adjusted denominators and give a reason for every exclusion.

“Non-pool owner concentration” and “beneficiary concentration” are different. Excluding a verified pool account can answer the first. Excluding custody without knowing beneficiaries may conceal concentration rather than resolve it. Provide a sensitivity view instead of naming the adjusted number as uniquely correct.

Rank account rows and owner totals separately. An owner can lead the aggregate ranking even when no individual account is the largest. This is the key transfer skill: correct arithmetic applied to the wrong unit still answers the wrong question.

Report limits alongside percentages

Include numerator, denominator, unit of aggregation and snapshot. Avoid a single badge saying “top holder40%” without the owner/account distinction. A stronger sentence says “Owner authority A holds400 displayed units across two accounts,40% of the supplied1000-unit total at S0.”

Nothing in this calculation identifies an insider, forecasts selling or estimates beneficiary wealth. A large owner authority can be observed without knowing human control. The exercise is graded on accounting and scope, not whether the analyst assigns a bullish or bearish verdict.

• Deduplication: removing proven repeated records.
• Owner aggregation: grouping accounts by supported owner authority.
• Coverage: extent of included records.
• Residual: unallocated difference, not necessarily one holder.
• Beneficiary: underlying claimant whose holdings may differ from custody authority.
• Sensitivity view: recalculation under an explicitly different policy.

ILLUSTRATIVE — FIX-P08-07. SIM-SOL-A / MINT-D, d=2, S0. Unique target rows are exhaustive for the standard accounting fixture. Raw supply 100,000 means 1000 displayed tokens.

Policy E excludes P1 only. A separate sensitivity policy F also excludes C1; no beneficiary data support a person-level ranking.

OBSERVED in fixture: H6 repeats H2; H7 has the wrong mint. A is the supplied owner authority for two token accounts of the target.

INFERRED: Unique target balances total 100,000 raw units. A's400 tokens exceed each individual ordinary account; its raw-supply share is 40%.

UNKNOWN: Custody beneficiaries, A's human identity and any shared control with B.

INSUFFICIENT EVIDENCE: Funding relationships or labels cannot justify further owner merges. Exclusion policies do not establish person-level circulating holdings.

Summing wrong-mint rows, counting duplicate export entries, grouping by program owner, ranking a residual as one person, merging on labels and hiding exclusions behind a holder percentage.

Filter/deduplicate the export, reconcile to supply and rank unique accounts and owner authorities. Calculate A's share under total supply, policy E and sensitivity F. State which ranking can be called a human-holder ranking.

• Filter exact network and mint.
• Deduplicate only proven repeats.
• Normalize raw units.
• Group the correct owner field.
• Reconcile coherent coverage.
• Publish both exclusions and denominator.
• Keep human attribution separate.

Distribution analysis starts with dataset integrity. Correct filtering and owner aggregation can change rankings without changing supply.

Accounts, owner authorities and humans are different units. Adjusted denominators are policies. Reconciliation supports internal consistency, not identity or intent.

Show input rows with H6/H7 visibly rejected for distinct reasons; reconciled raw total 100,000. Side-by-side account and owner rankings. Three A-share panels40%,57.1429%,66.6667% with denominators1000/700/600 and custody unknown note.

Illustrative account and owner-authority distribution; no human-control attribution.

Use deterministic SVG/HTML or charts with text alternatives, dark navy/black and restrained cyan, electric blue and violet. Label every quantity and uncertainty. At 390px stack panels; 768px/desktop and Arabic RTL verification remain future asset work. Keep identifiers LTR and factual axes/edge directions unchanged. Use only the official supplied ZECOIN mark if branding is added. Both records are specifications, not delivered assets.

Use RADAR for the lesson's bounded educational purpose only if network support, exact identity, fields and provenance are verified. No runtime endpoint or provider capability is asserted by this content. Use the embedded offline fixture without paid access. Missing data stays unknown; no wallet connection, transaction signature, token launch or live trade is required. Academy progress, payments and referrals never change Radar evidence. A Diagnostic Passport preserves observations and limits, not a price prediction or safety certificate.

• Solana getTokenLargestAccounts — Twenty largest token accounts; not exhaustive human-holder distribution. Checked 2026-09-30.
• Solana getTokenAccountsByOwner — Owner-scoped enumeration filtered by mint or program. Checked 2026-09-30.
• Solana getTokenSupply — Raw supply, decimals and RPC response context; not a circulating-supply definition. Checked 2026-09-30.

Documentation supports mechanisms, not fictional dataset values. All examples and exercise records are original ILLUSTRATIVE material, frozen in this file. S0/S1 are synthetic context labels; observedAt is null because no live or historical ledger measurement was collected. Re-review documentation and actual deployed behavior before any publication or integration.

P08-L08 after the worked exercise and quiz review.