Distribution and Holder Filters, Honestly Read

A holder distribution filter reads how the supply is spread and rejects candidates where too much sits in too few places. It is the most quantitative-looking rule family and the one built on the weakest evidence, because token accounts on Solana are cheap to create and straightforward to fund. The read is still worth running; it just has to be read for what it is, which is a statement about arrangement rather than about independence.

What the read actually measures

Concentration is a proxy for one specific danger: that a small number of parties can deliver more sell pressure than the pool can absorb, at a moment of their choosing. Everything useful about the rule family follows from that sentence, and everything misleading follows from forgetting it.

Notice what the proxy does not measure. It does not measure conviction, and it does not measure independence. Two hundred addresses holding equal amounts are indistinguishable on chain from two hundred addresses controlled by one party, unless you look at where their funding came from. Concentration measures shape, and shape is arrangeable.

It also does not measure danger on its own. A supply concentrated in three accounts is not automatically fatal if those three accounts hold a trivial amount relative to the pool depth. A supply spread across a hundred accounts is not automatically safe if the total outside the pool dwarfs the reserve. The comparison that matters is between what could be sold and what could absorb it.

Reading it from token accounts

On Solana, balances live in token accounts rather than in the wallet address itself. A holder of a given token has a separate account for that token, owned by their wallet, and the mint has no list of its holders. That structure, and the way associated token accounts are derived, is set out in the token program documentation.

The practical consequence for a filter is that a distribution read is an enumeration, not a lookup. You are asking for the largest token accounts for a mint, which is a heavier call than reading a single account and often the most expensive step in the whole pipeline. That is why it belongs last in the rule order: by the time it runs, most candidates should already have been rejected on cheaper grounds.

Three details change the result and are easy to get wrong. The pool's own token account will normally be the largest and must be identified and excluded from concentration arithmetic, since it is depth rather than a competing holder. Accounts with zero balance still exist and should not be counted as holders. And an enumeration returns a truncated list, so the tail is unknown and any statistic that depends on the tail is unreliable.

Effective float, worked through

Total supply is the wrong denominator for a trading decision. The number worth computing is the effective float: the supply that can plausibly arrive as sell pressure. That is total supply, minus the amount in the pool, minus anything provably unable to move.

Here is the arithmetic on invented round numbers, chosen so the relationships stay visible. Suppose a token has a total supply of 1,000,000,000 units. The pool holds 800,000,000 of them, which is the tradeable base side. The deployer wallet holds 120,000,000. The remainder, 80,000,000, is spread across other accounts.

Stated as a share of total supply, twelve percent sounds modest and would pass many published thresholds. Stated as a share of float, sixty percent is the entire story. The same read, the same accounts, two very different verdicts, and only the second one is comparable against pool depth.

Why a clean chart is easy to stage

The uncomfortable part. Creating token accounts and moving balances between them costs a small amount of SOL for rent exemption and transaction fees, and can be done in a single sequence before anyone else knows the token exists. Any distribution that a filter is known to want can be produced deliberately.

The pattern in the middle column is the useful one. Signals that are cheap to arrange carry little information, whatever they look like on a chart. Signals that require a history, a real counterparty or a verifiable on-chain commitment carry more, because faking them costs something. A filter set should weight rules by how expensive they are to defeat rather than by how confident they look.

There is a second-order effect worth noting: a distribution that is too even is itself an oddity. Organic early holdings vary enormously in size. A list of accounts holding nearly identical amounts is a signature of a script, not of a crowd, and some operators treat unnatural evenness as a rejection rather than a pass.

Rules that survive staging

Given the above, the rules worth keeping are the ones that are not satisfied by rearranging balances.

• Float against depth. Compare effective float, valued at the current pool price, against the quote reserve. This is arithmetic about the market, not about the holder list, and it cannot be improved by splitting balances.
• Funding source of the top accounts. If the largest holders were funded from one address shortly before launch, the distribution is presentation. This costs extra reads and changes verdicts more often than any other check here.
• Age of the top accounts. Accounts with a history predating the token cannot be manufactured after the fact. Absence of history is weak evidence; presence of it is comparatively strong.
• Pool share of supply. How much of the supply is in the pool at all. A pool holding a small fraction of supply means most of the token is outside the market and can arrive later.
• Unnatural evenness. Near-identical balances across many accounts is a script signature. Treat it as an adverse signal rather than a neutral one.
• Consistency with the authority read. A distribution rule assumes a fixed denominator. If the mint authority is live, supply can change and every share you computed is provisional.

