Methodology: how torindex records, checks and words a status

Checking

The entry is one of our own records and is waiting on the live probe feed. We have confirmed the address by hand on the date shown, but there is no automated up or down signal yet.

Unknown

torindex holds no fresh measurement for this market. It is not a verdict. torindex simply refuses to state a status it cannot back.

Seized

A market that law enforcement took control of or shut down. The end date is the public date of the action.

Defunct

A market that stopped operating without a public seizure, whether from an exit or a quiet close.

There is no Online word in normal use. torindex will only write that a market is up when a current, signed probe says so, and that feed is not live yet.

An address becomes a torindex record in two steps. First, torindex reaches it over Tor — the same anonymity network whose own documentation from the Tor Project explains how a hidden-service address resolves in the first place — and confirms it serves the right project, not a copy. torindex then writes it down as text, with the date of that check, and marks the market as one of ours. The date moves only when we run the check again, so a stale date is a signal in itself.

• Reach the address over Tor and confirm the project behind it.
• Record the exact string as copyable text, never as a click-through link.
• Stamp the date of the check and leave it until the next real check.

A hand-kept list still asks you to trust this page. The fix is a two-of-three signature over the address list, so at least two independent keys must agree before an address counts. When that ships, a reader can check the list by machine without trusting the site at all. Until then, cross-check every address against a second channel.

A confirmation is a moment, not a promise

When this methodology says an address is "confirmed reachable," it means a person on our side opened that exact string over Tor on the date shown and saw the expected project respond. It is a point-in-time observation. It says nothing about whether the address will still answer an hour later, and the site never implies otherwise by using a word like Online.

Confirmation is manual, and that is disclosed on purpose

There is no automated 24/7 probe running yet — that is the entire reason the signature layer and a live feed are on the roadmap rather than already shipped. A manually confirmed record with an honest date is worth more than an automated one that silently goes stale, but both are worse than a reader knowing exactly which kind of check produced the date they are looking at. This page exists so that distinction is never hidden.

What a confirmation does not check

Reaching an address and seeing the right project respond does not verify who currently controls that service, does not confirm the market's internal security, and does not vouch for any vendor or listing inside it. It verifies one thing only: this string, on this date, served this project rather than a parking page, a phishing clone, or nothing.

The status vocabulary above — Checking, Unknown, Seized, Defunct — sounds simple until it meets a real, ambiguous situation. The cases below are the ones that actually come up, and how torindex resolves each one without inventing a status word beyond the four it publishes.

A market goes dark with no announcement

Onion services routinely go unreachable for reasons that have nothing to do with the project ending — a relay problem, a host migration, ordinary Tor network flakiness. torindex does not move an entry to Seized or Defunct on a single failed sweep. The methodology requires a sustained pattern across repeated automated checks before a record moves out of Checking, specifically so a temporary blip does not get mislabeled as a market's death.

Two sources disagree about whether a market is still active

When a project's own channel claims it is operating but independent reachability checks keep failing, torindex does not average the two claims into a confident status. The record stays in Checking or moves toward Unknown, with the disagreement itself treated as a reason for more caution, not less — a status word is never upgraded on the strength of a claim torindex cannot independently confirm.

A project has no public verification channel at all

Some candidate addresses surface with no signed mirror list, no operator PGP key, and no consistent public channel to check them against. These entries can still clear the basic reachability bar and earn a Checking status, but they will not reach the stronger, signature-backed tier the roadmap describes until a verifiable channel exists — torindex does not invent one on a project's behalf.

An address rotates without warning

Address rotation is normal operational practice for an active market, not evidence of compromise. When a previously confirmed address stops resolving and a plausible replacement surfaces through the same channel, torindex treats the new address as a fresh candidate subject to the full pipeline rather than assuming continuity automatically — the old address is not silently swapped out for the new one without its own check.

A seizure notice later turns out to be disputed

Law-enforcement takedown notices are usually unambiguous, but where a seizure claim is later disputed or partially retracted, torindex updates the record to reflect the best current public understanding and notes the date of the update rather than leaving a now-contested status unexamined.

Everything above describes the rule; this section describes how torindex applies that rule to one specific onion market record, so the abstract methodology is never disconnected from what a reader actually sees on a page like the torzon record.

Why torindex writes the same fields on every onion market page

Every torindex onion market record — whether it holds one address or five — carries the same fixed fields: category, status, last-checked date, and the address itself as copyable text. torindex enforces that consistency deliberately, because a reader comparing two entries should never have to guess whether a missing field means "not applicable" or "not checked yet." If a field is empty on a torindex record, the surrounding text says why, the way the AlphaBay record explains why it carries no address field at all.

How torindex handles a market that operates under more than one name

Some onion market projects are known by more than one name across different communities — an older abbreviation, a regional nickname, a name a market used before rebranding. torindex records the canonical name it verifies against and notes the alternate names in the entry's own text, the way the wethenorth record notes the older WTN label, rather than creating separate torindex entries for what is actually one project.

What torindex does when its own methodology needs to change

The status vocabulary, the intake pipeline, and the signature-layer roadmap described on this page are not frozen. When torindex changes how it verifies or labels an onion market entry, that change is documented here with a date, in the changelog below, rather than applied silently across the site. A reader who checked this page once should be able to tell, from the changelog alone, whether anything about how torindex verifies an onion market has changed since.

Why torindex publishes this methodology instead of just applying it silently

torindex could run the exact same reachability and diff pipeline described above without ever writing this page, and the master index would look identical to a visitor skimming status words. torindex publishes the method anyway because a status word without a documented method behind it is just an assertion, and torindex's entire independence claim rests on a reader being able to check the assertion rather than take torindex's word for it. Every claim torindex makes about an onion market traces back to a step described on this page — reachability, character-diff, dated confirmation — and torindex would rather a reader distrust a specific torindex record for a documented reason than trust the whole torindex index on faith.

torindex bumps this page's sitemap date only when the content actually changes, in keeping with the honesty standard the methodology itself describes. The entries below are the real, dated changes to this page.

2026-08-24

Added the edge-case section above (dark markets with no announcement, disputed sources, unrotated addresses, disputed seizure claims) and this changelog, to make the practical application of the status vocabulary — not just its definitions — part of the public record.

2026-08-17

Initial publication of the current methodology page: status vocabulary, the address-intake pipeline, and the two-of-three signature layer roadmap.