Solana Token Holder Snapshot

Neither. This reads public on-chain data and signs nothing, so there is no wallet connection, no platform fee and no transaction. You can snapshot any token, including one you have nothing to do with.

Because it is usually the liquidity pool, not a person. When a token is pooled, those tokens sit in an account owned by the DEX program, and it will typically be the largest single line in any snapshot. Exchange wallets are the other common case: one address holding on behalf of thousands of people.

No, and this matters if you are planning a reward. One person can hold many wallets and one wallet can hold on behalf of many people. A snapshot counts addresses, which is the only thing the chain actually knows. Any conclusion about people is something you are adding on top.

It is true for the instant you took it and starts drifting immediately, because balances change every block. If a snapshot is going to decide who gets paid, take it as close as you can to the moment you decide and say publicly which moment you used.

Yes, that is exactly what the format is for. The CSV comes out as one row per wallet with its balance, which is the input shape the Multisender parses. You will normally want to edit the amounts column to whatever you are actually distributing.

By arithmetic rather than by scanning far enough. No EVM chain will list a token's holders, so the addresses are rebuilt from transfer history, which is always a window of blocks rather than the whole story. But every token that exists is in somebody's balance, so if the balances found add up to the total supply there is nothing left over for a missing holder to be holding. When that adds up the tool says the list is everyone, and it is right whatever the window covered. When it does not, it tells you exactly what percentage of supply is still unaccounted for and offers to keep scanning.

Because an ERC-20 balance is an entry in the token's own storage and nothing will iterate it: the only way to learn a balance is to ask for one address at a time. Most chains carry a Multicall3 contract that lets thousands of those questions travel in a single request, which is what makes this quick. On a chain without one the reads go one by one, and past a few hundred addresses that is slow enough to be rate-limited part way through. It stops and says so rather than handing you a list that quietly stops in the middle.

Because those two addresses really do hold the token and really cannot ever send it: nobody has a key for the zero address or for the 0x…dEaD address. They are kept in the list and in the CSV because the tokens sitting there are part of the supply, and leaving them out would break the check that proves the list is complete. The flag is there so you can drop them before an airdrop rather than paying them. Liquidity pools and exchanges are not labelled, because which address is a pool is a guess and a wrong label is worse than none.

No, this reads fungible token holders, and on an EVM chain it will find nothing at all rather than guess: an ERC-721 transfer looks almost identical to an ERC-20 one in the logs, so those are dropped on purpose instead of being read as balances that would in fact be token ids. For a Solana collection, use the NFT Holder Snapshot, which counts how many NFTs each wallet holds, or the NFT Hashlist for the mint addresses themselves.