Insider clusters: connected wallets are a lead, not a verdict

The short answer

An insider cluster is a working hypothesis that several addresses are controlled by, allocated to, or coordinating with one economically connected group. The risk is hidden supply control: a holder table can look distributed while one entity has enough inventory to shape price, create misleading activity, or exit into other traders. Onchain links establish transactions and timing. Ownership and intent still require inference.

An address is not automatically a person or an entity

A wallet address can be controlled by one person, a team, a multisig, an exchange, a bot, a program, or a service acting for many users. One person can control many addresses. That makes the raw top-holder list factual at the address level but incomplete at the economic-controller level.

Begin with classification, not clustering. Label pools, lockers, burns, programs, exchanges, bridges, launchpads, treasury, team, and unknowns only when the evidence supports the label. Preserve the original address-level percentage before making any exclusions or entity adjustments.

Use an evidence ladder instead of a binary insider label

• Observed: exact token or SOL transfers, balances, signer roles, instruction sequence, pool interactions, and timestamps visible onchain.
• Strongly linked: repeated direct funding and consolidation, common control transactions, or a traceable distribution-and-return pattern with weak service explanations.
• Consistent with coordination: common funders, tight launch timing, synchronized trades, shared destinations, or repeated behavior across tokens.
• Unresolved: a visual edge, one shared venue, one timing overlap, or an unlabeled intermediary without enough context.

Keep those levels separate in the final write-up. “Wallet A sent SOL to Wallet B” is an observation. “A controls B” is a conclusion whose confidence depends on the whole pattern.

Transfer graphs show relationships selected by the tool

Bubblemaps V2 says its default view represents the top 250 current holders, sized by balance, with links for detected onchain transfers. It can hide contracts and exchanges by default, restrict high-volume supernodes, and add nonholder intermediaries through Magic Nodes. The visible graph is therefore useful and deliberately incomplete.

Click every material edge. Record asset, direction, amount, date, transaction, and whether it occurred before launch. A transfer could represent payroll, vesting, an exchange withdrawal, an OTC deal, gas funding, market-making inventory, a launch service, or common control. The tool's independent guide covers map scope, Magic Nodes, Time Nodes, and historical reconstruction.

Launch state often contains evidence the current holder list lost

Current holders omit wallets that sold, emptied, consolidated, or fell below the visible cutoff. Reconstruct the earliest available distribution, the event under review, and the current state. Track initial allocations, funding before the first buy, bundled transactions, dispersal, pool creation, sells, and where proceeds consolidate.

Historical views can expose an early cluster that disappeared after distribution. They can also inherit present-day labels or omit addresses outside the historical top-holder scope. Save the map date, computation time, filters, exports, and the underlying explorer transactions.

Report a range, not a fake-precision cluster percentage

Build three concentration views: raw address concentration, known-entity-adjusted concentration, and a hypothesis range that aggregates strongly linked wallets. Keep merely correlated addresses outside the core figure or show them as a separate upper-bound scenario.

State what supply base you used—total, circulating, or tradable—and why pools, burns, lockers, exchanges, or program accounts were included or excluded. A polished “insider percentage” without address list, method, time, and confidence is not reproducible evidence.

Behavior can strengthen a funding link or expose its weakness

Compare acquisition time, token size, transaction construction, priority and tip behavior, holding period, transfer destinations, sells, and later reuse. Repeated patterns across launches are more informative than one visually dense map. Conversely, different histories and independent activity can weaken a common- controller hypothesis even when two wallets once transferred funds.

Do not infer insider status merely from profit, early entry, or fast execution. Snipers and independent bots can behave similarly. The question is whether the complete flow supports privileged allocation or shared economic control.

A defensible cluster workflow

1. Fix the scope. Save chain, mint, supply definition, block time, map time, holder cutoff, and the event being investigated.
2. Classify addresses. Separate pools, programs, services, known project wallets, and unknown holders before calculating concentration.
3. Reconstruct launch. Trace minting, allocation, funding, early buys, bundles, distribution, and pool creation from the earliest state.
4. Verify every edge. Open transactions and record asset, direction, amount, time, signers, instructions, and plausible service roles.
5. Test behavior. Compare later transfers, sells, consolidation, timing, and reuse across tokens for corroboration or contradiction.
6. Publish confidence. Show observed facts, strong links, correlated leads, alternatives, and raw versus entity-adjusted supply ranges.

What belongs in the journal

Record the mint, supply base and snapshot time, holder export, address classifications, raw concentration, every proposed entity and confidence, transfer hashes, funding origins, timing windows, launch actions, sell and consolidation flows, service labels, alternative explanations, and adjusted concentration range. Keep screenshots as illustrations, not substitutes for the address and transaction list.

Primary sources