You Can Check a Solana Token Yourself in About Five Minutes. The Order Matters More Than the Checks.

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 people most likely to notice it is wrong are the ones on the Solana forums complaining that a token 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, with every step linking to the article that explains why it is there.

The order matters more than the checks

Most safety guides 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, and yet that is the order almost every guide teaches.

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 fails most often and costs least. 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 namesake holding a major listing page. 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, including why two major data platforms publish different official links for the same asset.

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 almost nobody checks.

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 most published guides 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 trips up so many 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. The launchpad’s own API reports the same thing in its token_program field. This token is a Token Extension token, as are most tokens launched recently.

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 the one that decides most real outcomes.

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 100 pools, with the primary pool holding under half of the total. 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. Nearly every third-party source still publishes 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.

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.

When the node says nothing, that is not a pass

A caveat that belongs in every guide of this kind and appears in almost none of them. Public Solana nodes rate limit. Running these checks back to back this afternoon, 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.

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, six 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

Do I need to run commands to do any of this? No. Every fact in this article is visible in a block explorer, and the explorer is the right tool if you are checking one token once. The requests matter when you want to check many tokens, or want to be certain the display you are reading has not been filtered by whoever built it.

Is a safety scanner useless, then? Not at all. A scanner is a fast first pass and it catches obvious problems quickly. The argument here is narrower: a scanner’s verdict is a summary, summaries drop detail, and the detail it drops is occasionally the whole story. Use one, then check the two cheap steps yourself.

What is the single most important step if I only do one? Step one. Confirming you have the right mint address prevents the most common loss by a wide margin, and it is the only step where being careful about everything else afterwards makes no difference whatsoever.

Does a revoked mint authority mean a token is safe? It means the supply cannot be inflated. That is one specific guarantee about one specific risk. It is not a statement about liquidity, concentration, the people involved, or what the price will do, and it offers no protection against permissions you approve on your own wallet.

Why does the supply on this site differ from other sites? Because this site reads it from the chain every hour and most sources publish the launch figure. The gap is roughly 35.8 million tokens as of 24 August 2026. The stats page carries the current reading.