The mirror list: how we source and publish onion addresses
This page explains where the addresses on Deep Web Wire come from and how we intend to publish them in a tamper-evident form. It is the plumbing behind the working links table and the individual market records.
One reference set, cross-checked
Every address we show is drawn from a single reference set that we maintain and compare against independent sources. An address earns a place only when it matches that set. When a project rotates, the set is what we update first; the public pages follow. This is deliberately boring: the whole value of a reference is that it changes slowly and only for reasons we can point to.
Toward a signed mirror list
A plain web page can be edited by anyone who controls the server, so the strongest form of an address list is a signed one — a machine-readable file cryptographically signed so that any tampering is detectable by the reader. Our intended format carries a version number, an expiry, and a signature quorum, so a consumer can reject a list that is stale, rolled back, or signed by too few keys.
Why a quorum, not a single key
A single signing key is a single point of failure: lose it, or have it coerced, and the whole list is compromised. A quorum — several independent keys, of which a threshold must agree — means no one key can poison the list alone. That is the model we are building toward, with the signing keys kept apart from the servers that publish the pages.
How to use addresses until then
Exactly as you should use them afterwards: copy the full string, cross-check it against a second independent source, and match it character by character before you connect. A signature makes one of your sources much harder to tamper with; it never removes the need to cross-check. See the PGP and signatures note for the plain-language version, and the Tor Project documentation for how to connect through Tor Browser in the first place.
How to verify a mirror against this list yourself
You do not need to wait for the signed file to run a meaningful check today. This is the same four-step sequence every guide on this wire points back to, applied specifically to a mirror address you found somewhere other than Deep Web Wire.
Step 1 — Find the address on this mirror list or the project's record
Start from a source you already trust
Locate the darknet market's address as published on its Deep Web Wire record or the working links table, rather than starting from the mirror you are trying to check.
Step 2 — Copy both strings in full
No partial strings, ever
Copy the full 56-character onion address from both this list and the mirror you found elsewhere. A shortened or truncated string cannot be compared meaningfully against anything.
Step 3 — Compare character by character
One wrong character is disqualifying
Read the two strings against each other slowly, not at a glance. A single swapped or added character is the entire mechanism behind a copycat mirror — see spotting a fake mirror for the patterns that trip people up.
Step 4 — Only then connect
Verification comes before the click
Only after the strings match exactly should you open the address in Tor Browser. For the full reasoning behind each step, see verifying an onion address before you deposit.
How an address earns a place on this list
Nothing appears on this page because someone submitted it and we took their word for it. Each address is cross-checked against a channel the project itself controls before it is added, and that same check is repeated on an ongoing basis rather than performed once and forgotten.
What "hand-maintained" means while the signed file is pending
Until the 2-of-3 signed JSON ships, this list is maintained manually by comparing each address against independent channels rather than automatically. That is slower than an automated signature check, but it is not less rigorous — it simply has not yet been converted into a machine-verifiable form, and this page says so plainly rather than implying a cryptographic guarantee that is not live yet.
Why this list stays deliberately short
A longer list is not automatically a more useful one if the additional entries were not checked with the same care as the first. This page covers the projects Deep Web Wire can actually stand behind; a project's absence here means it has not been added yet, not that it has been rejected.
Where a new mirror comes from before it reaches this list
A mirror does not appear on this deepweb reference because someone emailed it in. Each candidate mirror is sourced from a channel already tied to the project — its existing verified address, its own operator announcement, or a signed post from a key we have previously confirmed. A mirror surfacing only in a third-party forum thread with no link back to an established channel does not clear this bar, no matter how plausible the string itself looks.
The gap between "circulating" and "on file"
Plenty of addresses circulate for any given project at any given time — some genuine, some not. This page's list is deliberately smaller than the full set of addresses you could find by searching, because "circulating" and "on file here" are different claims. Circulating means someone is sharing it. On file here means Deep Web Wire independently placed it against the project's own established channel.
What happens to a mirror that stops resolving
A mirror is not silently dropped from this list the moment a single check fails. Reachability failures are tracked over a window before an entry's status changes, since a temporary Tor network issue looks identical to a permanently dead mirror from the outside of a single failed attempt. When a mirror is confirmed retired, its entry updates to reflect that plainly rather than simply vanishing from the page.
How this mirrors page relates to the individual market records
This page explains sourcing methodology in the abstract; the individual market records apply it to a specific project's specific addresses, with the copy controls and per-mirror dates this page does not repeat. Read this page to understand the process, and a market's own record to act on it.
Where the same sourcing standard shows up across Deep Web Wire
The reference set behind this mirror list is not a one-off project; the same standard runs through every corner of the site that touches a darknet market onion address.
- The status board reads directly from the same reference set to decide whether a project shows Checking, Unknown or Down.
- The verified onion links page distills this same set down to one primary address per project.
- The warrant canary is the integrity check that sits underneath this entire reference set, confirming Deep Web Wire itself has not been coerced into altering it.
- The news section reports when the reference set actually changes — a rotation, a retirement, a new mirror — rather than publishing on a fixed schedule regardless of whether anything moved.
What a signed file actually changes for a reader
It is worth being precise about what the pending Deep Web Wire signed mirror list will and will not do, since "signed" gets used loosely across this space. A signature does not make an address more real or more official — it makes tampering with the list detectable after the fact, which is a narrower but genuinely useful guarantee.
What a signature proves
Integrity, not identity of the market
A valid signature on the mirror file proves the file has not been altered since it was signed by the quorum of keys Deep Web Wire controls. It does not, on its own, prove any given darknet market's onion address inside that file is correct — that still depends on the cross-checking process described above happening correctly before the file was signed in the first place.
What a signature does not protect against
Garbage in, signed out
If an address were added to the reference set incorrectly, signing the file afterward would not catch that mistake — it would just make the mistake tamper-evident rather than tamper-proof. That is exactly why the signature is planned as an addition to the sourcing discipline on this page, not a replacement for it.
How a reader would actually check the signature
A step this page will document when it ships
Once published, checking the signed file will use the same GnuPG tooling described on the PGP reference page — import the public keys for the quorum, verify the file against them, and only then trust the addresses it contains. Until that flow is live, this page states plainly that it is not, rather than describing a check a reader cannot actually run yet.
Why this list isn't built by scraping other directories
An obvious shortcut for building a bigger mirror list quickly would be pulling addresses from other trackers and directories and republishing them under Deep Web Wire's own reference set. That shortcut is deliberately not taken here, for a reason that matters more than convenience.
Copying an error propagates it with false confidence
If another directory has a stale or wrong address and this list simply copied it, a reader checking two sources that both trace back to the same original mistake would see false agreement — two sources that appear independent but are not. The entire value of "cross-check against a second source" collapses if that second source was never actually independent in the first place.
What this list does instead
Every entry traces back to a channel the project itself controls, not to another aggregator's page. Other independently maintained mirror trackers are useful as a genuine second opinion precisely because this list does not lean on them as a primary source — borrowing from a competitor and then treating the result as independent confirmation would quietly break the whole method.
Frequently asked questions
- Is the signed mirror list live yet?
- No, it is still pending. Until it ships, addresses on this site are maintained by hand against our reference set and shown as plain copyable text rather than a signed file.
- Why a quorum of keys instead of one signing key?
- A single key is a single point of failure. A quorum means no one compromised or coerced key can poison the list alone, which is the model we are building toward.
- Can I trust an address here before the signed list ships?
- Yes, with the same discipline this site always asks for: copy the full string, cross-check it against a second independent source, and match it character by character before connecting.
- How does an address actually earn a place on this list?
- It is cross-checked against a channel the project itself controls before being added, and that check is repeated on an ongoing basis rather than performed once and left alone.
- How does this mirrors page relate to Deep Web Wire's darknet market records?
- This page describes the sourcing pipeline behind every darknet market onion address on Deep Web Wire; each individual market record on Deep Web Wire draws its addresses from the same reference set explained here.