What torverify Is in 2026, and What It Refuses to Verify

Independence, stated plainly

No ads. No affiliate deals. No paid placement. A verification service that earns money per click has a quiet reason to bless the wrong address, and torverify removed that reason by not taking the money. When torverify says it cannot confirm something, nothing about its income changes, which is the point.

What "independent" does not mean

Independence is not the same as infallibility. torverify can still be wrong, slow to update, or missing a project entirely — the claim is narrower than that: nothing about how torverify is funded creates an incentive to say LEGIT when the evidence says otherwise. That is a claim about motive, not a claim about being error-free.

Why torverify names its limits instead of hiding them

A verification reference that only ever talks about what it can confirm, and never about what it can't, is easier to trust than it deserves to be. torverify's methodology page spells out exactly where the checks stop, on purpose — a boundary you can see is one you can actually rely on.

Why the tools run in your browser

The PGP check runs locally with a self-hosted library. Your key and message never leave the page. A tool that asks you to upload either one could lie about the result and keep a copy, so torverify does the maths on your machine and shows you armor you can read. The same design holds over Tor with scripts allowed.

The Tor Browser torverify assumes you’re using

torverify’s checks assume you are reaching every page, including this one, through an unmodified Tor Browser build from the Tor Project itself, not a repackaged copy from a third-party download page. A modified browser can leak information no amount of PGP signature checking would ever catch, which is a different failure mode from anything torverify’s verdict speaks to. torverify does not audit your browser, your operating system, or your network setup — those are separate, complementary precautions that sit underneath everything torverify verifies.

Why torverify doesn’t bundle its own browser-fingerprint tool

It would be easy for torverify to build a browser-fingerprint checker or a "is your Tor Browser safe" tool alongside the address and signature checks. torverify deliberately hasn’t, for the same scope-discipline reason it doesn’t rate markets: that kind of check is a different, deeper problem than address verification, and bolting it on would blur what a torverify verdict actually claims to answer. Get the Tor Browser directly from the Tor Project, keep it updated, and let torverify handle the narrower question of whether the address you’re pointing it at is genuine.

What torverify does not collect

The verify box and the PGP tool run in your browser. Addresses you paste are matched locally, and keys or messages you check never leave the page. We keep no accounts and ask for no email. A basic channel tag may ride in a link so we can tell which page sent a visitor, but it carries no identity and no address you looked up. The less we hold, the less anyone can ever demand from us.

What a channel tag is, concretely

When a link to torverify carries a short suffix pointing back to where it was posted, that suffix tells us "this visit came from a forum post" or "this visit came from a directory listing" — nothing more granular than that. It is never tied to a session, a cookie, or an address you subsequently look up. We use the aggregate only to see which outside pages are sending real readers, not to build a profile of any one of them.

What we would need to add, and why we haven't

A more conventional analytics setup would tell us which pages readers spend the most time on, where they drop off, and which guide gets the most traffic before a lookup. All of that is genuinely useful for improving a site. torverify has not added it, because every one of those signals requires tracking individual sessions in a way that sits uncomfortably next to a tool whose entire pitch is minimizing what it holds on a visitor checking something sensitive.

What we would do differently if compelled

We cannot promise a jurisdiction will never knock. What we can promise is architectural: because lookups resolve client-side and we hold no account database, there is very little to hand over even if compelled. The warrant canary exists specifically so a silent change in our situation is visible without us being able to say so directly.

Worked example: how a real address rotation gets handled

Policy reads differently from practice, so here is one concrete case. When a project we track rotates its onion address — a routine key rotation, not a compromise — our source of record does not update the moment someone claims a new address exists.

Step one: the claim arrives

A new address surfaces, usually from more than one channel at once — the project's own PGP-signed announcement, a forum thread, sometimes a mirror-list update. torverify does not treat any single one of these as sufficient on its own; a forum post can be forged as easily as a screenshot.

Step two: signature and quorum, not popularity

