Token-account and owner reconciliation

A holder chart can overcount one authority across multiple token accounts or undercount beneficiaries behind a custody address. The denominator and aggregation rule determine what the chart means.

Distinguish three layers: a chain account address, the program that owns its data, and an authority recorded inside token-account data. In the Solana account model, program ownership is a technical access relation; it is not a person’s name. A token account may designate a wallet authority while being owned at the account-model layer by a token program. Use the relevant program and mint identifiers, not a display symbol, to select compatible records.

Reconcile rows at a fixed observation slot before aggregation. Exclude unrelated mints explicitly; retain zero-balance or closed-account handling in the method. Sum only quantities expressed in the same raw unit. If delegate or multisignature information is unavailable, keep it unavailable rather than assigning a controller. The aggregation key answers a specific question, such as “balance per recorded authority,” not “wealth per person.”

An authority may be a custody service, program-derived address or signing arrangement. Conversely, one person may use many authorities. A concentration chart therefore needs a label explaining both its key and its unknown-beneficiary boundary. Wallet Intelligence may supply technical rows; provider labels must remain attributed and independently unverified unless a separate proof exists.

Program owner: program permitted to modify account data.

Token authority: authority field inside token-account state.

Aggregation key: field used to combine compatible rows.

Beneficial owner: economic person or entity, not established by an address alone.

ILLUSTRATIVE at slot S: token accounts TA1 and TA2 for mint M hold 60 and 40 units with authority W1. TA3 holds 100 M units with authority W2. TA4 holds 900 units of another mint X. All quantities are stipulated whole-unit equivalents. W2 may be custody; no beneficiary data exists. There are three selected accounts, two recorded authorities, and no proven count of humans.

Holder distribution with 50/50 authority bars and a companion account reconciliation table. Show excluded mint X separately; add unknown-beneficiary labels instead of portraits.

Caption: Fictional authority concentration, not a distribution of human investors.

SPECIFICATION_ONLY — the rendered visual has not been produced or independently reviewed.

For the fictional selected mint, total balance is 200 units and W1/W2 each aggregate to 100, or 50%. These are authority shares at slot S.

It proves no human count, independent investors, custody beneficiaries, shared control or current holdings. A technical 50% share is not necessarily one person’s economic exposure.

Summing mint X into M; using program owner as wallet owner; counting accounts as people; assigning custody balances to the custodian’s personal wealth.

Build an authority-level table for M, calculate the denominator and shares, and write a caption that rejects the “three investors” claim. State what W2 needs before beneficiary-level analysis.

• Match exact mint and program.
• Use one stated observation slot.
• Declare the aggregation key and denominator.
• Keep authority, delegate, program owner and human distinct.

Reconciliation yields a technical concentration measure only when identity, mint, unit and time basis remain explicit.

• Account ownership and token authority mean different things.
• Use a compatible mint and unit denominator.
• A holder chart does not count humans.

P10-L04

Use the named ZECOIN tool only as an evidence-reading context. This lesson creates no tool output, account session or entitlement. Offline exercise; do not sign, deploy, approve or fund anything.

• SOL: Solana account model — Account program ownership is distinct from a token-account authority or human identity. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.

ILLUSTRATIVE — entirely fictional offline inputs; no current observation.

null — no real observation

1

null

needs_review