torverify 2026: don't trust a link — verify the signature

How torverify's trust chain works, end to end

A verdict is only worth the evidence under it. Every check walks the same short chain: the raw address, the PGP signature over it, the quorum of independent signers who vouched for that signature, and the verdict that falls out of the maths.

torverify's three pieces of evidence, nothing softer

torverify in practice: three worked examples

The trust chain above is easy to describe in the abstract and easy to get wrong in practice. These three walk-throughs show what actually happens when a real string is dropped into the box — the same steps torverify runs on every submission, laid out slowly enough to follow by hand.

Example 1 — how torverify checks an address character by character

A v3 onion address is 56 base-32 characters plus the .onion suffix, derived directly from the service's Ed25519 public key. That means two addresses that differ by even one character are two different keys, full stop — there is no such thing as a "close enough" onion. torverify's first pass is mechanical: it takes the pasted string, strips whitespace and any surrounding scheme or slash, and does a byte-for-byte comparison against every address in the signed source. A single substituted character, a swapped digit, or a homoglyph copy-pasted from a phishing page fails this check instantly and never reaches the signature stage. This is also the check we recommend doing by eye before you paste anything: open the address you were given next to the one on record for that project and read it in short chunks, not as one long blur.

Example 2 — walking through torverify's PGP signature check

Passing the string match only proves the address is spelled the same as something on record — it does not by itself prove the record is genuine. That is what the PGP layer is for. Each project entry in torverify's source is wrapped in a signed message from a key we already hold and have cross-checked through more than one independent channel. When you run a check, torverify verifies that signature against the stored public key rather than trusting whatever key happens to be attached to the message. If the signature does not verify — wrong key, corrupted message, expired key — the entry is treated as unverified regardless of how the address itself looks. This is the step a copy-pasted phishing page can never fake, because forging it requires the private key, not the visible page.

Example 3 — reading torverify's 2-of-3 quorum result

A single signer, however trusted, is still a single point of failure — one compromised key and an attacker could sign a fake record. torverify's source of record is instead signed by three independent offline keys, and a verdict only turns LEGIT once at least two of the three agree. In the log below, every project currently reads as unverified specifically because that quorum has not yet been collected and re-signed for this build — not because the addresses are wrong. A "2 of 3" result and a "0 of 3" result look similar to a casual reader but mean very different things, which is exactly why torverify prints the raw quorum count instead of collapsing everything into a single green checkmark.

torverify's recent verification log

This is the current state of the signed source behind every verify page on the site. We show it plainly, including the projects that have not yet cleared quorum, because a directory that only displays its successes is not a verification tool.

Read literally: an UNVERIFIED row here is not a claim that the address is wrong. It means torverify's 2-of-3 offline-key quorum has not yet re-signed the entry for this build. We would rather a row sit at UNVERIFIED for longer than mark it LEGIT early.

How a clone tries to defeat a verification check like torverify's

Building torverify around a 2-of-3 signed source was a deliberate response to specific ways a phishing operation tries to get past exactly this kind of check. Understanding the attempts makes it obvious why the method is built the way it is, rather than something simpler.

Compromise torverify's checker, not the address

The most direct attack on a verification tool is not forging a signature — that is computationally infeasible against a real key. It is compromising the tool itself so it lies about the result: a fake "LEGIT" verdict handed out for an address that was never actually checked. This is exactly why torverify runs the PGP math client-side in your own browser rather than on a server whose output you have to trust blindly, and why the signer fingerprints are published across more than one independent channel instead of only here.

Time a fake mirror to a real outage

Tor onion services go down for mundane reasons — relay churn, maintenance, DDoS. Clone operators watch for these outages and push replacement addresses into forums and search results within hours, betting that urgency will override caution. A verdict here does not change just because a market is temporarily unreachable; an address either matches the signed source or it does not, regardless of whether the real service happens to be up at that exact moment.

Flood a mirror list with one real address hidden among fakes

Some phishing operations don't bother building a full clone — they publish a "complete mirror list" with one genuine address buried among several fake ones, hoping a visitor picks a random entry rather than checking each one. This is why torverify checks a single pasted address at a time against the source of record, rather than presenting a list to choose from that could itself be tampered with.

