torverify’s Signed Source: Every Onion Address We Attest To (2026)

How to use torverify's signed source

Pick the project you are after, copy the full string, and paste it into Tor Browser yourself. Do not follow a link from a forum or a search result to get here. The point of a source of record is that you always return to the same trusted place instead of chasing addresses around the web.

Bookmark torverify's page, not a search result

Search rankings shift, and a bookmarked search result can quietly start pointing at a different, unrelated page over time if a domain lapses or changes hands. Bookmark torverify's own signed-source URL directly, and treat any route back here through a third-party search or link as worth re-verifying.

Why torverify uses 2-of-3, not one signer

One key is a single point of failure. If it is stolen or its holder is coerced, one signature could bless a fake address. With three offline keys and a rule that any two must agree, a lone compromised key is not enough to mint a genuine record. That gap is the whole safety margin behind these addresses.

What "live signature pending" actually means right now

The pending label above is an honest status, not filler text: the three offline signer keys behind this record are not yet publishing a machine-verifiable quorum signature over the JSON file. That does not mean the addresses on this page are unverified in every sense — they still reflect the current source of record, cross-checked manually against each project's own published channels — but it does mean the fully automated, cryptographically provable version of this guarantee is not live yet. This torverify page will say so plainly the moment that changes.

Common mistakes torverify sees on this signed source

The page itself is simple; the mistakes people make around it are what actually cause problems.

Mistake 1: trusting a screenshot of this page instead of the live page

A screenshot circulating on a forum can be edited or simply out of date. Always visit torverify's signed-source page directly rather than trusting a copy someone else posted, however convincing it looks.

Mistake 2: copying an address from a search result's cached snippet

A cached or indexed copy of this page can lag behind the live version. Confirm you're reading the current page — check the page loaded fresh, not a cached preview — before copying anything you intend to rely on.

Mistake 3: skipping torverify's quorum-pending note

The pending label at the top of this page is not boilerplate. Until the 2-of-3 signature is live, treat every address here as torverify's best current record, cross-checked manually, rather than a fully automated cryptographic guarantee.

Worked example: adding a new address to your own notes safely

Suppose you want to save one of these addresses somewhere for later use. Here's the process that avoids introducing an error at the one step most people rush.

Step 1 — select the text, don't retype it

Use the copy button next to the address rather than reading and retyping it by hand. A 56-character string retyped from memory is exactly where a single transposed character slips in unnoticed.

Step 2 — paste it somewhere you can immediately verify

Paste into a plain text note first, then compare it character-for-character against this page once more before using it anywhere — catching a clipboard error here costs seconds; catching it after connecting to a wrong address costs much more.

Step 3 — re-check against this page before every use, not just the first

An address that was correct last month can become stale if a project rotates. Treat this page as the thing to re-check, not the note you saved from it.

How torverify's signed source differs from a typical mirror list

Most "working mirror" lists circulating on forums and aggregator sites are unsigned by design — whoever compiled the list is asking you to trust their judgment, with no cryptographic claim behind any entry. This torverify page is built the opposite way: every address exists here because it can be traced back to a project's own published source, not because it was reported working by an anonymous poster. That distinction is the entire reason torverify exists as a separate reference rather than just another aggregator.

Why torverify's list is short on purpose

A directory that lists everything gets breadth at the cost of depth — nobody can independently confirm hundreds of addresses with any rigor. This source of record stays limited to projects torverify can actually stand behind, and a name's absence here means it has not cleared that bar yet, not that it has been judged illegitimate. Check the verdict directory for the reasoning behind each entry that does appear.

What to do if this page and a project's own site disagree

If an address here does not match what a project currently publishes on its own official channel, treat that as a signal something has changed faster than this page has been updated, not as proof either source is wrong. Hold off connecting to either address until the discrepancy resolves, and re-check torverify's signed source after a short wait rather than defaulting to whichever address you saw first.

Why torverify doesn't just link to each project's own site instead

Linking directly to a project's self-hosted "official address" page would reintroduce the exact problem this page exists to solve — that page can be cloned as easily as any other. torverify's signed source is meant to be an independent checkpoint, cross-referenced against a project's own channels rather than simply repeating whatever they say about themselves.

Reading torverify's mirrors.json directly

The addresses on this page also exist as a plain mirrors.json file, meant for scripts, monitoring tools, or anyone who prefers to parse structured data over reading a rendered page. torverify keeps the format deliberately boring, which is a feature for anything meant to be machine-consumed.

What torverify's file actually contains

Each entry pairs a project name with its current onion address, alongside the version number and validity window mentioned elsewhere on this page. There is no ranking field, no popularity score, and no editorial commentary embedded in the JSON — just the same facts this HTML page presents, in a format a script can parse without scraping markup.

Why torverify didn't build a public API instead

A static JSON file over plain HTTPS is simpler to audit, cache, and mirror than any API with authentication or rate limits — anyone can fetch it, diff it against a previous copy, or archive it without asking torverify for permission. That simplicity is deliberate: the fewer moving parts between the signed data and the reader, the fewer places a tampering attempt could hide.

A script is not a substitute for the signature check

Parsing mirrors.json programmatically retrieves the same addresses shown above, but it does not, on its own, verify the 2-of-3 quorum signature over the file. Any automation built against this source should perform the same signature verification a human reader is asked to perform on the PGP tool — fetching the file is not the same step as checking it.

What happens on torverify's source when a project rotates its address

Projects change onion addresses for reasons that have nothing to do with being compromised — routine key rotation, migrating hosting, or recovering from an unrelated outage. torverify's source is built to handle that as a normal event, not an emergency.

How a rotation gets reflected on torverify

A new address only replaces an old one on this page after the same 2-of-3 verification a first-time listing requires — rotation does not get a shortcut past the quorum just because the project was previously verified. Until that clears, the old address stays listed and the new one stays absent, even if the project itself is already advertising it.

Why the old address isn't silently deleted

During the transition window, torverify would rather show the previous confirmed address than an unconfirmed new one, because a reader mid-transaction with the old address needs continuity, not a page that suddenly goes blank on them. The changeover happens the moment the new entry clears quorum, not before.

What to do if you see a "new" address here that isn't in the list yet

Treat it as unverified until it appears on this page with the rest — a project announcing a rotation on its own channel is not the same as torverify confirming it. Re-check back after a short wait rather than trusting the announcement alone.

Why torverify would rather be slow than wrong on a rotation

A verification reference that rushes to publish a rotated address the moment it is announced is trading rigor for speed — and speed is exactly the pressure a phishing operator wants a reader to feel too. torverify would rather a reader wait an extra day for a new address to clear quorum than trust an unverified announcement because torverify itself moved too fast to keep up appearances.