Token trust score
One score per token, 0 to 100, built from six factors that are each measured from public data and shown with their evidence. Method version 1.0. Projects that disagree with a score can point at the exact factor and the exact input, which is the point.
What the score is and is not
It measures how much you have to trust the people behind a token before you hold it: who can change the ledger, who can create supply, how concentrated the float is, whether you can get out, whether the canisters that hold your balance are healthy, and whether control or code changed recently. It says nothing about whether the project is any good. A perfectly fair meme coin can score A; a serious project run from one developer's principal cannot score above C on control alone.
Factors and points
| Factor | Max points | Measures |
|---|---|---|
| Ledger control | 25 | Who is in the ledger canister's controller list, read from the certified state tree. |
| Mint authority | 15 | Who owns icrc1_minting_account, and what controls that principal. Capped by ledger control, because whoever can upgrade the ledger can mint anyway. |
| Holder concentration | 20 | Share of free float held by the 10 largest accounts, from our own block index, only once the index has reconciled against total supply. |
| Liquidity depth | 15 | Token-side USD depth across DEX pools, depth relative to market cap, and how spread the liquidity is across pools. |
| Canister health | 15 | The worst Lifeline state across the ledger, index, and archives. |
| Upgrade and controller history | 10 | Controller changes, reinstalls, and upgrade frequency from the on-chain change log, weighted by who governs the ledger. |
Ledger control
| Condition | Points |
|---|---|
| NNS controlled | 25 |
| Blackholed (immutable) | 25 |
| SNS DAO controlled | 22 |
| Controlled by an immutable canister | 18 |
| Controlled by another canister | 8 |
| Single principal | 6 |
| Multiple principals | 6 |
NNS and blackholed ledgers score full marks: nobody can change them unilaterally. An SNS ledger can be upgraded, but only by a proposal the token holders vote on. A ledger controlled by an ordinary canister scores by what controls that canister. One or several principals is the weakest case: those keys can do anything, at any time, with no notice.
Mint authority
| Condition | Points |
|---|---|
| No one can mint | 15 |
| Chain-key minter (mints only against deposits) | 15 |
| NNS governed minting | 13 |
| SNS governance (DAO proposal or protocol rewards) | 13 |
| Immutable program | 13 |
| Program controlled by an SNS DAO | 12 |
| Program with changeable code | 5 |
| A principal can mint at will | 0 |
Cap by ledger control: NNS controlled 15, Blackholed (immutable) 15, SNS DAO controlled 13, Controlled by an immutable canister 13, Controlled by another canister 5, Single principal 3, Multiple principals 3.
Holder concentration
| Condition | Points |
|---|---|
| top 10 hold at most 25% of free float | 20 |
| top 10 hold at most 40% of free float | 16 |
| top 10 hold at most 55% of free float | 12 |
| top 10 hold at most 70% of free float | 8 |
| top 10 hold at most 85% of free float | 4 |
| top 10 hold more than 85% of free float | 0 |
Free float excludes protocol-held balances, so a DAO is not penalised for holding its own treasury: SNS treasuries and governance (neuron stakes live in governance subaccounts), SNS swaps, DEX pools, minters, and burn addresses are taken out of both the numerator and the denominator. The exclusions come from the entity labels, and the token's own governance principal is always excluded even without a label. Every excluded account is listed as evidence. This factor is only measured once our block index has replayed the whole ledger and the sum of balances matched icrc1_total_supply exactly; until then it is missing.
Liquidity depth
| Condition | Points |
|---|---|
| token-side depth of at least $1,000,000 | 9 |
| token-side depth of at least $250,000 | 8 |
| token-side depth of at least $100,000 | 7 |
| token-side depth of at least $25,000 | 5 |
| token-side depth of at least $5,000 | 3 |
| token-side depth of at least $1,000 | 1 |
| depth at least 10% of market cap (SNS and community tokens) | 3 |
| depth at least 2% of market cap (SNS and community tokens) | 2 |
| depth at least 0.5% of market cap (SNS and community tokens) | 1 |
| largest pool holds at most 50% of liquidity | 3 |
| largest pool holds at most 80% of liquidity | 2 |
| largest pool holds more than 80% of liquidity (two or more pools) | 1 |
Only pools with ICP, ckBTC, ckETH, ckUSDC, or ckUSDT on one side count, valued from that side. Pools of two illiquid tokens priced against each other do not exist for this purpose.
Canister health
| State | Ledger | Index | Archive |
|---|---|---|---|
| healthy | 15 | 15 | 15 |
| unknown | 10 | 12 | 12 |
| risk | 10 | 11 | 10 |
| low | 6 | 8 | 6 |
| frozen | 0 | 6 | 3 |
| life | 0 | 6 | 4 |
| gone | 0 | 5 | 0 |
The lowest value across the token's canisters is used. A frozen ledger also caps the whole score at 25. An uninstalled ledger is the dead-ledger floor: the grade is DEAD whatever else is true.
Upgrade and controller history
- Controller change that left the ledger under unilateral control: minus 10 within 30 days, minus 6 within 90 days, minus 3 within 365 days.
- Reinstall (wipes balances) within 365 days: minus 5, whoever governs the ledger.
- Code deployments in the last 90 days under unilateral control: 6 or more, minus 6; 3 or more, minus 4; 1 or more, minus 2.
- Under NNS or SNS governance every upgrade went through a proposal: 8 or more in the window, minus 1, otherwise no penalty.
Grades
| Condition | Points |
|---|---|
| A: Strong | 85 and above |
| B: Good | 70 and above |
| C: Fair | 55 and above |
| D: Weak | 40 and above |
| E: Poor | 0 and above |
Insufficient data
A score is only computed when at least 60% of the points possible for the token are measurable from current data. Ledger control is always required. Missing optional factors cap the score: one missing factor caps at 84, two at 69. Data older than its freshness limit counts as missing (minting account 45 days, holders 7 days, liquidity and health 2 days, history 21 days). A token with too little data shows "Insufficient data", never a misleadingly good score, and the panel shows the range the score would land in once the missing factors are measured.
Disputes
Every factor on a token page links to its inputs: the controller list, the minting account, the excluded holders, the pools, the canister pages, the change log. If an input is wrong, the fix is to the input, not to the score: submit a label, point us at the on-chain fact, or explain what we misread through the contact form. If the input is right and you disagree with the weighting, argue the weighting here in public; method changes are versioned and listed below.
Method versions
- 1.0, September 2026: initial method.