Wait out a stale cross-check

A signature check is only as strong as how recently the fingerprint you're comparing against was itself confirmed. An attacker patient enough to wait for a cross-channel source to go stale, then quietly alter one channel, is playing a longer game than most phishing operations bother with — but it's the reason cross-channel fingerprints get re-confirmed rather than published once and left alone. See the full methodology for how that re-confirmation actually runs.

Who runs torverify, and how to actually use it

torverify is maintained as an independent verification reference, not as a promotional page for any of the projects it tracks. No project pays for a listing, a better verdict, or faster inclusion, and no project has editorial input into how its own entry reads. That independence is the entire value of a verification layer — a reference that could be influenced by the thing it verifies is not actually verifying anything.

What "checked by torverify" means in practice

A project on torverify is checked against three concrete things, not a general impression: a signed source for its current address, a PGP fingerprint that can be independently confirmed, and a documented history of clone attempts specific to that project. A verdict changes only when one of those three inputs changes — not on a fixed schedule, and not because of unverified chatter.

What torverify does when evidence runs out

For a project where the signed source goes stale, the operator disappears, or the fingerprint can no longer be confirmed, torverify does not guess at a status to keep the entry looking current. It marks the entry UNVERIFIED or Unknown and says exactly what is missing, because a confident-sounding guess is more dangerous than an honest gap.

The fastest correct way to use torverify before you connect

Find the project on the verify index, read its current verdict and the reasoning behind it, then confirm the address and PGP fingerprint shown match exactly what you have in hand before you open anything in Tor. Skipping straight to "is this address in the list" without reading the reasoning misses the entire point — the reasoning is what lets you judge whether the verdict still applies to your situation.

When torverify's verdict and your own check disagree

If torverify shows a verdict that does not match what you are seeing — an address marked verified that will not load, or the reverse — trust neither blindly. Re-check the PGP fingerprint yourself using the method in the signature guide, and treat a persistent disagreement as a reason to wait rather than a reason to guess which source is right.

What to do when a project is not listed at all

An unlisted project is not automatically suspicious — torverify tracks a specific set of projects and does not claim coverage of every darknet market that exists. For anything not listed, the methodology page explains the general verification process well enough to apply the same logic manually: find a signed source, confirm a fingerprint, and treat anything short of that as unverified.

What torverify checks, and how it differs from a link directory

A verification layer like this one answers a narrower question than it might seem to at first glance: is this specific address the one the operator would sign for, right now. It does not answer whether a market is trustworthy to trade on, whether its escrow will hold up in a dispute, or whether a specific vendor on it is honest — those are questions no address-verification service can honestly claim to answer.

Address verification is not market vetting

Confirming an address is genuine tells you that you are talking to the actual operator's infrastructure, not a phishing clone. It says nothing about what happens after you connect. Escrow disputes, vendor scams that happen within a legitimate market, and operational decisions by the market itself are entirely outside what a signed-address check can catch.

A torverify-verified address today is not a permanent guarantee

Every verdict on this reference reflects a point-in-time check against the best available signed evidence. An address can be genuine today and compromised tomorrow through means that have nothing to do with the address itself — a server-side breach, a leaked private key, an insider incident. Re-checking before high-stakes use, not treating a past verdict as permanent, is the discipline this whole reference is built around.

Why this reference will not expand into market reviews

Scope discipline is deliberate. The moment a verification reference starts scoring vendor trustworthiness or market reputation, it takes on judgment calls that are far easier to get wrong, far harder to verify independently, and far more exposed to manipulation than a signed-address check. Staying narrow is what keeps every claim on torverify checkable.

How torverify differs from a general Tor link directory

A general-purpose Tor directory aggregates links, often hundreds of them, with minimal or no verification behind most entries beyond someone submitting a URL. torverify inverts that model: it covers a deliberately small, fixed set of projects and verifies each one against a signed source rather than trading coverage for depth.

torverify: fewer entries, checked harder

Every project tracked here has a documented verification method behind its entry — a signed source, a PGP fingerprint, a clone-pattern history specific to that project. A directory listing hundreds of links cannot realistically apply that same depth of checking to each one; breadth and per-entry verification depth trade off against each other, and this reference chose depth.

