About these pages: they explain Hodler Suite for its customers. Internal details, such as server paths, keys and network addresses, are deliberately left out.

How scores are calculated¶

This page gives the arithmetic behind every number in a report, step by step. Each step has its formula, a short worked example and what it means in practice. If you only want the short version, skip to In plain words at the end.

The same formulas and constants run for every customer and every plan. What a plan changes is which data sources are queried and which parts of the result you see (see Plans and data).

The pipeline at a glance¶

1. Each of the 16 components gets a quality score from 1 to 10, where higher is better.
2. Each quality score is turned into a component risk from 0 to 10, where higher is riskier.
3. The component risks are weighted into a base risk from 0 to 100.
4. The points of any red flags raised are added, up to 50.
5. Market-structure adjustments for very few holders, thin trading or a very small market cap are added.
6. The result is the risk score, from 0 to 150, and its band.

Two more figures are calculated alongside: the four category scores (0 to 100, higher is better) and confidence (how much of the expected data arrived).

Step 1: Component quality scores¶

Every component starts from rules that read the token's data: whether the contract's source code is verified, how many wallets hold the token, how much it trades, whether a screening service lists the address, and so on. Each rule adds or removes a fixed number of points from a starting value, which gives the component's rule score $h$, between 1 and 10.

For most components the rule score is then blended with the average reading of the specialised data services that cover that component:

where $b_i$ is the component's blend share and ${\overline{A}}_i$ is the weighted average of the readings the services produced:

Each service $p$ has a fixed weight $w_p$ for each component it informs. The sums run only over the services that returned a reading for this token, so the weights always add up over the services that actually answered. "Clamp" keeps the result between 1 and 10.

Market-data services (prices, market cap, volume) feed the rules, but their readings never enter the average: knowing that a token has a price says nothing about its risk.

Worked example. A component has a rule score of 8.0, a blend share of 0.50, and two services answered: one reading 6.0 with weight 0.20 and one reading 4.0 with weight 0.10. The average is (6.0 × 0.20 + 4.0 × 0.10) ÷ 0.30 = 5.33, and the quality score is 0.5 × 8.0 + 0.5 × 5.33 = 6.67.

Readings from screening services¶

Screening services (sanctions lists, scam databases, honeypot detectors and similar) usually answer with a risk value. It is converted to the 1-to-10 quality scale in three moves:

1. Scale: an answer on a 0-to-100 scale is divided by 10, one on a 0-to-1,000 scale by 100, so every answer lies between 1 and 10.

2. Invert, so that higher means better:
   $$q=11-x$$

3. Shrink toward the middle by a shrink factor $f_p$, so that no single service can swing a component on its own. The factor is 0.30 for most screening services and 0.35 for TRM Labs, Lukka and OpenSanctions:
   $$q_p=5+(q-5)·f_p$$

A factor of 0.30 maps the full 1-to-10 range onto 3.8 to 6.5.

A decisive finding is not shrunk away. It caps the service's reading instead:

Worked example. A screening service rates an address 2 out of 10 for risk. Inverted, that is 11 − 2 = 9; shrunk with a factor of 0.30, it becomes 5 + (9 − 5) × 0.30 = 6.2. The same service reporting a sanctions match would give 1.1 instead, however the rest of its answer reads.

Components with their own screening blend¶

Four components also blend their screening readings into the rule score itself, before the main blend described above, so that the specialised evidence weighs more where it matters most:

Adjustments for the kind of token¶

Two kinds of token lose quality points on specific components after the blend, never falling below 1.0:

• A speculative memecoin loses 2.6 on industry impact, 2.2 on business model, 2.0 on technology and on team expertise, 1.4 on AML and on compliance data, and 1.0 on ESG impact.
• A wrapped token loses 1.0 on code security and on compliance data, and 0.8 on business model.

When data is missing¶

Missing data is not treated as neutral. Each component starts from a cautious value between 3 and 5, and evidence has to be found to raise it. The social component, for example, starts at 3 and loses another 0.5 when at most one social or news source has anything on the token, so a token with no social evidence scores 2.5 there. A value of exactly 5.0 appears only if a component's calculation fails.

Step 2: From quality to risk¶

Each quality score $q_i$ is turned around into a component risk $r_i$ on a 0-to-10 scale:

The best possible quality gives no risk, the worst gives the maximum, and everything in between is a straight line.

Step 3: The weighted base risk¶

The 16 component risks are combined with fixed weights $w_i$ into the base risk $B$, on a 0-to-100 scale:

The weights add up to 1.00:

By category, Market carries 0.33 of the weight, Behavior 0.32, Contract 0.28 and Liquidity 0.07. The weights are the same in EU mode and in Global mode.

Because the weights add up to 1, the base risk is simply a straight-line reading of the token's weighted average quality $\overline{q}=\sum w_i{q}_i$:

