torverify Onion Verdicts 2026: Legit, Unverified, or Seized

How to read this table

A verdict answers one question: is the address genuine, or a clone? It is not a rating, a review, or an uptime check. For rankings look at an index. For whether a service answers right now, look at a status board. Here torverify only attests to the address.

Reading the "What torverify holds" column

That column is deliberately narrow — it says what evidence exists, not what it means for you. "The address on record" is a factual claim about torverify's source; how much weight to put on it before connecting to anything is a judgment each visitor still has to make with the reasoning on the project's own verify page.

Why torverify links every row instead of stopping at torverify's table

A single word in a table cell can’t carry the reasoning behind it, so torverify treats this directory as an index, not a final answer — every row links to a full page with the address, fingerprint slot, and project-specific reasoning the table itself has no room for.

Missing names and honest gaps

Some projects have no signed record yet. torverify would rather show a gap than invent a verdict, so those names are left off until there is a signature to stand on. If a mirror list shows a name torverify does not list, that difference is worth a second look before you trust it.

A missing name is not the same as a bad name

torverify's table intentionally does not include every darknet market that exists, and absence here should be read as "not yet checked," never as "confirmed fraudulent." Treating a missing entry as an automatic red flag would push readers toward assuming torverify's narrow, deliberately small tracking list is a complete map of the space, which it is explicitly not designed to be. See torverify's methodology page for exactly what earns a project a place on this table in the first place.

Why seized names stay on this torverify list

A dead market does not stop pulling searches, and that leftover attention is exactly what fraud operators harvest. Keeping a fixed SEIZED verdict for a name like AlphaBay or Hydra means the honest answer is easy to find: nothing live under that name is real. Removing the entry would hand the search result back to whoever cloned the brand. So the graveyard stays visible on purpose.

What torverify would need to remove a SEIZED row

In practice, nothing short of a genuine, independently verifiable relaunch signed by the original project’s own key — something torverify has never seen happen after a real law-enforcement seizure. Until then, a SEIZED row on this table stays exactly as fixed as the underlying fact it reports.

How often the records change

Onion services rotate keys and shuffle mirrors, so an address torverify confirms today may be replaced next month. When that happens the torverify record here moves with the signed source, and the old string becomes worthless. Treat every entry as a snapshot, re-open it on each visit, and never lean on an address you memorised weeks ago.

What torverify's sitemap actually tells you about freshness

Every page on this site, including each individual verify page, carries an honest lastmod timestamp in torverify's sitemap reflecting when that specific page last changed — not a single batch timestamp applied uniformly across the site regardless of what actually moved. If a project's verify page shows a recent lastmod, that is a genuine signal something about that entry changed; if it doesn't, nothing did.

What torverify checks before a project gets a row on this table

A project does not appear on the torverify verdict table because it is popular, because it asked to be listed, or because it pays for placement — torverify does not run affiliate links or paid placements anywhere on this site. It appears because torverify's 2-of-3 signing quorum has an address to confirm, sourced from mirrors.json and cross-checked against the project's own published PGP key, verified with a standard GnuPG implementation the same way torverify's PGP tool does. Nothing about a project's reputation, order volume, or how long it has operated moves it up this table; a torverify label — LEGIT or UNVERIFIED — is address verification only, never a review.

Why torverify limits itself to this narrow question

It would be easy for torverify to expand into star ratings, uptime percentages, or vendor trust scores, and plenty of sites in this space do exactly that. torverify deliberately does not, because those signals are either unverifiable from outside the market or actively easy to fake, and mixing them into an address-verification table would quietly launder a guess into something that looks like a fact. Every torverify verdict is scoped to the one claim we can actually stand behind: this address, this key, this quorum.

How to use this table alongside torverify's other pages

torverify's directory is the fastest way to check a single project, but it is not the whole of torverify. The PGP tool walks through verifying a fingerprint by hand, the signed source is the underlying record this table reads from, and spotting a fake mirror covers the patterns that show up across projects rather than any one of them. Use the table to find the project, then use those pages to understand why the verdict holds.

Using torverify's table when you already have an address in hand

