Editorial policy
How torhaven sources, dates and corrects what it publishes (2026)
A guide is only worth reading if you can tell where it stands. This page sets out the rules we hold ourselves to, so you can judge our work by them rather than by our word. It is a working policy, not a marketing statement, and it is written to be specific enough that a reader could actually catch torhaven failing to follow it.
On this page
On this page
What earns a torhaven page its place
Before anything goes up on torhaven it has to be checkable. We prefer claims you can test yourself, sources that carry a signature, and steps you can follow to the same result we did. If a claim on torhaven rests only on our say-so and cannot be confirmed by the reader, it is a weaker torhaven claim, and we either strengthen it or leave it out. That standard is why the library grows slowly rather than in bulk.
What "checkable" excludes
It rules out screenshots offered as proof of anything, secondhand claims repeated without a primary source, and any statistic we cannot trace back to a method. If torhaven cannot show its working, the torhaven claim does not appear, however useful it would be to include.
What "checkable" allows, even when it is uncomfortable
A checkable claim is not always a flattering one. If the evidence points to a market's escrow process being weaker than advertised, or a security practice being outdated, the torhaven checkability standard requires us to say so plainly rather than soften it for the sake of a more agreeable page. Uncomfortable and checkable beats comfortable and unverifiable every time this policy is applied.
How torhaven handles onion addresses
torhaven shows onion addresses as plain text, never as a clickable link, and always as a teaching example rather than a live directory entry. There are two reasons. First, an address is 56 characters long for a reason, and the safe habit is to read and compare every one of them, which a button hides. Second, the source of record for addresses is the signed directory, not a guide, so we point you there rather than pretending to be it.
The rule in one line
We publish addresses so you can learn their shape and copy them by hand, and we send you to a signed source to confirm them. We do not ask you to trust a link we handed over.
Why torhaven never certifies a market as safe
No honest source can promise that a darknet market will treat you fairly, because there is no regulator behind it and no recourse if it does not. So torhaven does not use words like trusted or safe about any market, and we are wary of anyone who does. What we will do is help you confirm you are reaching the real address and protect the step you cannot undo. Everything past that is a risk we describe rather than a risk we underwrite.
What torhaven does instead of a trust rating
Rather than a single score, a torhaven market profile separates what can be independently confirmed — the signed onion address, whether it has changed recently, how a specific dispute mechanism is described to work — from what cannot, such as whether staff actually resolve disputes fairly in practice. Collapsing both kinds of claim into one number, the way a star rating does, hides exactly the distinction a careful reader needs. Our Torzon profile is written to that standard: readable at a glance for what is confirmed, explicit about what is not.
Why "verified address" is not the same as "safe to use"
Confirming an onion address matches a signed source only tells you that you reached the operator's real service, not that the operator will behave honestly once you are there. torhaven treats those as two entirely separate claims on purpose. A guide can say plainly that an address is confirmed while saying, in the same breath, that nothing about the market's internal conduct can be confirmed the same way. Conflating the two is exactly the kind of false precision this whole policy exists to rule out.
Dates and freshness
Each torhaven guide carries a last-verified date, and that date means what it says. We move it only when the page was actually reviewed or changed, not on a schedule and not to look fresh for a search engine. A date that drifts upward while the words stay the same is a small lie, and small lies are how trust leaks away.
What triggers a review
A tool's interface changing, a linked directory moving, or a reader flagging something that no longer matches reality — any of those is enough to pull a guide back for a pass. We do not run a review on a fixed calendar interval, since that produces edits for their own sake rather than in response to something actually changing.
Why torhaven does not batch-update dates
It would be easy to script a monthly pass that bumps every torhaven guide's date whether or not the content changed, and it would make the whole library look more current than it is. torhaven deliberately does not do this: a date only moves when the words underneath it moved with it. A reader who sees an old date on a torhaven guide is seeing an honest torhaven signal that nothing material has changed, not neglect.
Who reviews a torhaven guide before it goes live
No torhaven guide goes live straight from a first draft. Each one passes through the same checkability standard described above, checked specifically against whether every claim in it can be traced to a primary source or is explicitly marked as uncertain. This is a process standard applied consistently rather than a claim about any individual credential, and it is the same standard whether a guide is about PGP fundamentals or a specific market's onion address.
What happens when a claim cannot be verified
If a claim cannot be traced to something checkable in the time available, it does not get softened into a vague generality and published anyway — it gets left out, or the guide states outright that the point is unverified. A torhaven guide with a gap it admits to is worth more than one that papers over the gap with confident-sounding prose.
Independence and money
There is no advertising on torhaven, no torhaven affiliate revenue, and no paid placement. Nobody can buy a kinder description or a higher spot, because there is no spot to buy and no ranking to sell. This is stated on the about page as well, and it is repeated here because it is the single fact that shapes everything else on the site.
Why this policy repeats what the about page already says
The torhaven independence claim appears on both pages on purpose, not by oversight. The about page states it as a fact about torhaven; this policy states it as a constraint the editorial process is built around, and specifically as the reason certain reviewing steps exist. A reader who only trusts one of the two pages should still land on the same conclusion either way.
Corrections
If a torhaven page is wrong, tell us and we will fix it, and the fix will be visible in the date rather than quietly slipped in. A correction is not a failure of the process, it is the process working. We would far rather carry a visible correction than an invisible error, and we treat a reader who catches a mistake as doing us a favour.
What a correction on torhaven actually looks like
A material correction updates the guide's date and, where the change is substantive enough to matter to someone who already read the old version, adds a brief note near the top describing what changed and when. Small wording fixes that do not alter meaning do not necessarily carry a visible note, but they still move the date, since the date's job is to say "this was checked," not "this changed dramatically."
What we link to, and what we do not
torhaven links to the tools that do the jobs we do not: the signed directory at torindex for the canonical list, and torverify for checking signatures and addresses. torhaven does not carry sponsored links, and does not link to a market as a recommendation. A link from us means the destination is useful for verifying something, not that we vouch for what you find there.
Primary sources a torhaven guide is checked against
The "checkable against a primary source" standard above is not an abstract phrase. In practice it means a torhaven guide about the network itself is checked against the Tor Project's own documentation, not a summary of it found on a forum. A guide about PGP is checked against the OpenPGP standard and the behaviour of GnuPG, the implementation most readers will actually install. Where a topic overlaps with general digital-safety practice rather than Tor specifically, we cross-check against material like the Electronic Frontier Foundation's Surveillance Self-Defense guide, which applies a comparable checkable-sourcing standard to a wider set of tools.
Why torhaven names its sources instead of just citing "research"
A guide that says "research shows" without naming what it checked against is asking for the same blind trust this whole policy is built to avoid. When a torhaven guide states a fact that came from the Tor Project's documentation, GnuPG's manual, or a comparable primary source, naming that source is not decoration — it is the part of the claim a skeptical reader can actually go verify. A claim we cannot trace to a named source this specifically is a claim we treat as unverified, per the standard set out above.
What happens when a primary source itself changes
Software and standards move. If the Tor Project changes a recommended security setting, or GnuPG's default behaviour shifts between versions, a torhaven guide built on the old behaviour is now describing something that no longer matches reality, even though nothing on torhaven itself was edited. This is one of the review triggers described under "Dates and freshness" above — a torhaven guide gets pulled back for a pass not only when a reader flags something, but when the underlying primary source it was checked against has itself moved.
Common questions about this policy
Does torhaven ever remove a guide entirely rather than correcting it?
Rarely, and only if a guide's underlying premise turns out to be wrong rather than merely out of date. When that happens, the page is replaced with a note explaining why, not silently deleted.
How can a reader tell if a torhaven guide is out of date?
Check the last-verified date against how fast the specific topic moves. A PGP fundamentals guide ages slowly; a specific market's mirror status ages fast, which is exactly why we send that kind of claim to the live directory instead of hosting it here.
Does this editorial policy apply to every page on torhaven, including this one?
Yes. This policy page is itself dated and revised under the same rule as every guide it describes.
What should I do if I find an error torhaven has not caught?
Treat it the way this policy asks readers to treat any unverified claim: flag the specific line, not just a general impression that "something feels off," since a specific claim is what we can actually check and correct.
What primary sources does a torhaven guide actually get checked against?
It depends on the topic: the Tor Project's own documentation for network guides, the OpenPGP standard and GnuPG for PGP guides, and comparable primary material for everything else. See the "Primary sources" section above for the full breakdown.
Does torhaven update a guide when the primary source it was checked against changes?
Yes. A changed primary source — a new Tor Project recommendation, a GnuPG default that shifts — is one of the triggers that pulls a torhaven guide back for review, the same as a reader flagging an error.