How to Check a Solana Token Yourself: A Six-Step Rug Pull Check

To check a Solana token yourself, run six free checks in order: confirm the mint address, read the mint and freeze authorities, find its token program, measure liquidity across every pool, reconcile supply, then look at who holds it.

Updated 16 October 2026: this page now opens with the six steps, adds the holder step it always promised, and re-checks every on-chain reading, the supply comparison and the pool count on the day. The original readings from 24 August 2026 stay in place, dated.

Type a token address into a safety scanner and it hands back a score, a colour and a verdict. It takes two seconds and it is genuinely useful. It is also somebody else’s opinion, calculated by somebody else’s rules, on data you never saw.

That is fine right up until the scanner is wrong, and the first sign is usually a token that passed a scan and then did not behave like a token that passes scans. The underlying facts these tools read are public. They cost nothing. Nobody needs permission to look at them.

This site has already published the individual checks across several articles, each one built around a single thing that went wrong on a real token. What it has never published is the order. That turns out to matter more than any individual check, because the checks are not equally valuable and three of them can be skipped entirely once an earlier one fails.

So this is the whole method, start to finish, run live against the token this site follows on 24 August 2026 and re-checked on 16 October 2026, with every step linking to the article that explains why it is there.

The order matters more than the checks

Safety guides often present their checks as a list, which quietly implies the list is a set of equals to be worked through. It is not. The checks differ enormously in how much they cost you and how much they can disqualify, and a good ordering front-loads the cheap disqualifiers.

Two of these steps take one free request each and can end the entire exercise. One of them, step one, regularly ends it. There is no reason to study a token’s liquidity depth carefully before establishing that it is the token you think it is, yet plenty of checklists start with liquidity anyway.

The sequence below is arranged by disqualifying power divided by effort. Run it top to bottom and stop the moment something fails, because a failure at step two makes steps four, five and six irrelevant.

Step one: are you even looking at the right token

This is first because it costs least and everything else depends on it. Names on Solana are not unique. Anybody can mint a token called anything, and the scam that works is not a clever contract, it is a familiar name.

The token this site follows shares its name with an unrelated 2021 BNB Chain project, and with a separate Solana token called Cate Coin that has its own CoinMarketCap page. This token has a CoinMarketCap page too, under the name Catecoin (cate.meme), so having a listing page tells you nothing about which one you are looking at. Three different assets, one word. A reader who searches the name and buys the first result they find has a real chance of buying none of the three on purpose.

The check is not a check of the token. It is a check of your source. Get the mint address from somewhere with something to lose if it is wrong, then confirm every other source agrees with that address rather than with the name. This site’s disambiguation article walks through the specific case in detail, address by address.

If the address you are about to paste came from a direct message, a reply under a viral post, or a search result you did not scrutinise, stop here. Nothing further in this article can protect you from checking the wrong token carefully.

Step two: can anybody still print more, or freeze you

Two fields on the mint account settle this, and both are readable in one free request with no account and no tool. The mint authority is the permission to create new units. The freeze authority is the permission to render your balance untransferable. Read as of 24 August 2026, slot 441,434,663, both are empty on this token, along with the metadata update authority that is easy to forget. Re-read on 16 October 2026, slot 457,682,218, all three are still empty, as revoked authorities have to be.

Empty means revoked, and revoked is permanent. It is worth being precise about what that buys you, because the phrase gets oversold. It means the supply cannot be inflated and your account cannot be frozen. It says nothing whatsoever about whether the price will hold, whether the liquidity is deep, or whether you have approved something on your own wallet that lets a stranger take the tokens. Those are different layers and the first is not evidence about the rest.

The article on what burned liquidity and revoked authorities actually mean covers both fields in full, including the detail that revocation is usually not a decision anybody made but a launchpad default nobody opted out of.

Step three: which of Solana’s two token programs is this

Here is the step that is easiest to get wrong, and it is the reason a one-line wallet audit can return a clean result that means nothing.

Solana does not have a token program. It has two. Solana’s own documentation describes its token basics as “focusing on functionality shared by both the original Token Program and the Token Extension Program (Token 2022)”. They are separate programs at separate addresses, and a request filtered to one of them returns nothing at all from the other. The sets are disjoint, not overlapping.

Which means a guide that hands you a single command filtered to the original program is handing you a check that silently ignores every token held under the newer one. It does not warn you. It returns an empty list, and an empty list reads exactly like all clear.

The reason this can trip up otherwise careful writers is chronological. For years there genuinely was only one token program, so a guide written then was complete when it was published and quietly became incomplete afterwards. Nothing about it broke. The command still runs, still returns valid data, and still formats nicely. It now answers a narrower question than it did when the words around it were written, and no error message will ever tell the reader that.

This is not hypothetical for anybody reading this site. Asked which program owns this token’s mint on 24 August 2026, a mainnet node answers with the Token Extension program, and the account is 366 bytes with metadata stored on the mint itself. The same request against a long-established token like USDC answers with the original program and an 82 byte account. Both answers were the same when re-checked on 16 October 2026. The launchpad’s own API reports the same thing in its token_program field. This token is a Token Extension token, so a check filtered to the original program would never see it.

So the practical rule is to run the account check twice, once against each program, and treat a single-program result as incomplete rather than clean. The article on how wallets actually get drained carries the full command, the measured account counts from a test wallet, and a second trap in the same response: on a healthy account the delegate fields are absent entirely rather than present and null.

Step four: is the liquidity real, and is it still there