The most common way people arrive here is with a specific address already in hand, wanting to know if it matches. Find the project's row, open its dedicated verify page, and compare the address there against yours character by character before doing anything else — the table itself is an index, the individual verify page is where the actual comparison happens.

What a single project's verify page adds beyond this table

Each row here links to a page built around one project specifically, and that page carries more than this table can show in a single cell.

The full address, not just a status word

Every project verify page prints the complete 56-character onion address as selectable text with a copy button — something a summary table can't reasonably do for nine projects at once without becoming unreadable.

The specific clone patterns seen for that project

Different projects attract different phishing tactics depending on how they're typically found and shared. A project's own verify page documents the patterns specific to it, which is more useful than the general guidance in torverify's phishing hub once you already know which project you're checking.

torverify's four verdicts, defined precisely

The words in the table above carry exact, deliberately narrow meanings. Reading them loosely is where most misunderstandings about this table start.

Why torverify separates SCAM from UNVERIFIED instead of merging them

It would be simpler to collapse everything torverify hasn’t confirmed into one grey status. torverify doesn’t, because the two words describe genuinely different situations and merging them would throw away information a reader needs.

UNVERIFIED: the string matches, the signature isn’t closed yet

Every active project on this table currently reads UNVERIFIED for the same reason: the address on file matches torverify’s source, but the 2-of-3 quorum signature covering it has not finished coming online. That is a statement about torverify’s own verification pipeline, not a claim that anything is wrong with the address itself.

SCAM: torverify has positively identified an impersonation

SCAM is reserved for an address torverify has specifically identified as a phishing pattern targeting a tracked project — a near-miss string, a broken signature chain, or a known clone campaign. It is a stronger, more specific claim than UNVERIFIED, and torverify does not apply it loosely just because an address is unfamiliar.

Why the difference matters for how you act on either word

Treating UNVERIFIED as if it meant SCAM would push readers to distrust addresses that are probably fine but simply haven’t cleared torverify’s own signature process yet. Treating SCAM as if it meant merely UNVERIFIED would understate a confirmed threat. Keeping the words separate keeps both claims honest.

How torverify’s 2-of-3 quorum works across every project on this table

The same mechanism sits behind every row above, whether the project is UNVERIFIED or SEIZED.

Three independent offline keys, not one central authority

torverify’s source of record is signed by three separate offline signer keys, held independently of each other. No single key, including one an attacker might compromise, can push a bad address into any project’s record — agreement from two of the three is required before anything above moves to LEGIT.

Why this table shows no LEGIT rows yet

Every active project currently reads UNVERIFIED because the quorum signing process itself is still being brought fully online across all tracked projects at once, not because any individual address is suspect. torverify would rather every row read UNVERIFIED honestly than promote any one of them early.

What changes a row from UNVERIFIED to LEGIT

Exactly one thing: two of the three signer keys independently confirming the address against the project’s own published PGP key. Nothing about popularity, time listed, or how many people ask about a project moves that needle.

Using this table if a search engine sent you here directly

A large share of visitors land on this exact table after searching a specific project’s name plus a word like “legit” or “real,” rather than browsing from torverify’s homepage.

Jump straight to the row that matches your search

Use the table above, find your project, and open its dedicated page rather than reading the whole directory top to bottom — each project page repeats the full address, the fingerprint slot, and reasoning specific to that project, which this shared table intentionally keeps out of every cell to stay readable.

If the name you searched for isn’t in the table

See the missing-names section above: absence here means torverify has no signed record yet, not that the project is confirmed fraudulent. Compare that against a genuine authority like the Tor Project itself before assuming any unlisted name is automatically safe or unsafe.

How this table differs from a general-purpose Tor link directory

A general Tor directory aggregates addresses, often hundreds of them, with little or no verification behind most entries beyond someone submitting a URL.

Depth over breadth, by design

This table covers a deliberately small, fixed set of projects and verifies each one against a signed source rather than trading coverage for depth. A directory listing hundreds of links cannot realistically apply that same depth of checking to each one.

What an entry on this table actually means

A row here means a named check was actually run against that address, with a documented outcome you can read on the project’s own page — not just that someone, somewhere, submitted a URL to a list.