Take a holder snapshot of any Solana token

Solana has no holder list stored anywhere. Balances live in token accounts, each one a separate on-chain account whose first 32 bytes are the mint, the next 32 the owner wallet, and the next 8 the amount as an unsigned 64-bit integer. A snapshot asks an RPC node for every account of the token program whose first 32 bytes match your mint. To keep the response small, this tool requests only the 40 bytes that matter — owner and amount — instead of the full 165-byte account.

One wallet can own several token accounts for the same mint: the associated token account plus any auxiliary accounts created by older wallets or programs. Counting accounts would overstate the holder count, so balances are summed per owner and accounts with a zero balance are dropped. The panel also shows what share of the mint's supply the balances found add up to; 100% means no account was missed. Percentages are calculated with integer maths on raw amounts, so they stay exact even for mints with huge supplies.

The owner column is the authority of the token account, and that is not always a person. Liquidity pools hold their tokens under a program-derived address, so the largest holder of most traded tokens is a Raydium, Orca or Meteora pool authority. Centralised exchanges hold customer balances in a few hot wallets. Burned supply may sit in an incinerator address, and locked team allocations in a vesting program's vault.

This matters for the top-10 concentration figure, which is the share of supply held by the ten largest owners in the filtered list. Left unfiltered, it mixes pools and exchanges with real whales. Paste the pool and exchange addresses into the exclude box and the number becomes meaningful: it then shows how much of the circulating float a handful of wallets could sell. The tool does not guess which addresses to exclude for you, because a wrong guess would silently distort the result.

The CSV export has one row per holder with rank, owner address, amount in whole tokens, percentage of supply and number of token accounts, and opens directly in Excel or Google Sheets. The JSON export adds the mint, program, decimals, raw supply and an ISO timestamp, and keeps raw amounts as strings so that large integers survive parsing in any language. The TXT export is one address per line, the format most allowlist and airdrop tools accept.

Exports always reflect the filters in force, so what you see in the table is what lands in the file. A snapshot is a point-in-time record: balances change with every trade, so note the timestamp, and announce a snapshot time in advance if it decides eligibility for something. Everything is generated in your browser; the list is not uploaded or stored anywhere.

The Send to these holders button passes the filtered list to the SOLTidy multisender in the same browser tab. Leave the total empty and the addresses arrive without amounts, ready for one equal amount per holder. Enter a total and it is split pro-rata: each holder's share equals their balance divided by the sum of the filtered balances, rounded down to the decimals of the asset you plan to send, so the distribution can never exceed the total. Nothing is sent from this page — you still choose the asset, review the cost and sign in the multisender.

The snapshot runs in your browser against a standard RPC method, getProgramAccounts. That works well for tokens with thousands to a few hundred thousand token accounts and typically finishes in under a minute. For the largest mints — USDC, USDT, the biggest memecoins, with millions of accounts — many RPC nodes refuse or time out the request because the response is too large. When that happens the tool says so plainly, and where the RPC provider offers an indexed token-account API it falls back to paging through that index with a live counter, up to a cap of 100,000 accounts. A capped result is labelled as partial.

To send tokens to the holders you exported, the Airdrop Tool takes a snapshot, filters it, allocates amounts and sends, all in one flow.