Measuring whether a token’s utility is real.

Abstract

Thousands of tokens launch on Solana every day, and many of them describe themselves as products: AI agents, trading bots, games, data networks. A trader usually has minutes to decide whether those descriptions are true. Utilitest answers one question for any token: is there evidence that the utility it claims actually exists?

Given a contract address, Utilitest collects public evidence from the blockchain, market data, token directories, the project’s website and code, then checks each utility claim against that evidence under a fixed rubric. The output is a tier from S to F with every claim labelled and every source cited. It does not predict price. It measures the distance between what a project says and what can be shown.

1The problem

Utility claims cost nothing to write. A launchpad listing, a landing page and a roadmap can be produced in an afternoon, and the words “live”, “AI-powered” and “revenue share” look the same whether or not anything stands behind them.

Checking them by hand means opening the website, finding the docs, looking for an app, reading the tokenomics, searching for a repository, and checking the contract. That takes far longer than the window in which most decisions about a freshly migrated token are made, so most people skip it. Summaries produced by search engines help, but they mostly restate the project’s own marketing: they report what was claimed, not whether it is true.

Utilitest does that work in under a minute and shows its sources, so a reader can check the checker.

2Principles

• Evidence over assertion. A claim made by the project is never evidence for itself. A tokenomics page proves that a mechanism is documented, not that it runs.
• Every finding cites a source. Each report lists the pages, repositories and data it actually opened.
• Missing is not false. Evidence that could not be found makes a claim unproven. Only evidence that conflicts with a claim makes it contradicted.
• Judge a token by its age. A token launched today cannot have a usage history. New tokens are judged on what can exist on day one (section 5).
• Honest memes are not failures. A token that claims no utility is labelled a pure meme and scored low, without accusation.
• Utility, not investment advice. Reports never comment on price, returns or whether to buy.
• Grades are not for sale. No project can pay to change its tier. A project improves its tier by shipping.

3Evidence pipeline

Each evaluation runs two stages: deterministic collection, then grading. Collection is ordinary code and produces the same evidence pack for the same token at the same moment.

The evidence pack is then graded by a language model working under the fixed rubric in section 4. The model is instructed to treat all project-written text as untrusted data, to label each claim, and to cite the evidence behind each verdict. If no model is reachable, a stricter rules-only evaluation runs instead, and the report states which method produced it.

4Scoring

Four dimensions are scored from 0 to 100 and combined into a weighted score.

Token role is scored as a ladder

• 0–15: no role, or only “utility coming soon” or “ecosystem token”.
• 15–40: a role is named but vague: no amounts, triggers or enforcement.
• 40–70: specific mechanisms are documented: holder tiers with thresholds, staking with what it unlocks, fees paid in the token, buybacks with a stated funding source, governance with real scope.
• 70–100: those mechanisms are observably running, for example burned supply, a staking contract in use, executed buybacks, or a product that requires the token.

Claim verdicts

Verified

The evidence directly shows it.

Partial

Some support, with gaps.

Planned

The project itself presents it as future or tied to a milestone that has not been reached.

Unproven

No evidence either way.

Contradicted

The evidence conflicts with the claim, such as “app is live” beside an app link that says coming soon.

Tiers

One rule overrides the score: a contradicted claim caps the tier at D, however strong the rest of the evidence looks. S is deliberately rare. A scale on which most tokens score well would carry no information.

5Fresh tokens

The most common use of Utilitest is a token that migrated from its bonding curve hours or days ago. Such a token cannot yet show usage, executed buybacks or a track record, and penalising it for that would make every new project look the same.

Tokens under 14 days old are therefore scored without the usage dimension and judged on what can exist at launch:

• whether a working product or demo is available right now;
• whether the code and domain existed before the token, which separates projects that built something from projects that launched a ticker;
• whether the token mechanics are specific and enforceable rather than aspirational;
• whether the team or code can be identified, and whether mint and freeze authority are revoked;
• how concentrated the supply is.

Promises tied to future milestones, such as “buybacks begin at a $5M market cap”, are labelled planned and listed under Watch for on the report. They are neither credited nor held against the token, and a later evaluation shows whether they were kept.

6Integrity

• Untrusted inputs. Websites, descriptions and repositories are written by the projects being graded. The grader treats them as data and ignores any instructions inside them.
• Copycats. Popular tickers are cloned constantly. Directory verification and official links tie a mint to its real project before any reputation is credited to it.
• Safe fetching. The crawler only requests public addresses, caps response sizes and times out slow pages.
• Consistency. Full evaluations are cached for several hours, so everyone looking at a token sees the same report, and the report shows when it was produced.
• Transparency of method. Every report states whether it was a full or quick evaluation, and why.

7$UTEST

A utility checker should pass its own test, so $UTEST has one job, stated plainly: access. Evaluations remain free to try: everyone gets one full evaluation a day. Holding $UTEST raises the limits, in proportion to how much is held.

Holder levels

Limits scale with the amount held:

How holder access works

A holder connects a wallet and signs a message proving ownership. No transaction is sent and no funds move. Utilitest then reads the wallet’s $UTEST balance on-chain and applies the matching level. The balance is re-read every few minutes, so selling after signing drops the level. Sessions last 7 days.

Launch

$UTEST launches on pump.fun with the platform’s standard fixed supply of 1,000,000,000 tokens. The contract address will be published on utilitest’s website and official accounts first; any other address is not $UTEST. Allocation details will be added to this section at launch.

By its own rubric, $UTEST should be expected to grade modestly until holder access is live and in use. That is intended.

8Roadmap

Items are listed by status, not by date. An item moves to Live only when it can be used.

9Limitations

• Utilitest sees only what is public. Products behind logins, private repositories and activity that leaves no public trace show up as unproven.
• X accounts cannot currently be read, so tokens whose only presence is an X account are judged on less evidence.
• Language models can misread evidence. Every verdict cites its source so a reader can check it, and reports state which method produced them.
• An evaluation is a snapshot. Projects change, and a later evaluation may differ.

10Disclaimer

Utilitest evaluations describe evidence of utility. They are not financial advice, a recommendation to buy or sell any asset, or a statement about any token’s value. A token can trade well with an F or poorly with an A. Automated evaluations can be wrong. $UTEST is an access token for a software service, carries no claim on revenue, equity or profit, and may lose all of its market value.