Building A Token Scorecard You Fill In Beforehand

A token scorecard is a fixed list of checks with pass conditions written before you look at any specific token. That ordering is the entire method. A card filled in after you have formed a view records the view; a card whose conditions were fixed in advance records the token. Everything below is built from checks you can perform yourself against public chain data.

Why the conditions must come first

The failure mode this template exists to prevent is quiet and universal. You look at a token, form an impression in the first thirty seconds, then assemble evidence. Every threshold you choose afterwards will be chosen, without any dishonesty, at a level the token happens to clear or miss depending on which way you already lean.

Fixing the conditions first costs an hour once. After that the card is reusable and its results are comparable across tokens, which is the property that makes a record worth keeping. The discipline is the same one that makes a verification worth doing: write the definition down before pulling the data, as set out in verifying dashboard numbers.

The four blocks of the scorecard

The card has four blocks matching the four families of evidence. They are ordered from hardest to softest, so that a hard failure early stops you spending an hour on the rest.

• Supply. What exists, who can create more, and who can freeze it. Read from the mint account, essentially no judgement required.
• Liquidity. How much depth exists, where it sits, and whether it can be withdrawn. Read from pool accounts.
• Distribution. Who holds the supply, after classification, and whether the largest holders are structurally related.
• Flow. What the trading looks like: size distribution, timing, turnover and participation shape. The softest block, and last for that reason.

Each block gets its own date and block height, because they go stale at very different rates. Supply findings can stand for weeks. Flow findings can be obsolete in an hour.

The template, line by line

Sixteen lines, four per block. The thresholds below are the desk's defaults and are deliberately conservative; the point is that you fix yours before you start, not that you adopt these.

Scoring: three states, not a number out of ten

Each line gets one of three marks: pass, fail, or unknown. There is no partial credit and no weighting. This is a deliberate restriction, and it resists the two things that ruin scorecards.

Weighting invites you to decide, after seeing the results, that the lines the token failed were the less important ones. A single composite score hides how many lines were unknown, so a card with four passes and twelve unknowns can score identically to one with four passes and twelve fails. Those are completely different situations.

Reporting three counts forces the unknowns into view. In practice the unknown count is the most decision-relevant of the three, because it measures how much of the token you were unable to see rather than how much of it you liked.

Worked example: one completed pass

Notice what the card did not produce: a recommendation. It produced a shape. The flow block in particular describes exactly what deliberately generated activity looks like from the outside, which is a structural observation and not an accusation. Anyone comparing this shape against the parameters a console such as Solana Volume Bot Pro exposes will recognise why uniform sizes and regular intervals appear together, and equally why an ordinary market maker can produce a similar signature for entirely different reasons.

Unknowns are findings, not gaps

The temptation with an unresolvable line is to leave it blank or to assume it passes. Both destroy the card. An unknown is a statement about the token's legibility, and legibility is itself a property worth recording.

• Unknown because the trace ended at a custodial address. Common, expected, and not adverse in itself.
• Unknown because no disclosure exists. A supply allocation with no on-chain lock and no published schedule is a real finding stated as an unknown.
• Unknown because you ran out of time. Record it honestly. This one is recoverable later, and marking it distinguishes it from the two above.
• Unknown because the mechanism is unfamiliar. A pool design or program you have not read. Worth flagging, because an unfamiliar mechanism is where assumptions do damage.

Three different reasons, three different implications, all of which vanish if you write only a dash. The reason field is short and it is the difference between a record and a shrug.

Re-checking and what change means

A scorecard describes a moment. The second pass is where it starts to be worth more than the first, because change carries information that levels do not.

1. Repeat with the same conditions. Never adjust thresholds between passes on the same token; that makes the comparison meaningless.
2. Record the interval and the block height. Both, since block height makes the state read reproducible.
3. Compare line by line, not total by total. Nine passes at both dates can conceal three lines flipping in each direction.
4. Note the direction of each change. Liquidity deepening while concentration falls is a very different trajectory from the reverse at the same score.
5. Resolve one unknown per pass. A modest target that steadily improves the card without turning each pass into a project.

Three passes over a few weeks produce something no dashboard offers: a trajectory measured with a constant instrument. Most token analysis compares different tokens at one moment. Comparing one token against itself over time is both easier and more informative.

The short version, for when there is no time

Sixteen lines is a reasonable pass for a token you are considering seriously. It is far too much for a token you are looking at for ninety seconds, and a template that gets abandoned because it is too long is worse than a shorter one that gets completed. So the card has a four-line short version, drawn from the lines that most often decide the outcome.

1. Mint authority. Revoked or not. One field on one account, and it caps how meaningful everything else can be.
2. Quote-side depth of the deepest pool. Not the reported liquidity total. One number, compared against the size you would actually trade.
3. Classified top-ten concentration. The list with pools and burns removed. This takes five minutes and changes the reading more than any other single check.
4. Average trade size against turnover. Two divisions on figures already displayed, giving you the flow shape without opening a single transaction.

Those four lines catch a large share of what the full card catches, because they are the lines that most often fail. What the short version cannot do is distinguish a token that passes from one that has not been examined. Passing four lines means four things were checked, not that the remaining twelve are fine, and the record should say so explicitly rather than implying a clean result.

There is one hard rule attached to the short version: it is a triage instrument, never a conclusion. Its legitimate use is deciding whether a token is worth the full pass. Recording a short-version result as though it were an assessment is the same error as filling in conditions after the fact, arriving by a different route, and it is more tempting because the four lines feel rigorous on their own.

If the short version produces two or more fails, the honest move is usually to stop rather than to continue into the full card looking for a reason to disagree with what you already found. If it produces four passes, the full card is worth the half hour, because the interesting failures on a token that clears triage tend to sit in the distribution and flow blocks that triage does not reach.

How scorecards fail

• Conditions written after the fact. The original sin, and it produces a document that feels rigorous and contains no independent information.
• Lines you cannot check. Adding team quality or roadmap credibility imports guesswork into the one document whose value is that it contains none.
• Collapsing to a single score. Convenient, comparable, and it deletes the unknown count, which is the field that most affects what you should do next.
• Stale reuse. Quoting a card from three weeks ago as though the flow block still held. Per-block dating exists to prevent exactly this.
• Copying someone else's thresholds without understanding them. Including these. A threshold you cannot justify is a number you will abandon the moment it is inconvenient.

Adapting the template without breaking it

The template is a starting point and should be changed to fit what you actually trade. Three rules keep an adaptation honest.

First, every line must be checkable by you from public data. If a line requires trusting a third party's assertion, it belongs in notes rather than on the card. Second, every threshold must be stated in the card itself, not held in your head, so that a later reader can see the standard the token was measured against. Third, changes to the template apply from the next token onward, never retroactively to cards already completed.

With those three rules, the card stays a record. Without them it drifts back into being an opinion with a table around it, which is the default state of most token analysis and the reason this desk keeps insisting that the definition comes before the data. If you are building the underlying checks for the first time, the metric definitions in the metric index and the classification work in holder count are the two pages that supply most of the raw material.

Questions the desk gets asked