Quick answer: We judge crypto research tools by the question they help answer and the proof a reader can inspect. We do not treat an AI label as proof of accuracy. We do not publish a numeric score without dated inputs, fixed weights, and a reproducible calculation.
Prepared by Token Metrics Research Team. Source review date: July 14, 2026. Product terms can change; check the official sources below.
Scope
This method covers on-chain search, entity and address labels, alerts, portfolio views, data queries, and API access. It also covers systems that summarize data with a model. It does not test future returns, trade signals, legal status, or the identity of a wallet owner.
The goal is a sound research trail. A useful tool should help a reader move from a question to evidence, note uncertainty, and check the result.
Evidence hierarchy
Official API docs, method notes, privacy terms, changelogs, and product help come first. Raw chain data comes next for a known test. A product output is an interpretation of that data, not a replacement for it.
A vendor blog can explain a feature. It cannot prove a label is right in every case. We separate “documented,” “observed in a test,” and “verified against a primary record.”
- First: official docs, methods, terms, and change logs.
- Second: saved tests with known addresses, times, and filters.
- Third: raw chain records and other direct evidence.
- Context only: third-party reviews and social posts.
Criteria and tests
Question fit asks whether the tool can answer the named task. Traceability asks whether the reader can see the address, transaction, time, filter, and source behind an output. Coverage checks the relevant chain and field. Control checks permissions, rate limits, exports, retention, and deletion.
For labels, we look for method notes and a way to challenge or cross-check the label. For alerts, we save the rule and compare the event time with the chain. For APIs, we test auth, errors, pagination, limits, and a small known response.
Scoring policy
This cluster uses no numeric product score. The evidence is not a single benchmark with common fixtures and public weights. A precise number would hide the difference between address research, alerts, dashboards, and API work.
We instead use pass, partial, fail, and not tested for each named job. If a later score is added, the page must show the formula, weights, fixture version, date, missing-data rule, and per-product inputs.
Research process
We write the research question first. We then list what evidence would change the answer. We collect primary sources, run a narrow test, save the query or address, and note the date. A second person should be able to follow the trail.
We do not enter private keys, seed phrases, client data, or material nonpublic data. API keys stay in a secret store. A model summary is checked against cited records before use.
Freshness and updates
We review after a change to supported chains, endpoints, labels, alert rules, prices, privacy terms, or access. Official changelogs help, but a new page alone does not prove old behavior still works.
Time-sensitive claims use a date. We avoid “real time,” “always,” and fixed coverage counts unless the source defines and updates them.
Limits and conflicts
On-chain data is public, but entity labels are inferences. One entity may use many addresses. One address may serve many users. Bridges and contracts can make flows hard to read. A tool can be useful and still be wrong.
Token Metrics may have a commercial interest in its own product or partner links. We disclose that fact. It does not count as evidence or add weight.
Worked example
A reader wants to know whether a public address sent funds to an exchange. The reviewer saves the address, chain, time range, and transaction hash. The tool label is one clue. The chain record confirms the transfer. The exchange label still needs a documented basis.
The result should say what is known, what is inferred, and what is not known. It should not turn one transfer into a claim about the owner, motive, or next price move.
Frequently asked questions
Do AI features make a tool more accurate?
Not by themselves. Accuracy needs a defined task, known examples, error review, and a way to trace the output.
Can a wallet label prove identity?
No. Treat it as a research lead unless strong primary evidence supports it.
Why is there no ranking?
The tools serve different jobs and the current evidence does not support one public, reproducible score.
What should I save from a test?
Save the question, address or query, chain, filters, time, output, source links, and any manual check.
Editorial release gate
Before a page ships, an editor checks every product claim against the linked source. A second pass removes stale counts, vague superlatives, and words such as “always,” “instant,” or “guaranteed.” The editor also checks that an example is clearly an example and not a hidden claim about a live account.
The final copy must state what was not tested. It must show why a product may fit one reader and fail another. Links are opened again at release. If a source has moved, the claim is held until the new primary page is found.
A score cannot pass this gate by sounding precise. It needs a public formula and saved inputs. When that proof is absent, “not scored” is the correct result. This rule keeps a clean card design without turning an opinion into a fact.
The release record names the editor, date, source set, and next review trigger. That record is part of the method, not a claim that a named outside advisor approved the work.
What would change this decision
The method should change when a test no longer matches the reader job, a better primary source exists, or the same failure appears across products.
A change is not accepted from a headline alone. Open the primary page, note the date, and repeat the hard case. Keep the old finding until the new result can be checked. If the change affects only one region, plan, chain, or platform, say so rather than rewriting the whole verdict.
Readers should also revisit the choice when their own job changes. A tool selected for a quick view may be wrong for an audit trail. A tool selected for one public address may be wrong for a team API. Fit belongs to the task, so the update record must name the task.
Related guides in this research cluster
Sources checked
Disclosure: Token Metrics may earn compensation when readers use some partner links. Compensation does not decide what we cover. This page gives general educational information, not investment, legal, tax, custody, compliance, or engineering advice.