Steps one through three are about whether the token can be manipulated at the protocol level. The rest are about whether you can actually get out, which is a different question and often the one that decides how things end.

Liquidity is depth, not size, and the single figure a chart shows you is usually one pool out of many. On 24 August 2026 at 16:17 UTC this token had liquidity spread across at least 100 pools, with the primary pool holding under half of the total. On 16 October 2026, GeckoTerminal’s public pool list for the token ran to more than 100 pools again, and the launch pool alone now held more than 70 percent of the liquidity listed there. Same check, very different answer, which is why it has to be read fresh each time rather than remembered. A reader looking at one pool’s chart and concluding anything about the whole market is reading a fraction and calling it the number.

The honest version of this step is not a number you clear, it is a habit. Find out how many pools exist before quoting a liquidity figure, and check whether the burn everybody cites covers all of them or one of them.

Step five: does the supply story reconcile

Total supply has an on-chain answer that costs one free request. Circulating supply does not, which is why the two numbers are so often quoted interchangeably by sources that should know the difference.

Asked for this token’s supply on 24 August 2026 at slot 441,434,663, a mainnet node returned 964,165,055.940507 tokens against a launch supply of one billion. When this page was first written, most third-party sources still published the round billion, because the round billion was true once and a number that was true once keeps getting republished long after the chain stopped agreeing with it.

Re-checked on 16 October 2026, the picture had moved, but not all the way. A mainnet node returned 964,148,695 tokens. CoinMarketCap’s page for this mint listed a total of 964,170,613 and a circulating figure of 964,165,452.5, both close to the chain but neither equal to it, and the total matches a reading the chain itself passed back in August. Gate’s public currency data for the same mint still gave 1,000,000,000. Three sources, three numbers, and only one of them is a live reading.

It is worth sitting with why that happens, because it is not laziness so much as architecture. Launch supply is written into a listing form once and then sits in a database. The chain figure changes whenever somebody destroys a token, which on this asset has happened thousands of times. One number is a stored field maintained by a person, the other is a live reading maintained by nobody. They diverge quietly, and the stored one is the one that ends up in headlines, screenshots and the summaries an assistant repeats back to you.

If a supply figure and a burn claim are both being quoted, they have to agree with each other and with the chain. This site checked that reconciliation properly by enumerating every individual burn on this token rather than trusting the headline, and the two numbers do agree, though what they agree to is not what the headline implies.

Step six: who holds it, and how much of that is pools

The last step asks how concentrated the ownership is. If a few wallets hold most of the supply, they can sell it all into everybody else’s buying and collapse the price without breaking a single rule. That is the soft version of a rug pull, and it is the one the first five steps cannot see.

Two free sources answer it. A node’s largest-accounts request lists the twenty biggest token accounts, and trackers such as GeckoTerminal publish a holder breakdown by rank. On 16 October 2026 at 14:09 UTC, GeckoTerminal put the top 10 holders of this token at 16.54% of supply, and the deployer wallet at 0.0%. The current figure is on the stats page.

Here is the part that changes how you read that number. A liquidity pool is an address that holds tokens, so it can be counted as one of the biggest holders. When this site logged the top 10 figure every hour for four weeks, it moved with the tokens sitting in pools far more closely than with anything holders did. A rising top 10 share is not, on its own, proof that whales are buying. The measurement, and why the pool’s place in the top ten is a strong inference rather than a confirmed fact, is in what the top 10 holders figure actually measures.

So run this step in two parts. First find the biggest accounts. Then, before drawing any conclusion, work out which of them are pools, exchange wallets or burn addresses rather than people. There is no fixed safe percentage, and the worked example for this token explains why it stopped offering one.

When the node says nothing, that is not a pass

A caveat that belongs in every guide of this kind, and one that is easy to leave out. Public Solana nodes rate limit. Running these checks back to back on the afternoon of 24 August 2026, one request returned neither data nor an error about the token, but this:

{"error":{"code":429,"message":"Too many requests for a specific RPC call"}}

Nothing about that response concerns the token. It concerns the caller. The public node had answered four questions in quick succession and declined to answer a fifth, which is entirely reasonable behaviour for infrastructure that anybody can use without paying or registering. The request that failed was the holder concentration check, the last step in the sequence, and it failed after every earlier step had returned real data. That is precisely the position in which a tired reader is most likely to shrug and call the job done. When this page was re-checked on 16 October 2026, a public mainnet node refused the same holder request with the same 429, so this is not a one-off.

That is not a finding about the token. It is the absence of a finding, and the two look similar enough in a hurry to be dangerous. A script that treats a failed request as an empty result will report a wallet with no delegates, a mint with no authorities and a token with no holders, all of it indistinguishable from good news.

So the rule is that every step in this method needs a positive answer, not the lack of a negative one. If a request fails, retry it slowly or use a different node, and never let silence count as a clean result. The same principle covers scanners: a tool that cannot reach its data source and shows you nothing alarming has told you nothing at all.

What the whole method cannot tell you

Every check here reads a fact that is already recorded. That is the source of the method’s authority and also the boundary of it. None of this is a prediction, and none of it is an opinion about whether a token is a good idea.

A token can pass all six steps cleanly and still fall by most of its value in a week, because nothing in this list measures whether people will keep wanting it. The checks rule out specific mechanical failures. They do not rule out the ordinary one.

Six steps, a handful of free requests, no account and no permission. Run them in that order on any Solana token and you will know more about it than the score on a scanner can tell you, because you will know where each number came from. The worked example for this particular token, with the results filled in, is the five checks article.

Common questions