About NexusWatch
NexusWatch is an independent verification project. We document Tor-network onion addresses associated with the Nexus marketplace, anchor each entry to a cryptographic signature, and publish the result as a research record. We are not affiliated with Nexus Market, we are not authorised to act on its behalf, and we do not provide a connection service to anyone using this site.
What this project exists for
The shortest version: a Tor user looking for a current Nexus address has too many sources and not enough way to tell them apart. Lookalike registrations turn up within hours of a rotation. Stale archives keep pointing at endpoints that have been deprecated for months. Forum posts get edited after the fact. None of those failure modes get fixed by another directory. They get fixed by a registry that publishes its evidence and explains its position.
NexusWatch is built around that registry. Each entry sits next to the cryptographic signature that authenticated it, the timestamp at which our monitoring infrastructure last confirmed the endpoint, and the canary statement that bound the address to the operator at the moment of attestation. If the evidence is missing, the record does not appear on the homepage. It stays in the deprecated archive with a note about why.
Verification methodology
Three source types feed the registry. The first is direct observation, date-stamped, performed through fresh Tor circuits at staggered intervals. The second is cryptographic attestation: PGP signatures pulled from the operator's published canaries, verified against the keyring we maintain across releases, with the previous signing key kept on file for at least one full rotation cycle. The third is published reporting and primary documents, including the operator's own announcements, public canary archives, and forum disclosures that can be cross-referenced against verifiable signing keys.
An address only enters the registry after the cryptographic and observational evidence agree. They have to keep agreeing for the record to remain in the active section: the monitoring cycle is short enough that descriptor churn or response anomalies surface within hours, and any disagreement freezes the record's status until the discrepancy is explained. We do not list an address because someone said it works, and we do not delist one because someone said it does not. Both directions require evidence.
Independence and editorial position
NexusWatch is editorially independent of the marketplace it documents. We did not consult, contract with, or accept material from Nexus Market or any party representing the marketplace before launching this project, and we will not enter any such arrangement during its operation. The reason is operational, not ideological: a directory that owes anything to its subject loses the only thing it has to offer, which is the credibility of an outside record.
That position constrains what we publish and how we publish it. We do not advocate for the marketplace, we do not warn users away from it, and we do not pretend our registry is a substitute for a user's own judgement about whether to connect. The record is the record. What you do with it is your call. The full non-endorsement language, verification limits, and user-responsibility framing live on the research disclaimer and apply to every entry on the verification registry.
Contact and corrections
If you can demonstrate that an entry in our registry is wrong, send the evidence and we will review it on the same standard we use for the original entry: wrong fingerprint, wrong attribution, or wrong status all warrant the same validation cycle as a new submission. We do not provide technical support for connecting to any external platform, and we cannot help with account-level questions or marketplace operations of any kind. Inquiries that fall in that category will be redirected back to the operator's own published channels.
Press, research, and academic correspondence is welcome. The methodology section of this page is the canonical reference for how the registry is maintained, and any specific question about a record can be tied to the timestamp and signature attached to that record.
Methodology references
The verification methodology described above draws on published protocol specifications and reference implementations. These are the canonical documents against which our practice can be audited.
- Tor Project. Tor Rendezvous Specification — Version 3. Hidden service descriptor format and onion address construction used throughout our observation cycle. spec.torproject.org/rend-spec
- Callas, J. et al. RFC 4880 — OpenPGP Message Format. IETF, 2007. Canonical reference for the PGP signature model our canary verification depends on. rfc-editor.org/rfc/rfc4880
- The Tor Project. Tor Metrics. Public network health, relay, and directory-authority data that contextualises our endpoint observation logs. metrics.torproject.org
- The GnuPG Project. The GNU Privacy Handbook. Reference PGP implementation used for keyring maintenance and signature verification. gnupg.org/documentation