How torverify Decides a Verdict: The 2026 Methodology, Step by Step

torverify's source of record

torverify's addresses live in one file, mirrors.json, meant to be signed 2-of-3 by three independent offline keys. Any two must agree for a record to count. That quorum is the safety margin. A single stolen or coerced key cannot mint a LEGIT verdict, because one signature out of three is not enough.

The file carries a rising version number and a short validity window. A reader rejects anything older than the last version it saw, or anything past its valid_until time, and falls back to the last good copy rather than showing an empty or stale list. When in doubt it fails closed.

Why "fail closed" is the whole design, not a footnote

A verification file that quietly falls back to showing nothing, or an old copy, when it can't confirm freshness is a deliberate trade-off: torverify would rather a reader see a stale-but-known-good list than a fresh-looking file that turns out to be forged or truncated. Failing open — showing whatever arrived, freshness unchecked — is how a compromised distribution channel becomes a silent attack.

torverify's four verdicts

• LEGIT. The exact address is in the current signed source and the quorum is satisfied.
• UNVERIFIED. No valid signature covers this address. It may be fine, torverify simply cannot confirm it, so it will not be coloured green.
• SCAM. An address that imitates a known name but fails signature checking, or that torverify has positively identified as phishing.
• SEIZED. The market of record was taken down. No current address for the name is legitimate, and none is published here.

Why UNVERIFIED and SCAM are kept as separate outcomes

Collapsing "no proof yet" and "actively identified as fraud" into a single negative verdict would either overstate the evidence against an address that simply hasn't cleared quorum, or understate the risk of one that has been positively flagged. Keeping them apart means each verdict on torverify carries exactly the weight of evidence behind it, no more.

torverify's cross-channel fingerprints

A signature is only as good as your copy of the key. torverify publishes the signer fingerprints through more than one channel so you can compare them and catch tampering on any single one. Two independent sources agreeing on a fingerprint is what turns “a valid signature” into “a signature from torverify”.

Why one channel is never enough

If we published a fingerprint only on this site, anyone who compromised this site could swap it for their own key and every subsequent check would silently trust the attacker. Cross-channel publication means an attacker has to compromise more than one independent surface at once, and do it without any of them noticing the mismatch. It is the same reasoning the Tor Project gives for verifying a Tor Browser download signature against more than one source before trusting a binary — a lone claim of authenticity is not verification, a matching second channel is.

What "agreement" actually means in practice

Agreement is not "the fingerprints look similar." It is a byte-for-byte match of the full fingerprint string across every channel we publish it on. Compare in short groups — the standard 40-character hex fingerprint breaks cleanly into 4-character blocks for exactly this reason — and treat any single mismatched block as a failed check, not a typo to wave off.

Worked example: tracing one verdict from address to badge

Take a hypothetical submission of an onion address for a project already on record. Here is the exact sequence torverify runs, in order, with nothing skipped.

1. Normalize and match the string

Whitespace and any http:// prefix are stripped, then the remaining 56-character string is compared byte-for-byte against every address in mirrors.json. No match means an immediate UNVERIFIED — no record found, and the chain stops here.

2. Locate the signed entry and check the signature

A match pulls the corresponding signed entry and verifies its PGP signature against the public key on file for that project — not whatever key happens to be attached to the submission. A bad or missing signature also stops the chain at UNVERIFIED.

3. Confirm the quorum count

The entry's signature history is checked against the 2-of-3 offline-signer requirement. Fewer than two independent signatures means the chain stops at UNVERIFIED even though the address and the single signature both checked out — this is the step most directories skip entirely.

4. Only then, render a verdict

Only after all three prior steps clear does the badge read LEGIT. Every other outcome along the way renders as UNVERIFIED, SCAM, or SEIZED depending on which check failed and why — never as a silent pass.

Why this example uses "hypothetical" rather than a live submission

The sequence above is exactly what runs on a real submission; it's framed as hypothetical here only because a static methodology page can't demonstrate a live check the way the actual verify form does. Every step named is real and independently re-runnable — nothing in this walkthrough is simplified for the sake of the explanation.

How torverify handles a change to the methodology itself

The procedure described on this torverify page is not frozen forever, but changing it is treated with the same discipline as changing an individual verdict.

What would trigger a methodology change

A genuine gap found in the process — a step that turns out not to catch a real attack shape it was meant to catch — is the only legitimate reason to revise this page. A methodology that changes to accommodate a specific project's convenience would defeat the entire point of having one procedure applied uniformly.

How a change would be communicated

Any material change to this methodology would update this page's own entry in the sitemap, with the revision described here directly rather than silently applied. A verification process that changes its own rules without saying so is exactly the kind of quiet inconsistency this page exists to rule out.

What torverify deliberately refuses to do

torverify does not rate markets, measure uptime, or rank anything. Those are separate jobs with separate failure modes, and folding them into a verdict would make the verdict mean less. It also never hardcodes a status as online. An address being signed says nothing about whether the service answers this minute.

Why scope discipline is part of the methodology, not separate from it

A methodology that quietly expands to cover more than it can rigorously check is a methodology in name only. torverify's refusal to rate, rank, or claim uptime is as much a documented part of this process as the 2-of-3 quorum itself — both exist to keep every claim on this site checkable by a reader, not just asserted.

torverify's methodology versus ad hoc trust signals

Most Tor link directories lean on signals that feel like verification but aren't: a site that has "been around a while," a forum thread with upvotes, a badge the operator added to their own page. torverify's methodology deliberately avoids every one of these, because each is trivially forgeable by whoever controls the page being judged.

torverify: age and popularity are not evidence

A phishing clone can be registered the same week as the real project and, given enough search traffic, accumulate exactly the same apparent "age signals" a casual reader might use to judge trust — a familiar layout, an established-looking URL history, forum mentions. None of that touches the one thing that actually distinguishes a genuine address from a clone: control of the signing key. torverify's methodology only counts that.

torverify: a self-issued badge proves nothing about the issuer

Any operator, honest or not, can put a green checkmark, a "verified" ribbon, or a security-audit logo on their own page. torverify does not accept self-issued badges as input to a verdict for the same reason a bank does not accept a customer's own signature as proof of a second bank's approval — the badge and the page it sits on share the same author, so the badge cannot vouch for the page.

Community reports are logged, never auto-trusted

User reports of a scam or a working mirror are useful leads that torverify's operators read, but a report by itself never flips a verdict. Every change still has to clear the same 2-of-3 signature quorum as every other entry — otherwise a coordinated wave of fake reports could manipulate a verdict as easily as a single compromised key could.

Why torverify's methodology stays independently re-runnable

Every claim this methodology makes is designed to be checked by someone who does not trust torverify at all, which is a deliberately higher bar than most verification pages set for themselves. The string comparison needs nothing but eyes and the published address. The signature check needs nothing but a PGP client and the published public key. The quorum count needs nothing but reading how many valid signatures cover an entry in mirrors.json. torverify's own conclusion is not required as an input to any of those three re-runs — a skeptical reader can arrive at the same LEGIT, UNVERIFIED, SCAM, or SEIZED verdict independently, using only public data and open tooling, which is the actual test of whether a methodology document describes a real process or just a plausible-sounding one.

Questions security researchers ask about torverify's methodology