Notice that the first item is not really a holder rule at all. It is a market rule that happens to use holder data as an input, and it is the most robust thing in the family precisely because it does not depend on believing anything about who the holders are.

Thresholds and their false positives

Every rule here owes you a statement of what it wrongly rejects. Written out, the list is short and clarifying.

The third row is the one to watch. Shared funding paths do occur innocently, particularly when several early participants withdraw from the same venue. The rule is still worth having, and the way to make it honest is to require several accounts to share a funder rather than treating a single coincidence as decisive.

Funding history and deployer context

The funding check is the most informative thing in this article and the least commonly implemented, because it costs the most. It asks where the balance in each large token account came from, which means walking back one hop from each of the top accounts.

What you are looking for is diversity of origin. Several large accounts funded from unrelated addresses with independent histories is a genuinely different picture from several large accounts funded from one address in the same minute. Neither is proof of anything, but the first is expensive to arrange and the second is nearly free.

Deployer context sits alongside it. The account that created the mint has a history, and that history is public. An address whose first ever activity was creating this token is a different proposition from one with months of unrelated behaviour. All of this is inspectable by hand through a public Solana explorer before it is ever automated, which is the right order: check a dozen launches manually, see which signals actually separate them, and only then write the rule.

A worked concentration read

Putting it together on the same invented numbers as before, with a pool price attached so the comparison against depth can be made. Suppose the pool holds 800,000,000 base units against 40 SOL of quote reserve, giving an implied price for the full float.

1. Identify the pool token account and exclude it. Its 800,000,000 units are depth, not a holder position.
2. Compute effective float. Total supply minus pool holding gives 200,000,000 units, or twenty percent of supply.
3. Value the float at the current pool price. With 800,000,000 units against 40 SOL, the float of 200,000,000 units is worth roughly a quarter of the base reserve, which implies a notional value around 10 SOL at the untouched price.
4. Compare that against the quote reserve. A float notionally worth 10 SOL against a 40 SOL reserve is a ratio of one to four; the same float against a 4 SOL reserve would be a completely different position.
5. Look at the largest float holder. The deployer's 120,000,000 units are sixty percent of float, so a single account controls most of the potential sell pressure.
6. Check funding of the next largest accounts. If they share an origin with the deployer, treat the sixty percent as an understatement.
7. Record every number, not just the verdict. Float, ratio, top share and funding result all go into the log so the rule can be argued with later.

Step three is where the actual price impact intuition lives, and it is worth doing slowly because it collapses two rule families into one comparison. The question stops being "is twelve percent too much for one wallet" and becomes "can the reserve absorb the float if it arrives", which is answerable.

What the read cannot tell you

It cannot tell you whether holders are independent, only whether their accounts were funded from different places. It cannot tell you what anyone intends to do. It cannot see agreements made off chain, and it cannot distinguish a patient holder from a fast one. It is a snapshot of arrangement at one instant, and the arrangement can change in the next block.

What it can do is bound one risk with arithmetic: how much potential sell pressure exists relative to the depth available to absorb it. That is a real constraint, it is computable from public data, and it does not depend on trusting anybody. Every other conclusion drawn from a holder chart is softer than it appears.

It is also worth separating this from the mirror-image problem that trading-activity tools address. Distribution analysis asks who could sell into you; scheduled routing through a pool is about placing your own flow through that same depth, which is why Solana volume automation is evaluated on cost per swap and on the evidence it returns rather than on any screening claim. The two disciplines share a pool and share almost nothing else, and a tool that markets itself as doing both usually means it does the routing and reads a public verdict for the screening.

The next page moves past admission entirely and deals with the position once it exists, which is where the quality of every rule on this page finally gets priced.

Questions this page keeps getting