RecheckableTransparency score, not a security audit
Methodology
Method v0.3.0 · 2026-10-21 · rubrics onchain v0.2.7 / offchain v0.2.7 · change log → · How it works, in plain words →
1. How a check is scored
- ✓ Met
- 1
- ◐ Partial
- 0.5
- ✕ Not met
- 0
- ? Unknown
- we read the source and could not establish the fact: excluded from the category mean, −1.5 pts each (max 10); a category with only unknowns scores 0 of its weight
- ⊘ Not read
- our checker could not read the source (timeout, HTTP 403/429/5xx, empty or JavaScript-only page): no points lost, but it lowers coverage. It is not a finding about the project. A token mint whose address could not be confirmed or read is Not read (method 0.2.4), not Unknown
- ◌ Not assessed
- nothing was submitted or found to assess in that category (for example no API, extension or program): no points and no penalty, but its weight stays in the denominator of the weight coverage. “Nothing to assess” never reads as “nothing wrong”
- ℹ Status only
- shown, never scored (for example “claimed”)
- ○ Not built
- excluded (our gap, not the project's)
- – N/A
- excluded
2. How it becomes a score
Category = weight × mean of decided checks. Total = sum over categories with decided checks, rescaled to 100, minus the unknown penalty. Coverage = decided ÷ (decided + unknown + not read). Unknown (we read the source and could not establish the fact) is left out of the category average and costs 1.5 points per check (at most 10); a category with only unknown checks counts as 0 of its weight. Not read (our checker could not read the source) costs no points but lowers coverage; below 70 % coverage no grade is given.
3. Bands
No band below 70 % coverage, and none unless at least 60 % of the rubric weight was actually assessed (“Insufficient data”): a site with only a homepage and a repository has no contract, key-custody or transaction evidence to grade, so it is listed without a grade. Directory and badge show the worst track.
The grade describes how much of a project’s control structure, code and contact information could be checked from public sources on the date shown. It does not describe how good, safe or honest a project is. A low grade often reflects missing or unreadable public evidence, not misconduct.
Onchain weights — onchain v0.2.7
Offchain weights — offchain v0.2.7
Rules that fix or cap a result
- Single-key upgrade/mint/freeze authority, or a multisig with threshold 1 or one voting member → “Not met”, with a plain line at the top of the report (address, slot, time, evidence, method).
- Squads multisig: threshold and members are read onchain and the vault address is re-derived. Threshold ≥ 2 → Partial (independence of members is not provable). Met only with threshold ≥ 2, a time lock > 0 and no config authority. An unidentified PDA → Unknown.
- A homepage phrase that looks like a request for a seed phrase or private key is never published automatically. Phrases that are warnings (“never enter your seed phrase”) are ignored. Any other hit is held: the check stays Not read, has no effect on the score, and is reviewed by a person against the quoted text and source before anything is published. Only a confirmed case caps the band at E, shown as a quote with its source and date.
- Build match in the OtterSec registry (method 0.2.5): the OtterSec registry lists every build submission of a program. A build counts as Met when any entry in that list matches the program’s current on-chain hash, whoever submitted it, not only the registry’s default entry; the check names the repository, commit and signer of the matching entry. Submissions that match an older hash do not count. For an immutable program, a missing match is never described as a later upgrade.
- Unreachable domain (method 0.2.6): when the site cannot be reached, we ask two independent public DNS resolvers (Cloudflare and Google). Only if both answer “no such domain” (NXDOMAIN) does the report say “the domain does not resolve (checked with two public DNS resolvers)”; otherwise it keeps the plain “no HTTPS connection” wording. The score effect is the same as before.
- Fetch failures and repository choice (method 0.2.7): a site that times out or resets the connection on two tries counts as Not read (no points, lower coverage), not as “no HTTPS”. When a project gives a GitHub organisation rather than one repository, the repository, licence and contributor checks use the organisation’s most-starred non-fork, non-archived repository (ties: name), so the choice stays the same from run to run; recent activity uses the latest push across the organisation’s non-fork repositories. Organisations with more than 100 public repositories are judged on the first 100 only.
- Components a project does not have (method 0.3.0): a category is Not applicable, and left out of the rubric weight, only when the project has no own on-chain program (none found by the same program search used for every project) and its own website or GitHub states what kind of product it is (wallet, explorer, analytics, API/service, app, or liquid-staking token on a shared stake-pool program). Which categories apply depends only on the components: Key custody applies to wallets, extensions, transaction-building APIs and staking pools; Transaction behaviour to wallets, extensions and transaction-building APIs; Extension permissions only when there is an extension; Listings only to APIs/MCP servers. A category with a decided check is always scored. Without that evidence, a category with nothing to read stays “not assessed” and lowers the weight coverage, as before. A liquid-staking token on a shared stake-pool program is scored on its own pool: the pool’s manager and staker authorities and the token’s mint and freeze authority, judged by the same control rules as program authorities; the shared program itself is not scored. The 70 % coverage and 60 % weight-coverage rules are unchanged, computed over the categories that apply, and every grade also needs at least 10 decided checks in at least 3 categories, so no grade rests on a handful of checks.
- Self-declared text (company name, listings) earns nothing without registry evidence. Domain age only counts when the domain is linked to the submitted components. Audit links must reference the program or be hosted by a known auditor / the project's own GitHub org. Audits are discovered automatically (method 0.2.2) from the project’s own official sources only: its GitHub organisation (audit folders and documents in its non-fork repositories) and its website (audit and security pages, including docs sub-domains). The same search runs for every project; reports are matched to the project by the program ID in the text when it can be read, otherwise they count as Partial when a known audit firm is named. Two or more distinct audit firms found at official sources (method 0.2.4) count as Met even when the program ID cannot be read in the documents; this applies to linked and discovered audits alike. We never rate an audit’s quality, scope or date. If the search found nothing, the check says “not found in what we searched” and lists what was searched; this is not proof that no audit exists (reports may sit elsewhere, for example on an auditor’s site). If a source could not be read completely, the check is Not read: no points are lost and coverage goes down. A project can point us to its audit page: info@recheckable.com.
- No one adjusts a score by hand. If a data mapping is wrong (for example a wrong repository or address), we fix the mapping and recompute; the fix is logged in the change log. AI never affects the score.
- Whether a page is claimed, whether a project has replied, and payment are never inputs to a score, coverage or placement.
Monitoring & badges
Monitored fields are hashed into a snapshot. A re-check that changes any of them greys the badge; the band stays visible. A re-check or a new submission can never restore a badge — only a full review with sufficient coverage. Free reviews grey after 30 days.
Claimed / not claimed
Claimed means that a party that controls an upgrade authority, an official domain or a GitHub organisation of the project proved that control. It does not mean that we checked or approved the project or its people, or that the project reviewed or approved the score. Not claimed is neutral: the page was produced from public data without the project’s involvement, and the status says nothing about the project or its score. On pages that are not claimed the seal is drawn in washed-out colours; the difference is only the status, the grade letter and number are the score. Claiming is free and needs no review by us. Three ways: (A) an off-chain wallet signature from the upgrade authority or a member of the multisig / DAO council that holds it; (B) a DNS TXT record on the official domain, which two independent resolvers must show; (C) a published file: one line, recheckable-claim=<project>:<token>, at https://<official domain>/.well-known/recheckable.txt or as recheckable.txt in a public repository of a GitHub organisation that the project links to itself. Domains and organisations must be tied to the project by its own listing, on-chain security.txt or website; personal GitHub accounts, forks and archived repositories are refused. We record the URL, the HTTP status and a hash of the file, so anyone can open the same URL. Records and files are re-checked nightly; if one is gone for more than 14 days the page shows as not claimed until it is claimed again. A temporary network error never changes the status. We do not publish signer addresses: a page shows only the method and the date.
Claiming never changes a score, and nobody can pay for a better grade or placement.
Publication (automatic)
Nobody selects which projects are scored, and nobody approves a page by hand. Every project in our index is checked by the same engine. Its score appears when all of these hold: (1) coverage is at least 70 %, so that a grade exists; (2) there is no hard flag (a counted check rests on a source that blocked our checker, or a phrase that might be a request for a seed phrase is waiting for a person); (3) no anomaly: a swing of more than 10 points, or a grade jump of 2 levels or more, between two consecutive runs is held in a review queue until a person has looked at it; (4) stable: at least two successful runs, at least 24 hours apart, gave the same grade; (5) no waiting period during the beta: a score can appear on the first nightly run on which conditions (1) to (4) and (6) hold; (6) evidence is stored for every counted check: URL, HTTP status, time fetched and a SHA-256 of what was fetched. A project that is in the index but does not (yet) meet them is listed by name only, as “Listed, not yet scored”, with no grade, no number and no seal. A contact route is not required: the page shows the contact route we found (security.txt on the official domain, on-chain security.txt or a route the project publishes), or “Contact route: not found”.
During the beta a later change that lowers a grade is published on the next nightly run, without a waiting period; a large swing is still held for a person (the anomaly rule). Where a project publishes a contact route, a private preview notice is prepared automatically and sent by a person from an @recheckable.com address; a page says “Owner notified on [date]” only when a notice was actually sent. Not answering is not treated as agreement or as an admission. Pages that the automatic checks flag are reviewed by a person; that is the only manual step, and it can only hold a page back or release it, never change a score. Every such release or hold is logged. How scores are made, what can go wrong and how to get a result fixed →
How the list is ordered
The directory is sorted alphabetically by default. You can sort by score or by the date of the last check; ties are broken by name. Sorting by score is a convenience, not a ranking of quality or safety. The weekly list is ordered by the rule stated on that page, and its list of movers only covers claimed projects.
Submissions
Web submissions are stored as requests. They never create or overwrite a public report by themselves. Projects are indexed from public data and scored by the same automatic checks as every other project; a submission does not change how or when a page is shown.
AI-generated text
Generated with Grok 4.7 (xAI), Claude sonnet-5-5 (Anthropic) and GPT-6.1-sol (OpenAI) via their APIs. xAI, Anthropic and OpenAI have not reviewed, approved or sponsored Recheckable. AI-generated text; models see only extracted check results, never project-supplied text or personal names. They do not affect the score.
Some text on this site (summaries and reports) is AI-generated and labelled where it appears. Scores and check results come from fixed code, not from AI. Scores are produced automatically from public data and are not reviewed by hand before they are shown; cases that the automatic checks flag are held for a person.
Models get only extracted fields (category, check id, status, band, score, coverage). Project text and personal names are never sent. Output is hidden if it uses forbidden words (safe, trusted, scam, recommend…), states a band/score not in the evidence, claims an audit or multisig not in the evidence, or contains URLs.
Interests
Recheckable is published by Leviathan Technologies AB, org. no. 559578-8034, Täljövägen 5, 18592 Åkersberga, Sweden, info@recheckable.com. The publisher is editorially responsible and also develops other crypto products (see Methodology, “Interests”). Reports on projects built by the same people carry a “Related party” box and tag. Paid monitoring, if a project buys it, is shown as: “Project pays for monitoring. Payment does not affect the assessment.” and never affects scores, grades, rankings or how requests are handled.
Pay-to-play rule. Paid products are kept entirely separate from previews, corrections and disputes: they are never mentioned in them, there is no sales contact with a project during a preview, an open dispute or the 30 days after, and payment never affects timing, priority or outcome.
Limits
- A review is a snapshot; servers can behave differently towards the reviewer.
- Static scans miss obfuscated or JS-rendered content. When we cannot read a source the check says “Not read” and costs no points.
- Backdoors in never-upgraded code and frontend swaps are not caught by onchain monitoring.