Most people check a token the way they check a restaurant: the reviews, the crowd, the vibe. The chart is the crowd. The Telegram is the reviews. The marketing is the vibe. None of it touches the only question that decides whether you keep your money: what can this contract actually do to you after you have bought in?

The good news is that the answer is knowable, and it does not require you to read Solidity. It requires you to ask five questions in the right order — because the order is what separates a ten-minute check from an afternoon lost in a block explorer. Each step is cheap to run and, on its own, capable of disqualifying a token. This is the sequence we run internally, compressed into something anyone can do with a browser.

Safety is not the absence of red flags. It is the presence of constraints — evidence that the people who deployed the contract cannot quietly change the rules after you arrive.

Step 1 — Confirm the source is verified

Open the contract on the chain's block explorer and check whether the source code is verified. If it is not, you are done; the answer is no. An unverified contract is one whose behaviour you are taking entirely on faith, and faith is not a risk model. Verification is also the gate for everything that follows — you cannot read privileged functions you cannot see.

In the GhostScore model, an unverified contract cannot rise above a hard ceiling on the Security pillar (weight 0.305). It is not a penalty so much as a refusal to certify the uncertifiable.

Step 2 — Read who holds the keys

Find the privileged functions: mint, pause/freeze, blacklist, fee setters, and anything touching upgradeability. The question is never “does this contract have admin functions” — almost all of them do. The question is “what is the worst thing the admin can do, and is that power renounced, time-locked, or held by a multisig?”

A public mint() behind an onlyOwner modifier is not illegal. It is a design choice that concentrates unilateral power in a single address, and the historical record of how that power gets used is not encouraging. Renounced ownership or a timelock turns that same function from a threat into a constraint — which is exactly what Step 1 promised you would be looking for.

Step 3 — Follow the liquidity

Is the liquidity locked? For how long? What fraction of it? And who holds the LP tokens? A lock is a promise, and a promise should be verified by reading its terms, not its headline. “Liquidity locked” in a Telegram bio means nothing until you have seen the lock contract, its unlock date, and the percentage it actually covers. Many locks fail precisely because nobody checked the fine print — a topic we treat at length in our piece on liquidity-lock failure patterns.

Step 4 — Look at the holders and the deployer

Two numbers do most of the work here. The first is top-holder concentration: if the top five wallets control the overwhelming majority of supply, the float is an illusion and the price is whatever those wallets decide it is. The second — and the single most predictive signal in our entire corpus — is not in the contract at all. It is the deployer's track record. A wallet that has shipped four contracts that later collapsed tells you more than any line of code.

Step 5 — Try to sell

Finally, the behavioural test: can you actually sell? A contract you can buy but cannot exit is the oldest trick in the category and still among the most effective, because buying feels like progress and selling always feels like something you will get around to “later.” Simulate a sell before you need to make a real one. Hidden transfer taxes, sell-only blacklists, and honeypot logic all surface here, where it is still free to find them.

The order is the method

None of these five steps is clever in isolation. The discipline is sequence. Verification gates visibility; visibility reveals power; power is constrained or not by the liquidity and ownership picture; and the sell test confirms in behaviour what the code implied in theory. Run them in order and you will disqualify the dangerous majority of tokens in the first two steps, and spend your remaining attention only on the candidates that have earned it.

That is, more or less, what our engine does — in ninety seconds, across six independent intelligence sources, on every chain we support. You can run the same read on any contract address for free.