Verifying a token on chain before you trade it

The rule in one paragraph

Start at the mint address, never at the name. Read the authorities and the supply together. Read the token program and, if it is Token-2022, the extension list. Read the metadata state and fetch the URI yourself. Then look at holders and at who controls the pool. Everything else is commentary.

The order matters because each step changes how you read the next one. A supply figure means something different once you know whether the mint authority is live. A clean authority state means something different once you know one wallet holds most of the float. Doing the checks out of order produces the same facts and a worse reading.

Getting the right mint address

Every step below hangs off one string, so the string has to be right. A symbol is not an identifier: the metadata standard does not enforce uniqueness and cannot, so two mints can display the same ticker and neither is invalid. The consequences of starting from the wrong address are total, because every subsequent check will be perfectly accurate about a different token.

Get the address from a source with something to lose if it is wrong, and then confirm it in a second place. A project site served over HTTPS, an established aggregator entry and the pool itself are three independent sources; agreement between two of them is a reasonable bar. Copying an address from a message, an image or a search result is where most of the damage in this area starts.

The order, and why it is that order

Twelve checks, grouped into five passes. The table gives each one, the clean answer for a token presented as fixed supply and permissionless, and what a different answer actually means. It means something different for a token that presents itself differently, which is the point of the third column.

Authorities, decimals and supply

The first pass is one page in any explorer. Both authority fields and the supply are stored in the mint account, so a single lookup answers three of the twelve checks. The discipline is to read all three rather than the first one, because the mint authority field is the one everybody checks and the freeze authority sits directly beside it.

Read supply as arithmetic. Take the raw supply, divide by ten to the power of the decimals value, and compare the result to whatever figure is being published. A mismatch is not automatically sinister; the most common cause is somebody quoting a raw number as a display number. It is, however, always worth resolving before anything else, and the arithmetic is worked through on the decimals and supply note.

Then read the two authority fields together, because they answer different questions. No mint authority means supply cannot grow. No freeze authority means no account can ever be frozen. Each is a permanent guarantee on its own, and neither implies the other, as set out in the authorities note.

Program and extensions

The mint account's owner tells you which token program governs the token. If it is the original SPL Token program, the behaviour is fully described by the fields already read. If it is Token-2022, there is a second list to read, and skipping it makes the whole verification incomplete.

Extensions worth identifying immediately are a permanent delegate, which allows a named address to move or burn tokens from any account indefinitely; a default account state of frozen, which means new holders start unable to transact; a transfer hook, which routes every transfer through a third program that can cause it to fail; a transfer fee, which withholds a proportion of each transfer; and non-transferable, which makes the token permanently unmovable once received. The full set is listed in the Token-2022 documentation.

None of these is a defect. They exist because real designs need them, and several are exactly what a compliant or enterprise token requires. What matters is whether they are present, whether they are explained, and whether the explanation matches how the token is being described to you.

Metadata state

The fourth pass moves to a different program and a different account. Confirm the metadata account exists, read the mutable flag and the update authority, then open the URI in a browser and look at the JSON directly rather than trusting a rendered card.

The check people skip is the last one. Fetching the URI takes ten seconds and answers three questions at once: whether the document resolves at all, whether its name and symbol match the on-chain values, and whether the image is hosted somewhere durable or somewhere that will lapse. A mismatch between on-chain and off-chain names is worth understanding before trading, and a dead link is usually neglect rather than anything worse.

Mutability itself is a fact rather than a verdict. Most tokens are mutable and many well-run ones stay that way deliberately, which is the whole argument of the note on immutable versus updatable metadata. What a reader is entitled to is knowing which state applies and who holds the key.

Holder distribution

Explorers such as Solscan and the Solana Explorer list the largest token accounts for a mint. This is the first check that needs judgement rather than reading, because a large holder can be a treasury, a pool, a bridge, a market maker, an exchange, or one person.

Two things make it tractable. Pool accounts are identifiable, because they belong to an automated market maker program rather than to a wallet, and they should be excluded before you conclude anything about concentration. And unexplained concentration is a fact about what an exit will meet rather than an accusation about anybody: a float held by very few accounts behaves differently when one of them decides to sell, regardless of who they are or what they intend.

• Identify which top accounts are pools or program-owned before reading the distribution at all.
• Check whether large wallets were funded from the same source at the same time, which is visible in their transaction history.
• Treat a published vesting or treasury arrangement as a claim to verify against the accounts, not as a finding.
• Record what you observed rather than what you inferred, so the reading can be repeated later and disagreed with.

Pool and liquidity custody

This is the check that changes outcomes most often and appears in the fewest checklists. Trading happens against a pool, the pool holds the reserves, and the right to withdraw those reserves belongs to whoever holds the liquidity provider tokens. A token with both authorities revoked and immutable metadata can still have every unit of its liquidity withdrawable by one wallet.

Establish three things. Which pool the trading actually happens in, since a pair can exist on several venues with very different depth. Whether the liquidity provider tokens were burnt, which is verifiable as a burn transaction rather than as a claim. And if they are locked rather than burnt, what is holding them, for how long, and whether that arrangement is inspectable on chain rather than asserted in a document.

Depth is the number that matters more than turnover here. A pool that shows a large amount of daily volume and a small reserve is telling you that the same liquidity has been traded repeatedly, and it is the reserve, not the turnover, that your own order will meet.

Burning and locking are not equivalent, and the difference is worth stating plainly. A burn is a completed instruction that destroyed the provider tokens, visible as a transaction, after which nobody can withdraw the underlying reserves. A lock is an arrangement in which somebody or something still holds them under a condition, and the strength of a lock is entirely the strength of the thing enforcing it. A lock held by a program whose code and unlock time you can read is a different object from a lock described in a document, and only the first one is verifiable from the chain.

Reading turnover honestly

Once construction state is settled, the remaining signal on most screens is market activity, and it is the easiest thing on a chart to misread. Turnover is a sum of notional value. It cannot distinguish many participants trading once from a few addresses trading repeatedly, because both produce the same total.

It also has a supply side. Produced market activity is an openly sold category with published parameters and pricing, and a Solana DEX volume bot is a normal part of the venue landscape rather than a secret. Knowing that the category exists is part of reading a turnover figure honestly; treating every busy chart as evidence of a crowd is the error the knowledge prevents.

The practical questions to attach to any turnover figure are the ones any careful measurement has to state anyway: over what window, on which venues, and with what rule for multi-hop routes. A vendor page on how volume campaigns are measured is worth reading for exactly that reason, whatever you think of the category, because it makes the declarations a number needs explicit.

What verification can conclude

It can conclude that specific powers do not exist and that specific fields hold specific values, permanently and checkably. That is a genuinely strong result, and it is available to anyone with an address and a browser.

It cannot conclude that a token is safe, well run, or worth holding. No account field records competence, honesty or what a person will do next week. The chain records state, and state is not intent, which is why this workshop stops at describing state and refuses to convert a set of clean fields into a recommendation.

It also cannot rule out the risks that live outside the token program: a withdrawable pool, a concentrated float, an off-chain document served from a host that can change it, or simply a project that stops. Verification narrows the failure modes to the ones that no account can describe, and the honest end of the procedure is saying which of those remain rather than declaring a pass.

One thing this note deliberately never does is run in the other direction. Nothing here explains how to make any of these twelve checks return a comforting answer that the underlying state does not support. Each check is written so a reader can perform it; there is no version of this page written for the person on the other side of it.

Questions the workshop is asked