A Token Holder List Counts Addresses, Not People

A token holder table can prove that a particular onchain account holds a stated balance at a particular observation point. It does not automatically prove how many people are behind that account, why the tokens are there or who receives the economic benefit.

That distinction matters in meme-token research. One person can control several addresses. One exchange address can represent thousands of customers. A liquidity pool can appear near the top of a holder list even though its balance is trading inventory. On Solana, one wallet can own more than one token account for the same mint.

The right reading is therefore “largest recorded balances,” not “largest people.”

What the chain actually records

On an EVM chain, the ERC-20 standard defines balanceOf(address) and requires transfer events. It does not require the token contract to maintain a public, human-readable list of beneficial owners. Explorers and analytics services can reconstruct holder tables from contract state and transfer history, but the resulting rows remain blockchain addresses.

On Solana, the mint identifies the token. A token account stores the mint, its token amount and an owner with authority over that account. The documentation also notes that one wallet may own multiple token accounts for the same mint. A raw list of the largest token accounts can therefore overcount a wallet unless the researcher resolves and aggregates the owner fields correctly.

In both models, a balance is strong evidence about the state recorded by the token system. It is weak evidence about real-world identity unless another source supports the attribution.

Why one large address may represent many holders

Custodial services often pool customer assets. Coinbase’s current United States User Agreement says it may use shared blockchain addresses for assets held on behalf of customers and may keep the customer-level distinction on its own ledger rather than creating a separate onchain address for each customer.

If such an address owns 12 percent of a meme token, the chain can establish the address balance. It cannot show how that 12 percent is divided across the custodian’s customers. Calling the entire row “one whale” would turn a custody address into a person without evidence.

The reverse problem also exists. If one controller splits tokens across 40 fresh wallets, the table may make ownership look less concentrated than it is. Similar timing, common funding or coordinated transfers can justify more investigation, but none of those signals alone proves common control.

Pool balances are not ordinary whale balances

A decentralized-exchange pool holds the assets people trade against. The token balance at the pool contract is inventory governed by the pool’s rules, not a conventional wallet position.

Control of the liquidity is a separate question. Uniswap’s documentation explains that v2 positions are represented by UNI-V2 tokens, while v3 and v4 positions use NFTs. The wallet holding those position assets can remove liquidity or claim fees. Inspecting the meme token’s holder row for a pool does not reveal who controls the corresponding liquidity position.

This is why “the pool is the second-largest holder” and “the creator controls the liquidity” are different claims. The first may be visible in the token balance. The second needs the LP token or position-NFT ownership record, including any lock, burn or transfer evidence.

Labels help, but they remain claims to verify

Explorer and intelligence labels can help classify an address as an exchange, bridge, pool, burn address, treasury or known project wallet. That classification can prevent a serious reading error. It should not erase the underlying evidence.

Record the label provider, observation time and address. Then inspect whether the transaction pattern and contract type fit the label. A service can change an attribution, a project can rotate wallets, and an address can serve more than one role over time.

Do not group addresses simply because they received tokens in the same block or interacted with the same router. Launch platforms and distribution contracts naturally create repeated transaction patterns among unrelated users.

A practical holder-concentration workflow

Use percentages carefully. Excluding a verified pool or burn address can clarify circulating concentration, but the report should show what was excluded and why. A “top ten excluding contracts” figure is not reproducible if the contract classifications are hidden.

For a hypothetical example, suppose the top table shows 28 percent in a pool, 14 percent in a labeled exchange and six fresh wallets with 3 percent each. It would be accurate to report those balances. It would not be accurate to say three people own 60 percent. The pool’s liquidity controller, the exchange’s customer ledger and the six wallets’ possible relationships all require separate evidence.

The defensible conclusion

A holder list is a map of token balances, not a census. Use it to find concentrations worth explaining, then separate address balance, account authority, liquidity control and beneficial ownership. The more serious the allegation, the more important it is to keep those layers apart.

Pair this method with the token-launch checklist, the guide to Solana account permissions, why liquidity is not market cap and the ConstitutionDAO PEOPLE case. The learning hub collects the full sequence.

Sources and image notes

Original AI-assisted educational analysis based on ERC-20, Solana’s token-account documentation, Coinbase’s omnibus-account disclosure and Uniswap’s liquidity-position explanation. The examples are explicitly hypothetical and no identity, wallet cluster or misconduct is asserted. The cover shows a real late nineteenth-century magnifying glass in the Cooper Hewitt collection. The exact Wikimedia Commons rights record marks the object image as free of known copyright restrictions under Public Domain Mark 1.0. It was cropped, resized and converted to responsive WebP files. Corrections: Hello@dev.cooking.