Methodology

ChainSift · Last updated: 19 August 2026

This page explains exactly how a ChainSift Score is calculated, where the data comes from, what a machine does, what a human does, and where the method is weak. If any of it is unclear, write to [email protected].

The score

A ChainSift Score is a number from 0 to 100. It is the sum of five categories worth 20 points each.

A score is not a verdict. It is a summary of how many risk signals we found and how serious they are. Every point is traceable to a specific finding, with a source and a date.

1. Team & Transparency 20 points

Signal	Points
Identities verifiable and consistent across sources	0–8
Verifiable track record in previous work	0–6
Public presence and responsiveness	0–6

An anonymous team is not automatically a fail. Many legitimate crypto projects are pseudonymous — so are we. What costs points is unverifiable claims: names and photographs that lead nowhere, or a history that cannot be confirmed.

2. Tokenomics 20 points

Signal	Points
Supply and emission clearly documented	0–5
Holder concentration	0–6
Unlock and vesting schedule disclosed	0–5
Token has a stated function beyond speculation	0–4

3. Technology 20 points

Signal	Points
Contract source verified on the block explorer	0–4
Independent security audit exists and is published	0–5
Repository activity consistent with claims	0–6
Product stage matches what is being promised	0–5

4. Red Flags 20 points

Signal	Points
Contract mechanics: honeypot, mint, pause, blacklist, transfer tax	0–8
Copied documentation or website content	0–4
Claims that cannot be true as stated	0–4
Signals of manufactured social activity	0–4

5. Legal 20 points

Signal	Points
Operating entity disclosed	0–6
Jurisdiction identified	0–4
Terms of service and privacy policy present and specific	0–4
Regulatory posture consistent with what is being offered	0–6

The arithmetic is not left to a language model. The model scores each signal; our code sums the signals into a category, sums the categories into the score, and derives the risk level from it. A model that miscounts cannot inflate a score, because it never gets to decide the total.

Where the data comes from

We do not run our own blockchain infrastructure. We orchestrate public sources and add interpretation on top. This list is what we use today, not what we intend to use:

The project's own website, documentation and social accounts — claims, team information, legal disclosures. This is the primary input for a written report: we fetch the pages and assess what they do and do not say.
GoPlus Security API — contract mechanics read directly from the chain: honeypot detection, tax parameters, mint, pause and blacklist functions, upgradeable proxies, ownership, holder concentration, liquidity locks. This runs in our Discord bot and, since 19 August 2026, inside written reports as well.

Where the two sources disagree, the chain wins. Three sub-signals — contract mechanics, holder concentration and source verification — are calculated directly from contract data, not inferred from the project's text. If a site says "liquidity locked forever" and the chain says otherwise, the score reflects the chain, and the report prints both.

This requires a contract address. Supply one with your order, or we will try to find it on the project's site. If no contract can be identified, the report says so in plain language and those three signals are assessed from published material only — a materially weaker report, and you should know when you are reading one.

Where a source disagrees with another, we say so on the report rather than silently picking one.

What is automated and what is not

Automated, in seconds: contract mechanics, holder concentration, contract verification status, and the presence or absence of documents. These are read from the chain and scored by fixed rules — no language model is involved in deciding them, so they are reproducible: the same contract state always yields the same points.

Language model assisted: reading documentation, comparing claims against observable facts, detecting copied text, summarising findings. A language model is good at reading a lot quickly and bad at being certain. Everything it produces is attached to a source you can open yourself — and, as noted above, it does not control the arithmetic.

Human reviewed: only in reports marked human-verified. In those, a person checks each finding against its source before publication. Automatic reports are labelled as automatic. We do not blur the difference.

Freshness

A score is a photograph, not a promise. A project that scores 78 today can score 40 next week if the owner enables minting or liquidity unlocks.

Every score carries the date it was produced.
When we re-check a project, the previous score stays visible along with what changed and why.
Contracts under monitoring are re-checked automatically, and score changes are recorded.

The history is the point. A single number is easy to produce; a year of dated observations is not.

Where this method is weak

We would rather state these than have you discover them:

New projects have thin data. A project two weeks old has no track record to verify. It will tend to score lower than it may deserve.
Off-chain claims are hard to disprove. We can confirm that a partnership is not documented. We usually cannot prove it does not exist.
Sophisticated operators pass mechanical checks. Clean code and a patient timeline defeat every automated scanner, including ours. This is exactly why we score team and legal separately, but it is not a solved problem.
We can be wrong. When we are, we publish the correction with a date and leave the original visible.

What the score is not

Not a security audit. Not investment advice. Not a guarantee. A high score means fewer risk signals were found on the date shown — nothing more.