Why Two Solana Bundle Checkers Give You Two Different Numbers

Julio — Sat, 14 Nov 2026 14:42:49 +0000

Paste the same Pump.fun mint into two different bundle checkers and you can get 8% from one and 103% from the other. Both of them read the same blockchain. Both of them are telling you the truth about what they measured — they just measured different things.

I maintain one of these tools — a Solana bundle checker — and most of the support questions I get are some version of "your number disagrees with the other guy's." So here is what the number actually means, where the disagreements come from, and how to tell which answer is the sane one.

What "bundled" means here

A Solana block lasts roughly 400 milliseconds. Using a Jito bundle, whoever launches a token can place the token creation and a batch of buy transactions into that same block. Those buys settle before the token is visible to anyone outside the operation — before it appears in a scanner, before a Telegram bot picks it up, before the chart has a second candle.

So "bundled 14%" means: wallets that bought in the creation block ended up holding 14% of the supply, at the lowest price the token will ever trade at.

Nothing about this is hidden. It is all on-chain. It is just annoying to read, and that is exactly where tools start to diverge.

Divergence 1: the creation transaction is not the bundle

The intuitive approach is to fetch the transaction that minted the token and look at who received tokens in it. On Pump.fun the creator's own buy usually does sit inside that transaction — so this approach returns one buyer and a small, reassuring percentage.

The rest of the bundle is in separate transactions in the same block. Different signatures, often a few slots apart, same 400ms window. A checker that only parses the creation transaction is structurally incapable of seeing them.

If a tool shows you "1 wallet, 3.2%" on a token that visibly dumped from four addresses in the first minute, this is usually why.

Divergence 2: the bonding curve is not a buyer

Pump.fun routes the supply through a bonding curve account. By design that account holds almost the entire token supply right after creation.

Count it as a participant and your percentage goes over 100. This is where the famous "103% bundled" screenshots come from — not a bug in the chain, just a program account being counted as a person.

The naive fix is to filter by size: ignore any holder above 90% of supply. That breaks quietly, because a curve can sit at 85% and sail straight through the filter. The robust fix is to exclude it by address — the curve's address is derivable from the mint, so you already know it before you start counting.

A second filter is worth adding on top: a real buyer spent SOL. Anything that received tokens for free in that block is a program account, a transfer, or an internal routing step — not a participant. That one rule removes most of the garbage addresses that make wallet counts look inflated.

Divergence 3: the denominator

This one is subtle and it is the reason two otherwise-correct tools still disagree by a few percent.

The obvious denominator is the token's current supply. But current supply is not launch supply — a portion gets burned at migration. I checked a token recently whose current supply was 967,870,243 instead of a flat billion. Divide by that and your percentage inflates by about 3.3%, which is enough to push a borderline token over whatever threshold a trader uses.

The other tempting denominator is "total tokens bought in block 0." That one is worse than wrong — it is circular. If the bundle were the only buyer in the block, you would get exactly 100% no matter how much supply they actually took.

Pump.fun mints a flat 1,000,000,000 tokens per launch. That is the denominator. It does not change.

The bonus bug: lookup tables

Worth knowing even if you never write a checker, because it produces convincing nonsense rather than obvious nonsense.

To work out how much SOL each wallet spent, you diff pre- and post-balances per account key. But bundlers use address lookup tables constantly, and addresses loaded through a lookup table do not appear in the transaction's own key list — they arrive separately in the transaction metadata. Reconstruct the key list without them and every index after the first loaded address is off by some amount.

The balances are still real. They are just attributed to the wrong wallets. You get a plausible-looking table where wallet 4 spent what wallet 7 spent, and nothing about the output looks broken.

How to read the result

Two numbers matter and they answer different questions.

Wallet count. One or two wallets in the creation block is unremarkable; snipers exist and they are fast. Ten or twelve wallets acting in the same 400ms is not a coincidence, it is an operation.

Supply share. Under roughly 5% is common even on organic launches. Above 15% spread across several wallets, coordination is the simplest explanation.

Then look at what those wallets did next. Compare each one's current balance against what it bought in block 0. If most of the bundle has already sold, that supply was distributed into the market at a higher price, and somebody on the other side of those trades paid for it.

And bundling itself is a technique, not a verdict. Teams use it defensively too — if you launch without it, snipers take the opening supply instead. What matters is concentration, and what happens after.

Checking a tool's work

Any honest checker should be able to show you the wallet list, not just the percentage. The list is the claim; the percentage is a summary of it. If two tools disagree, compare the lists and the disagreement explains itself within about thirty seconds — one of them is counting the curve, or missing the non-creation transactions, or dividing by current supply.

I run a free one that shows the full table: Solana Bundle Checker. Paste a mint, get the block-0 wallets, their share of supply, and whether they still hold it. No account, no wallet connection — it only reads public chain data.

There is a rug checker next to it for the other half of the question: mint and freeze authority, liquidity, holder concentration.

Every number involved is reproducible from the chain, which is the useful part — you never have to trust the tool, including mine. You just have to be able to read the wallet list.

DEV Community: Julio