Reading a token launch before you buy

Almost everything written about evaluating a token launch is about vibes — the team, the community, the roadmap, whether the chart looks like it is about to do something. That material is unfalsifiable and it is also the easiest thing in the world to manufacture.

This article is about the other kind of check: the ones with an answer. Every item below can be verified by you, from a block explorer, in a few minutes, without trusting anyone's description of the project — including the launchpad's.

1. Is the supply actually fixed?

Start with the token contract, not the marketing. "Fixed supply" is a claim about code, and the code either has a way to create more units or it does not.

On the explorer's contract tab, read the source and look for:

• A mint function of any kind, including one gated behind onlyOwner. Gated is not absent.
• A minter role, or any access-control pattern that can grant one.
• A rebase mechanism, which changes balances without a transfer.
• An owner that is a live address rather than the zero address or a burn address.

A genuinely fixed-supply token mints its entire supply once, in the constructor, and has no minter and no owner. If there is no code path that creates a unit, the supply is fixed by construction rather than by promise, and you do not need to trust anybody's intentions about it.

Then compare the total supply on chain with the number stated on the project's page. A mismatch is not a rounding issue — it is either the wrong contract or an untrue claim, and both are reasons to stop.

2. Who holds what?

Every explorer has a holders tab. Open it and look at the top ten.

What you are looking for is not "a whale exists" — a whale usually exists. You are looking for concentration that makes the float a fiction. If one non-contract address holds 30% of supply, the liquidity you are trading against is a small fraction of what could hit it, and the price you see is a price for a market that has not happened yet.

Two refinements that stop this check giving false alarms:

• Identify the contracts. The pool, the curve and the locker will all appear as large holders, and they should. Confirm each large holder is either a contract you can account for or a wallet you cannot.
• Look for splitting. Ten wallets holding 4% each, all funded from the same address within minutes of each other, is one wallet holding 40% wearing a costume. The funding history is on the explorer, one click into each address.

3. Can the liquidity be pulled?

This is the check that matters most, because it is the one with the largest downside and the one most often answered with a word rather than a fact.

When a launch's liquidity sits in a pool, someone holds the LP position. Whoever holds it can generally withdraw it, and withdrawing it removes the ability of anyone else to sell. So: who holds the LP position, and what can they do with it?

The answers, from worst to best:

• The creator's wallet holds it. They can remove liquidity whenever they like. Nothing else about the project matters until this changes.
• A timelock holds it. Better, and genuinely useful — but a timelock is a promise with an expiry date. Read the unlock timestamp. "Locked" with three days left is a countdown, not a guarantee.
• The LP tokens were burned. The position cannot be withdrawn because nobody holds it. Verify by checking the LP token's balance at the burn address rather than believing a screenshot.
• A contract holds it that has no withdraw function. The strongest form, because it is not a promise at all — it is the absence of a code path. Nobody can remove the liquidity, not the creator, not the platform, not a future governance vote, because no function exists that could.

That last category is what The Hood's graduated launches use: the locker that owns the pool position has no withdraw, no burn, no transfer of the position and no owner. The only action it can ever perform on the position collects accrued fees while moving exactly zero principal. You do not have to take that on faith — read the contract, and note the absence.

4. Can you actually sell?

A token you can buy and cannot sell is the oldest trick in the category, and it survives because almost nobody tests it.

Read the transfer logic. You are looking for anything conditional in the path between two ordinary addresses:

• A blocklist or allowlist that gates transfers.
• A max-transaction or max-wallet limit the owner can set to zero.
• A trading-enabled flag the owner controls.
• A fee-on-transfer that the owner can raise after launch. A 1% sell fee and a 99% sell fee are the same code with a different number in it.

Then check the transaction history for sells that other people have completed — not just buys. On the explorer's token transfers, a healthy market shows both directions from many addresses. All buys and no sells is either a very new launch or a trap, and it costs nothing to find out which.

A note specific to curve-phase launches: a token on a bonding curve may legitimately restrict transfers to the curve itself before graduation, which keeps the curve the only price source until a real pool exists. The distinction to check is whether that lock is automatic and one-way — released once at graduation and never reappliable — or discretionary. Something an owner can toggle is a very different object from something the code releases once and forgets.

5. What has the creator done, not said?

Click the deployer address. You get its entire history for free.

• Has it sold? Token transfers out of the creator wallet into a pool are sells, whatever the accompanying announcement said.
• What did it deploy before? A deployer with six previous tokens, all of which went to zero within a week, has told you what this one is. This is the single highest-signal check on the list and it takes about thirty seconds.
• How is it funded? A wallet freshly funded from a mixer or an exchange withdrawal minutes before deployment is a wallet designed to have no history.
• Do the creator's fees keep flowing after graduation, and to where? Ongoing creator revenue is not a red flag by itself — it can be the thing that keeps a project maintained rather than abandoned at graduation. What matters is that it is disclosed, that it comes from fees rather than from supply, and that you can see the recipient address.

6. Are you even looking at the right contract?

Save the most boring check for last, because it is the one that actually gets people.

An address that resolves on a block explorer is not thereby legitimate. Exploited, abandoned and superseded contracts keep resolving forever — name, symbol, holder list and frequently a price-aggregator listing intact, long after the project moved to a new deployment or died. A search result, a price-site listing and an explorer page are all evidence that a contract exists, and none are evidence that it is the one you mean.

So resolve the address from a source with something at stake:

• The project's own site, over HTTPS, not a link from a chat message.
• The launchpad's registry — here, only projects the factory itself vouches for are shown, which is why an address that is not in the registry gets a "not found" rather than a page.
• Cross-check on a second independent source and compare the full string, not the first and last four characters. Vanity-generated lookalikes match at both ends by design.

And check the chain. The same address can exist on several chains with entirely different code behind it.

What this does and does not buy you

Run all six and you will have ruled out the mechanical ways a launch can be built to take your money: inflatable supply, hidden concentration, pullable liquidity, a one-way door, a creator already leaving, and a wrong address. That is worth having, and most people never do it.

What you will not have established is whether the project is any good. No on-chain check can tell you that, and a token whose contract is impeccable can still go to zero on the merits — most do. The mechanism being sound only means that if you lose money, you lost it to the market rather than to the contract. Treat everything above as a filter that removes obvious disasters, not as a green light.

For what the mechanism looks like when it is designed to be checkable, the piece on what a bonding curve actually is walks through the arithmetic of this platform's own curve and graduation. The security and audit page lists the contracts here, what was reviewed and what is still open. And the risk disclosure is the honest short version of everything that can still go wrong once every box above is ticked.