Launch readiness

What a holder will be able to check about your token

Everywhere else Evidesa is written for somebody deciding whether to touch a token. This page is written for the other side of that decision: the team that still has time to change what the token's evidence says. Enter the mint, answer the questions nobody outside your project can answer, and the checklist reports what is configured, what is published, and what is still open.

Thirty-three items across authorities, tokenomics, distribution, liquidity, identity, community and monitoring. Fourteen are read from the chain, from the token's metadata, or from a market data provider. The other nineteen are yours to state — they leave no trace this checklist could read, and they are labelled as your statement wherever they appear.

The mint must already exist for the on-chain half of the checklist to be answerable. Nothing you enter here is stored, logged, or placed in a URL, and nothing checks that the token is yours.

Questions only you can answer

Nineteen of the thirty-three checklist items leave no trace on a chain. A lock agreement, a moderation rota and an incident plan are real work and none of them is readable from outside, so they are asked here instead. Every answer you tick is recorded as your statement and checked against nothing — it is labelled that way in the results and in the document, and it is counted in its own column.

An unticked box is recorded as unanswered, never as a no. This surface cannot tell a question you have decided against from one you have not reached yet, so it does not claim to. Either way the item counts as not yet satisfied.

Authority cleanup

An address on its own answers nothing. A holder can already read from the chain that an authority is active; what they cannot read is whether it belongs to the team, to a launchpad, to a market maker, or to somebody who has since left the project.

Tokenomics clarity

Supply is readable from the chain; where it went is not. Without a published allocation, every large account is indistinguishable from an insider account, and the project spends the launch answering the same question one holder at a time.

An allocation that is described as locked but sits in an ordinary wallet is not locked; it is described as locked. The difference is checkable only if the address is published, and only the project can publish it.

A transfer fee changes the amount that arrives at the other end of every transfer, and the configuration can carry a withheld-fee withdraw authority. A holder who discovers the fee by receiving less than they sent has already been surprised by the token.

A transfer hook runs project-controlled code on every transfer and can make transfers fail under conditions only that code knows. Without the program id and its source, the conditions under which this token moves are not knowable to anybody outside the team.

Holder distribution

Unlabelled large holders are the raw material of every concentration claim made about a token, accurate or not. Labels do not lower concentration; they make it possible to argue about the right thing.

Liquidity setup

Withdrawal of the initial pool is the single event holders ask about most, and the claim that it cannot happen is worth exactly as much as the address that proves it. A statement without an address is not checkable by anyone.

Liquidity provided by a market maker under a loan or option agreement behaves differently from liquidity the team funded and intends to leave in place, and the pool itself does not record which it is.

Official links and accountability

Anonymity is an ordinary and often reasonable choice, and it is not the point of this item. The point is that holders assess accountability whether or not the project offers them anything to assess, and a project that says nothing has delegated that assessment to strangers.

Somebody finding a problem with the token, the pool, or the site will report it through whatever channel they can find. Without a stated route, that channel is a public post, and the project learns about the problem at the same time as everybody else.

Community readiness

The minutes after a launch are when impersonation tokens are most effective, because there is nothing authoritative to compare an address against. An address published in advance, in the project's own channel, is that comparison.

Fake support accounts are the most common route to a drained holder wallet, and they arrive in proportion to attention. A channel that gains its moderation policy after the first incident has already paid for it.

Whether an audience grew organically cannot be established from a single snapshot by anyone, including this checklist — the number seen today has no shape without an earlier number to compare it against. A baseline the project records before launch is the only version of that comparison that exists.

Unanswered questions in the first days do not stay unanswered; they are answered by whoever is willing to guess, and those guesses become the project's public record.

Post-launch monitoring

Every authority this checklist asks about can change after the checklist is complete, and a compromised key is discovered by whoever is watching. If nobody on the team is, the discovery is made publicly by somebody else.

Liquidity leaving is visible to everybody at once. The only question is whether the project sees it at the same time as its holders or afterwards, and that determines whether the project's account of what happened arrives first.

Incident disclosure written during an incident is written by people who have not slept, under pressure to say something reassuring before the facts are in. Written beforehand, it commits the project to saying what is known and what is not.

This assessment describes one moment. Authorities can be reassigned, supply minted, and pools drained in a single transaction, and none of those events invalidate a document already published — which is precisely the problem with treating a completed checklist as a standing statement.

This is a checklist, not a certification. It is not an audit, not a review, and not an endorsement. Nobody at Evidesa looks at a submission. A high completion figure is not a statement that a project is trustworthy, that its team is who they say they are, or that the token is worth holding — it is a count of items on a list, and more than half of them are items the project ticks itself. Nothing on this page may be quoted as approval, and completing it changes nothing about how a token is scored in an Evidence Dossier.

It is not a risk score. Completion counts checklist items; a risk category weighs evidence by how far it bears on a holder's downside. The two numbers are built differently and are not comparable, and the thresholds this checklist uses are deliberately its own. An item can be satisfied here while the same fact is flagged in a dossier — that is the checklist asking whether a project still has room to act, and the dossier asking what a holder is exposed to.

An unread item is not a passed item. When a read fails, the item it would have answered counts as not yet satisfied and says so. The alternative — quietly dropping unread items — turns an outage into a finished checklist, because the items that disappear are the ones that were failing. Completion is therefore a floor: it can only rise when the missing evidence comes back and turns out to be satisfied.

Nothing here checks that the token is yours, and nothing is stored. There is no account, no signature, and no record of what was run. Anyone can enter any mint and tick any box, so a result is a worksheet held by whoever produced it and never a claim Evidesa makes about a project to anyone else. The document it produces carries no signature either: any line in it can be edited before it is published, and a reader cannot tell that it has been.

What the evidence half actually covers. Holder distribution is read from the largest token accounts an RPC endpoint returns, not from the full holder set. Liquidity is read from one market data provider's view of the venues it knows about. Authority items decode SPL Token multisig accounts only — a Squads or governance account is reported as unread rather than guessed at, and a multisig threshold is a statement about how many signatures the program requires, not about how many people hold the keys.

Evidesa is not financial advice and does not certify safety.