The new address only enters the signed source once it carries a valid PGP signature from a key we already hold, and once our 2-of-3 offline-signer quorum has re-signed the updated record. Until that quorum clears, the entry on the relevant verify page stays at UNVERIFIED even if the new address is, in fact, correct — we would rather be visibly slow than quietly wrong.

Step three: the old address is retired, not deleted

We do not scrub the previous address from history. The verify page notes that it is superseded, so a visitor who saved the old link months ago understands why it stopped matching rather than assuming our source itself broke.

Why the process is slower than "just trust the announcement"

A faster process would mean updating the moment a project's own channel posts a new address. torverify deliberately does not do that, because a compromised project channel is exactly the scenario the 2-of-3 quorum exists to catch — if torverify updated on a single announcement alone, the quorum requirement would be theater rather than a real check.

Why torverify calls itself a "verification lab"

The word is a deliberate choice, not decoration. A lab implies a repeatable method applied consistently to every entry, not a one-off judgment call made per project. Every address on torverify goes through the same sequence: string comparison, signature check, quorum confirmation — regardless of how well-known or obscure the project is.

What the "lab" framing rules out

It rules out treating any project as a special case. A large, well-known market and a small one both clear the same bar before torverify marks either LEGIT, and both sit at UNVERIFIED under the same conditions. Consistency is the entire value of framing this as a lab rather than a curated opinion piece.

How to hold torverify honest

Do not trust this site on faith. Read the methodology, compare the signer fingerprints against a second channel, and confirm any address through the PGP tool before you act. Watch the warrant canary for the date it should update. A verification service you cannot audit is just another page asking for trust.

What auditing torverify actually looks like in practice

It is not a one-time exercise. Re-checking the canary's date each month, re-comparing signer fingerprints when torverify publishes an update, and re-running a signature check occasionally rather than assuming last month's result still applies — that ongoing habit is what auditing looks like for a reference like this one, more than a single deep read of this page.

How torverify is funded and hosted

torverify carries no ads, no affiliate links, and no sponsored placement anywhere on the site — the "independence" claim earlier on this page is only meaningful if it is backed by an honest answer to how the lights stay on, so here it is plainly.

What torverify does not run on

There is no advertising network embedded on this site, no referral code appended to any outbound link, and no project pays for inclusion, a faster review, or a better verdict. A verification reference funded by the thing it verifies has a structural conflict of interest baked in from day one; torverify avoids that conflict by not building the funding model that would create it.

What running this site actually costs

Domain registration, static hosting for the HTML and the mirrors.json file, and the time spent maintaining the signed source and re-checking entries are the entire cost surface — there is no database to scale, no user accounts to secure, and no analytics pipeline to run, which keeps the operating cost low enough that it does not need to be recovered from readers or from projects being verified.

Why torverify hasn't added a donation or support mechanism

Accepting funds, even unconditionally, from readers or from projects being tracked introduces a question every future verdict would have to answer: did this donor's status influence this outcome. Rather than manage that perception indefinitely, torverify has chosen to keep the cost surface small enough that the question never has to come up.

What happens when torverify gets something wrong

A verification lab that claims perfect accuracy is not being honest, and torverify does not make that claim. The methodology is designed to fail toward caution — UNVERIFIED rather than a wrong LEGIT — but a mistake in either direction is still possible, and pretending otherwise would undermine every other claim on this page.

What a correction looks like

If an entry is found to be wrong — a stale address, a signature check that should have failed and didn't — the fix is a re-signed update to the source of record, the same quorum process any other change goes through, not a quiet edit. The sitemap's lastmod on the affected page reflects when that correction actually happened.

Why torverify doesn't quietly delete a past mistake

Silently correcting an error without acknowledging it happened would make torverify's own track record impossible for a reader to evaluate honestly. The same discipline that keeps a superseded onion address visible as "superseded" rather than deleted, described above, applies to torverify's own mistakes: better a visible correction than an invisible one.