This post explains why raw holder lists mislead, how Rugsight computes holder concentration instead, and the cases where even a careful method can't give you a number.

Token accounts are not holders

On Solana, a wallet doesn't hold tokens directly. Tokens live in token accounts, and each token account has an owner. The RPC call most tools start from, getTokenLargestAccounts, returns the 20 largest token accounts for a mint, not the 20 largest owners.

That causes two problems:

1. One owner can have several token accounts. Usually a wallet has one associated token account per mint, but nothing stops it from holding more. Counting accounts can split one whale into several smaller "holders".
2. Many of the largest accounts are owned by programs, not people. That's the bigger problem.

What sits at the top of a typical list

For a token that trades on a DEX, the largest token accounts usually include:

• The liquidity pool's vault. An AMM pool holds one side of the pair in a token account owned by the pool program (or a PDA derived from it). On a thin token, that vault can hold 30% to 80% of the supply. Those tokens are the market; they're what buyers buy from.
• The pump.fun bonding curve. Before a pump.fun token graduates, most of its supply sits in the bonding-curve account. Calling that "one holder owns 80%" is wrong.
• Other program-owned accounts: lockers, vesting contracts, staking vaults, bridges.
• Burn and dead addresses. Tokens sent to an address nobody controls are gone in practice, even if they still count in the supply.

None of those can dump on you the way a single wallet can. Count them and nearly every new token looks like 90% concentration. Then the metric tells you nothing.

How Rugsight measures it

For each mint we:

1. Read the largest token accounts (getTokenLargestAccounts) and the total supply.
2. Resolve the owner of each of those accounts.
3. Classify each owner. If it's a known burn address, it's burn. If it's one of the token's DEX pool addresses, it's a pool. If the owner account belongs to the System Program, it's a normal wallet. Anything else (a program-derived address such as a bonding curve, vault or locker) is a program. If we can't resolve an owner, we count it as a wallet, so errors push the number up, not down.
4. Merge accounts that belong to the same owner.
5. Report top-1 wallet % and top-10 wallet % using real wallets only, and list what we excluded and why.

The full report shows the top-20 breakdown with each entry labeled (wallet, pool, program, burn), so you can check our classification instead of trusting a single number.

Scoring then uses the wallet-only numbers: over 80% in the top 10 wallets costs 30 points, over 50% costs 20, over 30% costs 10, and any single wallet over 20% costs another 15.

Where it still breaks

Huge tokens. For a mint with millions of token accounts, getTokenLargestAccounts has to rank all of them. On USDC, USDT and wrapped SOL (each with more than 10 million accounts), public and free-tier RPC nodes refuse or time out. There's no free, reliable way to get that list, so for those tokens Rugsight says plainly that holder concentration is unavailable and leaves it out of the score, instead of guessing.

Overloaded indexes. Even for mid-size tokens like BONK or WIF, an RPC provider sometimes answers "index overloaded". We retry with backoff, fall back to another RPC, and as a last resort use the last successful holder snapshot (up to 7 days old), marked as cached in the report.

Wallets that look like wallets. A team can split its supply across 50 fresh wallets. Each is a real wallet on-chain, so it counts as a wallet, but no single one looks large. Holder concentration alone can't catch that; you need funding-graph analysis (who funded these wallets?), which bubble-map tools do and Rugsight does not yet.

Centralized exchange wallets. An exchange hot wallet holding 15% of a listed token is technically one wallet, but it represents thousands of customers. We don't relabel exchange wallets yet, so large listed tokens can look a bit more concentrated than they are.

What to take away

• Treat any "top 10 = 90%" number with suspicion until you know what's in the top 10.
• Look for the pool and bonding-curve accounts and set them aside.
• Concentration in real wallets over 50%, or one wallet over 20%, is the signal worth worrying about.
• Even a clean distribution doesn't rule out a coordinated group of wallets.

You can see the wallet-only numbers for any token on its Rugsight page: try BONK, browse new tokens, or read the full checklist in how to check a Solana token for rug-pull risk. The free sample report shows the labeled top-20 breakdown.

Automated technical analysis of public on-chain data. Not financial advice.

Originally published on the Rugsight blog.

Drafted with AI assistance and reviewed by the author.

This post covers how the flow works on Solana, what we chose, and the things that tripped us up. It's written for developers; there's nothing to buy here.

The flow

1. The agent calls GET /api/v1/report?mint=<mint> with no payment.
2. The server returns HTTP 402. For x402 v2, the payment requirements go in a base64 JSON PAYMENT-REQUIRED header; we also return the v1 JSON body for older clients. The requirements say: scheme exact, network Solana mainnet, asset USDC, amount 30000 (0.03 USDC in 6-decimal units), and the address to pay.
3. The client builds a Solana transaction that transfers exactly that amount of USDC, signs it as the payer, and resends the request with the payload in a PAYMENT-SIGNATURE (v2) or X-PAYMENT header.
4. The server asks a facilitator to /verify the payload.
5. If it's valid, the server builds the report.
6. Only then does it ask the facilitator to /settle, which submits the transaction on-chain.
7. The server returns 200 with the report and a PAYMENT-RESPONSE receipt header.

The order of steps 5 and 6 matters. If the report can't be built (an RPC outage, an invalid mint), we never settle, so the agent is never charged for an error. Verify first, do the work, settle last.

Why a facilitator

On Solana, the facilitator can also be the fee payer: it co-signs and pays the SOL network fee, so the agent's wallet only needs USDC. That removes the most common onboarding failure ("you need SOL for gas"). We use the PayAI facilitator; its fee-payer address is part of the payment requirements so the client can build the transaction correctly.

The facilitator also checks things you don't want to re-implement: that the transfer instruction matches the requirements, that the amount and mint are right, and that the transaction will simulate.

Things that went wrong

The pay-to token account didn't exist. On Solana, USDC goes to the treasury's associated token account (ATA), not the wallet itself. Our treasury had never held USDC, so its ATA didn't exist, and every payment failed at simulation. The fix is just to create the account (send any amount of USDC to it once), but nothing in the 402 response tells a client why it failed. We now expose x402PayToReady in /api/health, so the problem shows up before a customer finds it.

Local pre-checks save facilitator calls. Before calling /verify we decode the transaction and check the obvious things ourselves: the right program, mint, destination and amount. Garbage payloads get a fast 402 with a clear error instead of a round trip.

v1 and v2 clients both exist in the wild. Supporting both headers and both body formats cost a few dozen lines and avoided a lot of "it doesn't work with my client" debugging.

Discovery is half the product. An API that agents can pay for is useless if agents can't find it. We publish /.well-known/x402, an OpenAPI document with the price on each paid route, llms.txt, and an MCP server with a free tool and a paid tool. The 402 response also carries a bazaar extension with input and output schemas, which facilitator directories use to list services after their first settled payment.

Pricing

0.03 USDC per report is low enough that an agent can check every token it touches, and high enough to cover the RPC and market-data calls behind a full report. The basic score (grade, verdict, flag codes) stays free at /api/score/<mint>, so an agent can triage for free and only pay when it needs the detail.

Try it

• Free score: curl https://rugsight.rugsight.workers.dev/api/score/DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263
• See the 402: curl -i "https://rugsight.rugsight.workers.dev/api/v1/report?mint=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"
• Clients: npm i rugsight, pip install rugsight, and Vercel AI SDK tools. The source is on GitHub (MIT).

If you're building an agent that trades or recommends Solana tokens, the docs show how to plug in a payment-aware fetch.

Rugsight is an automated technical tool. Not financial advice.

Originally published on the Rugsight blog.

Drafted with AI assistance and reviewed by the author.