Worked example. A token whose weighted average quality is 6.4 has a base risk of 100 × (10 − 6.4) ÷ 9 = 40.0.

Each component's own share of the base is $10\times w_i\times r_i$ points. A component weighted 0.08 with a risk of 5, for example, contributes 4 points.

The base can never exceed 100, so the components alone can make a token at most Medium risk. Only red flags and the adjustments below can take it into High or Extreme.

Step 4: Red flags¶

Each red flag raised adds a fixed number of points ${\beta }_k$. Together they are capped at 50:

A check that could not run reports Not checked and adds nothing. What each flag means and when it is raised is listed in Scoring model and categories.

Worked example. A token is flagged for a sanctions match (45) and, in EU mode, for EU regulatory issues (40). The flags add up to 85, so they count 50.

Step 5: Market-structure adjustments¶

A few signs of a fragile market add a smaller number of points, outside the red-flag cap:

Together these make the market adjustment $M$, the wrapped-token penalty $W$ and the native-token discount $N$.

Step 6: The risk score and its band¶

Two rules can override the sum:

• A speculative memecoin never scores below 50.5, so it is always at least Medium risk:
  $$S=\max (S,50.5)$$

• In EU mode, an unlicensed EU stablecoin scores 150, Extreme risk, whatever its other scores are.

The band follows from the score:

Worked example. A token with a base risk of 40.0 is flagged for an unverified contract (15) and low liquidity (12), and has 4,000 holders (+4). Its score is 40.0 + 27 + 4 = 71.0, Medium risk.

Total minus social¶

On Plus and above the report also shows the score without the social component. The social component's share of the base is

and Total minus social is $\mathrm{clamp}(S-C_{\text{social}},0,150)$. The difference between the two numbers is the social contribution. Because of how the social component is scored (see Social signals), it lies between 2.4 and about 6.7 points.

Category scores¶

The four category scores summarise the components in each category, on a 0-to-100 scale where higher is better, the opposite direction to the risk score. A category's score is the plain average of its components' quality scores, rescaled:

Category scores are a summary for reading the report. The risk score is calculated from the weighted components, not from the category scores.

Worked example. Contract components with quality scores of 7.2, 6.0, 8.1 and 5.5 average 6.7, so the Contract score is (6.7 − 1) ÷ 9 × 100 = 63.3, shown as 63.

Confidence¶

Confidence measures data coverage: how much of the evidence the engine expected for this token actually arrived. It never changes the risk score.

For each component, the expected sources $E_i$ are the data services that cover the component, cover the token's chain, are included in your plan and could be called in this run. Services that were skipped or failed in this run (for example, because they were temporarily unavailable or had used up their allowance) are left out of the count. Each expected source earns a credit ${\kappa }_p$:

If none of a component's sources could be called, all of them count as expected and the component's confidence is 0. The report then shows Partial data for that component.

The overall confidence pools every component's sources (a service that informs three components counts three times):

No component is shown with a higher confidence than the overall figure. The report also shows the credits and the expected count behind the overall figure, as "N of M sources", and the category confidence is the average confidence of the category's components.

Worked example. A component expects four sources. Three return data and one answers with nothing on the token, so its confidence is (1 + 1 + 1 + 0.35) ÷ 4 = 83.75%, shown as 84%, Moderate.

Plans and data¶

The formulas are the same on every plan, but the data they receive is not:

• Free queries a primary set of sources: market data, DeFi data, block explorers and node providers, and the core security and sanctions checks. The specialised services that Basic and above add can move a component's quality score, so the same token can score differently on Free and on a paid plan.
• Free and Basic do not collect social signals. The social component is then scored as a component with no social evidence (quality 2.5, risk 8.33), which adds 6.67 points to the base, and it is left out of the Market category score.
• Plus and above collect social signals and show the social contribution separately.

In plain words¶

Hodler Suite looks at a token from 16 angles, such as the safety of its code, how it trades, who holds it, whether it appears on sanctions or scam lists, and how active its development is. Each angle gets a mark out of 10, built from fixed rules and from what specialised data services report. No single service can tip a mark on its own, except for serious findings like a sanctions match, which always count in full.

The 16 marks are combined with fixed weights into a risk score out of 100, where higher means riskier. Specific warning signs then add points on top, up to 50 more, which is why the scale goes to 150. A score of 50 or less is Low risk, up to 100 Medium, up to 120 High, and above 120 Extreme.

Missing information never makes a token look safer: when evidence cannot be found, it counts against the token. Confidence tells you how much of the expected evidence actually arrived, so a high-risk score with low confidence is a reason to look closer, not to stop looking.

Everything is calculated the same way for every token and every customer, so two reports can be compared fairly and any number in them can be traced back to this page.