The zkCheck Score

Why a number

Eight answers are precise and they are eight things to read. A launchpad card has room for one. The score compresses the seal into a number a holder can compare across tokens, and every point in it can be traced back to the seal's public fields. It adds nothing that is not already on the seal; it arranges it.

The scale

Score	Band
70 to 100	Lower risk
35 to 69	Caution
0 to 34	High risk

The bands are named for what they are. "Lower risk" is not "safe"; what a seal cannot see applies to the score exactly as it applies to the seal.

The three parts

Checks, 60 points. 7.5 per passing check. A check that did not run (check 07 before deployment) is removed from the denominator rather than counted as a fail.

Code analysis, 25 points. Four signals read from the same AST as the checks, by declaration id, deterministically.

Signal	Points	What it measures
Owner-only functions that change state	10	External functions gated on an owner or a role that write state. None: 10. One or two: 8. Three to five: 5. Six or more: 2.
Addresses that can be changed after deployment	5	address state variables with a setter reachable after the constructor: treasury, router, fee recipient. None: 5. One or two: 3. More: 1.
Dangerous primitives	5	tx.origin in reachable code costs 3; inline assembly costs 2.
Token foundation	5	Inherits from OpenZeppelin, Solmate or Solady: 5. Hand-written token logic: 3.

Review, 15 points. The reviewer ends its text with a structured verdict: a risk level, a one-sentence summary and flags. Low risk: 15. Medium: 8. High: 0. When there is no review, or the reviewer produced no verdict, this part is removed from the denominator.

Coverage

The score is round(100 × earned / available), where available is the sum of the parts that actually ran. A seal made before deployment without a review is scored on 60 + 25 − 7.5 = 77.5 of 100 possible points, and the seal says "computed on 78% of the scale". A number computed on less of the scale is a less complete number, and the seal never hides that.

Flags

Red flags are, in order: every failed check with its evidence; every code-analysis signal that lost points, in words (An owner can redirect: treasury, router); the reviewer's flags. Green flags are the analysis signals that scored fully (No owner-only function can change state after deployment), facts the checks established (Supply is fixed after deployment), and the reviewer's positive flags.

The analysis flags are deterministic. The reviewer's flags are an opinion, like the review, and come from the same signed text.

The one-sentence summary

The reviewer's tldr. It is the first line a holder reads on the seal page, and it is the reviewer's, not the checks'.

What the score is not

It is not a probability. It is not calibrated against outcomes yet; when enough sealed tokens have a history, the weights will be revisited, and the rule set version on the seal will say which weights applied. It is not a substitute for reading the eight answers: a token at 74 with a failed check 02 has a drain in it, and the red flags say so in the first line.

In the API

"score": {
  "value": 91, "band": "lower-risk",
  "parts": { "checks": [52.5, 52.5], "analysis": [23, 25], "review": [15, 15] },
  "coverage": 93,
  "tldr": "A plain fixed-supply token with a constant tax to a fixed treasury.",
  "redFlags": [], "greenFlags": ["Supply is fixed after deployment.", "…"]
}

analysis is also returned in full, signal by signal, so that a badge can show why.