Why that trade-off matters for a reader

A directory that lists an address without checking it is functionally equivalent, from a phishing-risk standpoint, to a search-engine result: it might be right, but nothing about its presence in the list confirms that. An entry on torverify means something more specific — that a named check was actually run against it, with a documented outcome, not just that someone submitted a URL.

Tools that pair well with a torverify address check

Verifying an address is one link in a longer chain, and torverify does not try to be every link in it. The tools below are widely used, independently audited or open-source projects that handle the parts of the chain torverify does not — the operating system, the wallet, the password store, the encrypted volume. torverify does not receive anything from linking to them; they are named here because they are the projects worth knowing about, not because of any partnership.

The operating system layer, per torverify

Tails is an amnesic live operating system that routes all traffic through Tor by default and leaves no trace on the host machine after a session ends — a reasonable default for anything sensitive. Whonix takes a different approach, splitting a Tor gateway and a workstation into separate virtual machines so that even a compromised application cannot leak your real IP. Qubes OS goes further still, isolating entire tasks into separate virtual machines by design, which is the setup serious researchers in this space tend to reach for.

Wallets, storage, and secrets

For payments, Monero is the privacy-focused cryptocurrency most escrow-based darknet markets, including several torverify tracks, have standardized on, precisely because its ledger does not expose transaction graphs the way a transparent chain does. For keeping the credentials and fingerprints this site asks you to compare, a local encrypted vault such as KeePassXC beats a browser's built-in password manager, and VeraCrypt covers full-disk or container-level encryption for anything you are not willing to lose to a seized or stolen device.

Sharing files without a server

OnionShare lets two parties exchange a file or host a short-lived page directly over Tor without renting server infrastructure or trusting a third party with the content in transit — useful context for understanding how a project like torverify's own signed-source distribution could be mirrored independently.

The two tools underneath every torverify check

Everything torverify does rests on two pieces of software worth downloading directly from their own maintainers rather than a mirror: the Tor Project's own Tor Browser, and a GnuPG implementation from gnupg.org for the signature checks described on the PGP page. For the broader habits around any of this — not just onion verification but digital security generally — the EFF's Surveillance Self-Defense guide is a well-maintained, independent starting point, and Signal remains the reference point for encrypted messaging outside of Tor entirely.

torverify in three words: onion, verify, PGP

Every claim on this site reduces to those three words, so it is worth defining each one plainly rather than assuming they are self-evident.

Onion: the address, not the vibe

An onion address is a 56-character string derived from a Tor service’s own key — not a name anyone assigns, not a brand anyone owns. When torverify says an onion is UNVERIFIED, it means that specific onion string, character for character, has not yet cleared torverify’s quorum, regardless of how familiar the onion looks.

Verify: one narrow check, repeated the same way every time

To verify, on torverify, means exactly one thing: compare the onion address and its PGP signature against torverify’s signed source of record. torverify does not verify a market’s conduct, verify a vendor’s honesty, or verify uptime — verify here is always short for "verify the address," nothing broader.

PGP: the signature that turns a string into evidence

PGP is the signature layer that separates a real onion address from a convincing copy. A PGP signature is what torverify actually checks; the onion string alone is only step one. Anyone can read torverify’s PGP page and run the same PGP check torverify runs internally, on any PGP-signed message, not only ones torverify itself published.

Frequently asked questions about torverify

What torverify does not do (and why that matters)

A verification tool earns trust as much by what it refuses to claim as by what it confirms. torverify does not rank markets against each other, does not carry affiliate or referral links to any project it lists, and does not publish star ratings, review scores, or "best market" lists — those are editorial judgments dressed up as facts, and they have no place next to a cryptographic check. Confirming that an address and signature match torverify's source is also not the same as vouching for a vendor's honesty, an escrow's solvency, or a market's uptime tomorrow: those are operational risks no signature can settle. When torverify's source cannot confirm something, the verdict says UNVERIFIED and stays there — we do not soften it to keep a page looking complete, and we do not backfill a green badge because a project has been around a long time. That restraint is the whole product.

Start with a torverify project on record

These projects have an address in torverify's source. Open one to read the exact onion and copy it by hand, or browse the full list of verdicts.