torhaven: learn the dark web the safe way, one plain guide at a time (2026)

Start the torhaven fundamentals

New readers do best in a fixed order: understand what Tor actually hides, learn to read a real onion address, then set up the two tools that do the heavy lifting, PGP and Monero. The torhaven guides below are written so you can read one in a single sitting and come away able to do the thing, not just describe it. This section walks each one in a little more depth than the card alone shows, so you can decide where to start before you click through.

What is PGP, and why it matters

PGP is the one skill on this list that separates a safe habit from a hopeful one. It lets you prove that a message, a signed mirror list, or an onion address really came from whoever holds the matching key, without either side sharing a secret in advance. The torhaven guide walks the public/private key pair, the difference between encrypting and signing under the OpenPGP standard, and a worked example using GnuPG you can follow with real commands rather than a diagram alone. Read it before you trust any address you did not type yourself. Read the PGP guide →

Verify an onion address before you deposit

This is the short routine we ask you to run every single time, before money moves: pull the address from a signed source, compare all 56 characters by hand, and only then paste it into Tor Browser. It takes under a minute once it is a habit, and it is the single check that stops a look-alike address from costing you a deposit. The torhaven guide covers what a signed record looks like and what to do when one is not available yet. Read the verification guide →

Is Torzon legit? An honest read

Our first torhaven market profile, built to the same standard as the torhaven guides: what the name Torzon actually refers to, what we can and cannot independently confirm about it, and the exact steps to check its current address yourself rather than take our word or anyone else's. It is a profile, not an endorsement, and it says so throughout. Read the Torzon profile →

Coming next: Tails, Monero, and a glossary

Three more torhaven entries are in progress and will follow the same rule as everything already published — nothing goes up until it is checkable. Tails vs Whonix will compare the two amnesic systems by threat model rather than by tribal preference. Using Monero without leaks will cover buying, holding, and spending XMR while keeping the trail cold. A plain-English glossary will define escrow, multisig, finalize-early, exit scam, and the other terms that recur across every guide, in one place, once.

Why torhaven publishes guides one at a time instead of all at once

A handbook that ships twelve guides on launch day and then goes quiet for a year is a common pattern on the clearnet, and it usually means most of those twelve were written quickly to fill out a table of contents rather than checked properly. torhaven publishes fewer guides, more slowly, because each one has to clear the same source-checking bar before it goes up. Three published guides that are each individually reliable are worth more than twelve that are not, and the "in progress" cards above exist specifically so that gap is visible rather than papered over with a placeholder page.

Who this torhaven handbook is for

This torhaven handbook is written for someone opening Tor Browser for a genuinely first time, not for someone who already knows what a hidden service is and just wants a link. If a term like "onion address" or "PGP fingerprint" is unfamiliar, this torhaven handbook assumes that and explains it before using it again. If those terms are already second nature, the guides here will move slowly for you — that trade-off is deliberate, because the reader most at risk from a bad first step is the one least equipped to spot it.

What we assume you already know

Almost nothing, on purpose. We assume you can install software and follow a numbered list, and that is close to the full list. Where a guide needs a concept from an earlier guide, it links back rather than repeating the whole explanation inline, so the site holds together as a sequence even though each page also stands on its own if you land on it directly from a search result.

What this torhaven handbook is not trying to be

This is not a market comparison site, a vendor directory, or a place to find "the best" anything. Readers looking for that will not find a ranked list here, because a ranked list of darknet markets is exactly the kind of claim this torhaven handbook cannot verify honestly. What it offers instead is narrower and, we think, more durable: the specific skills torhaven actually teaches — PGP verification, onion-address checking, threat-model-appropriate tool choice — that stay useful regardless of which market or service you eventually decide to use them on.

Reading torhaven safely in the first place

This torhaven site is a clearnet page, reachable without Tor, which is deliberate — a safety handbook that can only be read after you have already made every decision it is meant to inform would defeat its own purpose — the same reasoning behind resources like the Electronic Frontier Foundation's Surveillance Self-Defense guide, published openly rather than gated behind the tool it teaches. That said, once you move from reading here to actually visiting a market or checking a mirror, that step belongs inside Tor Browser, not on the clearnet. Our own torhaven guides walk that transition explicitly rather than assuming a reader already knows where the line is.

Name what you are protecting against before you protect anything

The single most useful habit this torhaven handbook can hand a new reader is not a tool. It is the question that comes before every tool: who or what am I actually worried about here? Security advice given without that question attached is how people end up running elaborate precautions against something that was never a risk to them while leaving the thing that was wide open. Three rough pictures cover most readers, and each one points at a different part of this handbook.

You do not want your connection observed

The concern is that whoever provides your connection, or anyone else watching the line, can see which sites you open. This is the problem Tor was built for, and it is the one it solves most completely: what a network observer sees is that you are using Tor, not where you went. If this describes you, the network guide and the safe-install guide are the whole of what you need, and the rest of the handbook is background rather than homework.

You are worried about being cheated

The concern is not surveillance but loss — a look-alike page, a swapped address, money sent somewhere it cannot be recalled from. Routing does nothing for this, because nothing is being intercepted; you are being handed the wrong destination and walking to it yourself. The countermeasures are verification habits: reading an address from a source that can prove it wrote it, checking a signature, comparing a string in full. This is the largest category of real harm we see people describe, and it is also the most preventable, which is why torhaven's verification guide is written as a routine you repeat rather than a concept you understand once.

Someone specific is interested in you

The concern is a party with resources, patience and a reason to care about you in particular. This is a genuinely different problem, and honesty requires saying that a clearnet handbook is not sufficient for it. What changes at this level is that the endpoint matters as much as the network: an amnesic operating system that forgets everything at shutdown, strict separation between identities, and a discipline about what is ever typed on which machine. torhaven can point at the right questions here; it cannot pretend that reading a few guides settles them.

Why this ordering matters more than any individual tip

Most people arrive somewhere between the first and second picture and mistakenly buy defences suited to the third, or — far more often — adopt the vocabulary of the third while skipping the plain verification habits that would have covered the second. A reader who has named their own concern can tell which advice on this site is load-bearing for them and which is background reading, and that judgement is worth more than any single technique the handbook contains.

Amnesic systems and the persistence trap

Once a reader is past the first two threat pictures, the next real decision is not which browser add-on to install but which machine state they are working from. Tor protects the path a request takes across the network. It does nothing whatsoever about what your own computer writes to its own disk while you use it, and that gap is where most avoidable trouble actually lives. The two systems people reach for here — Tails and Whonix — solve that gap in genuinely different ways, and the choice between them follows from the threat model you named above rather than from which one a forum prefers.

What amnesia actually buys you

An amnesic system runs from removable media or from memory and deliberately forgets everything when it shuts down: browsing history, downloaded files, wallet state, shell history, the swap file, thumbnails, the small clutter a normal operating system generates constantly without being asked. The benefit is not mystical. It is simply that a machine which never wrote something down cannot later be made to produce it, whether the party asking is an intruder, a repair technician, or somebody with a warrant. Against a network observer this changes nothing at all; against anyone who ends up with physical access to the device, it changes almost everything.

Tails: one session, then nothing

Tails boots from a USB stick, routes all traffic through Tor by design rather than by configuration, and wipes memory on shutdown. Its appeal is that the safe path is the default path: there is no setting to forget to enable, and there is no second, leakier browser sitting one click away. Its cost is friction. Every session starts from a clean slate, so anything you actually need to keep — keys, notes, bookmarks — has to be deliberately re-established or deliberately persisted, and it is that second option where the model tends to quietly break.

Whonix: isolation rather than forgetting

Whonix takes a different route. It splits the work across two virtual machines: a gateway that does nothing but run Tor, and a workstation that has no way to reach the network except through that gateway. Even software that actively tries to bypass Tor on the workstation has nowhere else to send packets, which is a stronger guarantee against application-level leaks than a single-machine setup can offer. What Whonix does not do by default is forget. It runs on a host that keeps a disk, and the durability that makes it comfortable for long-running work is exactly the durability an amnesic system is designed to refuse.

Persistent storage is where the model breaks

Persistence is the feature most new users enable first and understand last. Turning on an encrypted persistent volume in an amnesic system is a rational choice for keeping a key you genuinely cannot regenerate. The trap is scope creep: persistence starts holding a keyring, then a notes file, then a browser profile, then a download folder, and at some point the system is no longer amnesic in any meaningful sense — it is an ordinary encrypted laptop with extra steps and a false sense of having been handled. The honest rule is to persist the minimum you cannot reconstruct, review that set periodically, and remember that an encrypted volume protects a powered-off machine, not one sitting unlocked on a desk.

Choosing between them without tribalism

If the machine itself may fall into someone else's hands, favour amnesia. If the risk is a compromised application phoning home outside Tor during long sessions, favour isolation. If both concerns apply, the two are not mutually exclusive — people do run Whonix on top of an amnesic host — but complexity has its own failure rate, and a simple setup you operate correctly beats an elaborate one you half-configure. Neither system, it is worth stating plainly, protects a user who then logs into a personal account, reuses a password, or writes something identifying into a form. The operating system covers what the machine records; nothing covers what a person types.

Coins that remember, and coins that forget

Payment is the step where the largest share of avoidable de-anonymisation happens, and it happens for a structural reason rather than through anyone's carelessness. Most people arrive with Bitcoin because Bitcoin is what exchanges sell most readily, and Bitcoin was never designed to be private. Understanding that difference clearly is worth more than any specific tool recommendation, because tools change and the underlying property does not.

Bitcoin is a public ledger, and that is the whole problem

Every Bitcoin transaction ever made is published permanently and readable by anyone. Amounts are visible, addresses are visible, and the links between them are visible. Nothing on that ledger carries your name, which is why the word "anonymous" attached itself to Bitcoin early and never quite came off — but pseudonymity is not anonymity, and the gap between them closes the moment any single address is tied to an identity. Since a regulated exchange collects identity documents before it will sell you anything, that link usually exists from the very first purchase, and chain-analysis firms exist specifically to walk outwards from such links. Bitcoin does not forget, and the analysis of it only gets better over time, which means a transaction that looks unremarkable today is still sitting there to be re-examined later with better tools.

What Monero changes

Monero was built the other way round: privacy is the default and there is no transparent mode to fall back to. Amounts are cryptographically hidden, the true sender is concealed among decoys, and each payment goes to a one-time address derived for that transaction, so there is no reusable public address on the ledger to cluster. The practical result is that the kind of graph-walking that works on Bitcoin has far less to work with. This is not a promise of invulnerability, and anyone claiming a coin makes you untraceable is overselling it — endpoints, exchange records, timing and plain human habit all remain. But the default posture differs sharply, and defaults are what most users actually live with.

The BTC→XMR step is where privacy is usually lost

The common path is to buy Bitcoin on an identity-verified exchange, convert it to Monero, and spend from there. The conversion is the sensitive moment, not the spending. If the conversion happens on a service that keeps records tied to your account, the privacy gained afterwards is only as good as that service's logs and its willingness to keep them private. Points worth thinking through before, not after: whether the service required identity documents; whether it retains a record linking the incoming Bitcoin to the outgoing Monero; whether the amount was distinctive enough to be matched by size alone; and whether the transfer happened minutes after a deposit, making it trivial to correlate by timing. Rounding amounts to memorable figures and moving funds immediately are the two habits that most often undo the rest.

Wallets, receipts and the trail you keep yourself

A meaningful amount of what gets people identified is not on any blockchain at all. It is a wallet file synced to cloud backup, an exchange confirmation email sitting in a personal inbox, a screenshot in a photo library, a browser password manager holding an exchange login next to a real-name account. Blockchain privacy is only the part of the trail that is public; the rest is on your own devices, and it is the part you control completely. When a guide on this handbook talks about keeping the trail cold, that is as much about what your laptop and your inbox retain as about which coin you chose.

Escrow, multisig, finalize-early and the shape of an exit scam

Everything above concerns being watched. This section concerns being robbed, which as noted earlier is the far more common outcome and the one plain habits actually prevent. The vocabulary here recurs constantly and is rarely explained honestly, so it is worth defining once in plain terms.

What escrow is supposed to do

Escrow means the payment is held by the platform rather than passed straight to the seller, and released only once the buyer confirms the order arrived. The intended effect is symmetry: the seller cannot simply take the money and vanish, and the buyer cannot receive goods and then refuse to pay. The unavoidable weakness is that escrow moves the trust rather than removing it. Funds now sit with the operator, so escrow protects a buyer against a dishonest seller and does nothing at all to protect either party against a dishonest operator. Any discussion of escrow that stops before that sentence has skipped the important half.

Multisig moves the trust further out

Multisignature escrow splits control of the funds across several keys — typically buyer, seller and platform — and requires two of the three to authorise a release. The operator alone cannot move the money, because one key is not enough. That is a real structural improvement over ordinary escrow, and it is also more work: keys must be generated and kept, partially-signed transactions handled correctly, and a lost key can strand funds nobody can then release. Multisig implementations also vary in quality, and a badly built one can be worse than none while feeling safer. The pattern to be wary of is a platform advertising multisig prominently while quietly defaulting every order to ordinary escrow.

Finalize-early hands your leverage away

Finalizing early means releasing payment before the goods arrive. Sometimes it is framed as a courtesy to an established seller, sometimes as a requirement to access certain listings, and sometimes it is simply the only option offered. Whatever the framing, the mechanics are the same: the moment funds are released, the buyer has no dispute leverage left and no path to recovery, because there is nothing left to hold. Pressure to finalize early — a story about platform fees, a claim the seller cannot ship otherwise, a deadline — is a pressure tactic regardless of whether the person applying it intends fraud, and it should read as a warning sign rather than as a favour asked.

What an exit scam looks like before it completes

An exit scam is a platform accepting deposits it never intends to honour, then disappearing with the balance. It rarely arrives without warning, and the warnings are behavioural rather than technical. Withdrawals start taking longer and support explains it as maintenance. Escrow releases slow while deposits stay instant. New rules appear pushing users toward finalize-early or direct payment. Announcements grow more frequent and more reassuring. None of these individually proves anything, and each has an innocent explanation available, which is exactly why they work. The defensive posture that survives all of it is unglamorous: keep no balance you are not actively using, treat any platform wallet as temporary storage rather than an account, and let a withdrawal problem change your behaviour immediately rather than after you have confirmed the worst.

Checking where you are before any of this matters

Every protection described above assumes you are on the platform you believe you are on. A look-alike front-end can render a perfect escrow interface and a convincing multisig page while controlling both. This is why the verification routine comes first in the reading order and why we ask for a second independent reading of an address rather than one. Project-maintained reference pages serve that second reading — the WeTheNorth verification archive keeps that project's current address and mirror history in one place, and the Torzon access guide does the same for Torzon — and the point of naming them is not that any single page deserves your trust, but that reading the same 56-character string from two independent places is a far stronger check than reading it once. Torzon's address is published as torzonguqmlfy2kfi5tjbnt4bp3idtkjzi4qtupmhpdihjftomjtdzqd.onion and WeTheNorth's as hn2paw7hljeihrk7qm2toniay5bb4cfz46cav5iywnsv64klm45mypqd.onion; both are shown here as plain selectable text precisely so you can compare them character by character against whatever source you check next, which is the only comparison that means anything.

Clipboard poisoning and browser-side safety

The last category of harm covered here happens entirely on your own machine, after every network-level precaution has already worked correctly. These attacks are unglamorous, they do not require breaking anything cryptographic, and they succeed constantly because they exploit a habit rather than a flaw.

Address swapping happens on your computer, not theirs

Clipboard poisoning is a piece of malware that watches for a cryptocurrency address being copied and silently replaces it with the attacker's own before you paste. Nothing on the remote site was compromised; the address you were shown was genuine, and the address that landed in the payment field was not. Cryptocurrency addresses defeat human verification by design — they are long, random-looking and visually similar at a glance — and the standard shortcut of checking only the first four and last four characters is the exact check that generators of look-alike addresses are built to satisfy. The defence is to verify the pasted string in full, in the field, immediately before confirming, and to be more suspicious rather than less when an address looks reassuringly familiar. The same discipline applies to onion addresses: the point of showing a hidden-service address as selectable text on a page like the Mars access reference, which publishes marskp4ozu3nv2ez3in5ofyukovali7o5ioxyuvubeus74cu2bjl5nid.onion as plain text, is that a reader can compare it against another source rather than trusting a button that copies something invisible.

Why JavaScript is the default risk

JavaScript is not malicious in itself, but it is the mechanism by which a page gets to run code on your machine, and almost every practical de-anonymisation of a Tor Browser user in the historical record involved a scripted exploit rather than a break in Tor itself. Script also enables fingerprinting: fonts, canvas rendering, screen dimensions, timing behaviour and dozens of other signals that combine into something recognisable across visits, regardless of your circuit. Tor Browser's security levels exist precisely to trade functionality for this exposure, and its Safest level disables JavaScript on non-HTTPS sites and much else besides.

What raising the security level actually breaks

Being honest about the cost matters, because a recommendation people abandon in practice is worth nothing. On the strictest setting some sites will not render, some login flows fail, images may not load, and interfaces that depend on script will simply appear broken. The temptation is then to lower the level "just for this one site", which quietly becomes the permanent setting. A better habit is to decide the level per activity rather than per annoyance: highest for anything involving money or a login, relaxed only for reading pages where nothing is at stake. A site that cannot show you a plain address without executing script is telling you something about itself worth hearing.

Downloads and documents open outside Tor

A file downloaded through Tor Browser is safe only while it stays a file. Opening a document, spreadsheet or PDF in an ordinary desktop application hands it to software that will happily fetch remote content over your normal connection, revealing your real address in the process. This is the classic decloaking trick and it needs no exploit at all — it is documented behaviour of office software working as intended. Anything downloaded over Tor should be opened in an offline environment or an amnesic system disconnected from the network, which is one of the more concrete reasons the operating-system section above is not merely theoretical.

The habits that survive every tool change

Tools change, interfaces are redesigned, and specific advice ages. What does not age is a small set of habits: verify a destination from two independent sources before money moves, read a pasted address in full rather than by its ends, keep the browser's security level high for anything consequential, never open a downloaded document on the same system you browse from, and keep no balance anywhere you are not actively using. None of these require expertise. They require only that you do them on the ordinary day, because the day you need them will not announce itself in advance.

How to read the torhaven handbook

Read a torhaven guide the way you would read a recipe you actually intend to cook, not a magazine feature you skim once. The value is in doing the thing, so keep Tor Browser open in another window and try each step as you reach it. A concept you only nodded along to will not be there when you need it under pressure, and the moment you need this material is rarely a calm one.

You do not have to read everything, and you certainly do not have to read it in one go. If you have a specific worry, jump straight to the guide that names it. If you are starting cold, the three fundamentals above are enough to get you to a footing where the rest makes sense. What we ask is only that you treat a claim on torhaven as an invitation to check, not a conclusion to accept, because that habit is the actual subject of the whole site.

The four-step reading method this torhaven handbook assumes

1. Pick one gap, not the whole site. Start from whichever guide answers the question actually in front of you right now, rather than reading top to bottom out of a sense of completeness.
2. Open the tool the guide describes before you start reading. A verification step read in the abstract is easy to nod along to and hard to actually remember; doing it once while reading fixes that.
3. Follow every step in order, including the ones that feel obvious. The obvious-feeling steps are usually the ones a look-alike page counts on a reader skipping past.
4. Treat the guide's own claims the same way it asks you to treat everyone else's. If a guide points you to a signed source, go check that source yourself rather than trusting the guide's description of it.

None of these four steps are unique to torhaven — they are just what actually verifying something over Tor looks like, written down once instead of relearned by every reader the hard way.

How the torhaven guides connect to each other

The three published torhaven guides are not three unrelated articles that happen to share a footer — they form a sequence a new reader would actually follow. The PGP guide teaches the verification skill; the onion-address guide applies that skill to the specific 56-character string you are about to trust; the Torzon profile applies both to one real, named project, so the abstract steps land on something concrete rather than staying theoretical.

Why the Torzon profile comes third, not first

Reading a market profile before understanding PGP and onion verification would mean taking our word for the profile's own claims, which is exactly the pattern this torhaven handbook is built to avoid. By the time a reader reaches the Torzon profile, they have the tools to check its claims independently rather than trust them because we wrote them down.

What the torhaven "in progress" guides will slot into

Tails vs Whonix and Using Monero Without Leaks extend the same sequence sideways rather than starting a new one: operating-system choice and payment handling are both decisions a reader makes once they are past basic verification, not before it. The glossary is different in kind — a reference page meant to be linked from inside the others rather than read start to finish on its own.

Following torhaven's own links instead of a search result

Every internal link on this torhaven site points to a page we ourselves checked and published, which is a smaller guarantee than it sounds like but a real one: a link from one guide here to another has not passed through a third-party aggregator or a possibly-stale search index in between. Following the in-page links as you read is the fastest way through the sequence, faster and more reliable than searching for each next topic separately.

Why torhaven runs no ads or affiliate links

An affiliate link pays out when a reader clicks through and takes an action on the other end — registers, deposits, buys. That payment structure creates a direct incentive to describe the destination more favorably than an honest assessment would, even for someone who starts out with good intentions, because the income depends on the click happening. This torhaven site carries no such link anywhere on it, which is a claim you can check yourself: view the source of any page and look for a tracking parameter, a referral code, or a redirect chain on an outbound link. There is not one.

What this costs, and what it buys

The honest cost is that torhaven has no revenue model tied to traffic or clicks, which means no budget for the kind of promotion an affiliate-funded site can afford. What it buys in exchange, in the same spirit as independent projects like Privacy Guides, is a page that has nothing to gain from telling a reader a market or a tool is safer than it actually is — the incentive that produces so much of the misleading content a new Tor user runs into elsewhere simply does not exist here.

How this differs from a paid review

A paid review discloses payment and hopes the reader discounts the review accordingly; our approach is to remove the payment entirely rather than disclose around it. Where the Torzon profile describes a real project, nothing about that description changes based on any relationship with the project itself, because there is no such relationship to influence it.

What would need to change to add advertising

We are stating this plainly rather than leaving it implied: if this torhaven site ever accepted advertising or affiliate revenue, that change would be disclosed on this page and in the editorial policy, not introduced quietly. Readers checking back on this section later have a concrete claim to hold the site to, not just a vague promise of good intentions.

What torhaven will not publish

Some content categories are excluded on purpose, not because we have not gotten to them yet. Naming them plainly is part of the same checkable-source standard the rest of torhaven holds to.

Numeric trust scores or star ratings, and why torhaven skips them

A single number implies a precision no outside site can honestly claim about a darknet market's internal reliability, dispute rate, or vendor quality. We will describe what can be verified — an onion address, a PGP fingerprint, a reachability history — and will not compress that into a score alongside things that cannot be verified from outside.

Ranked "best markets" lists

A ranked list implies a comparison methodology applied consistently across every entry, and in practice most such lists on the clearnet are either unmaintained, paid placement, or both. Our Torzon profile is a single-project honest read, not the first entry in a league table, and no such table is planned.

Vendor-level content

Individual vendor accounts, their history, and their reputation live entirely inside whichever market they operate on and are not independently verifiable from a clearnet reference page. We write about markets and tools at the level a clearnet page can actually check, not about vendors, which it cannot.

Time-sensitive claims without a live probe

A statement like "this mirror is currently reachable" ages within hours on a Tor hidden service, and we do not run a live monitoring feed the way a status-tracker site does. Where reachability matters, guides point to the signed directory and the signature checker linked in the footer rather than asserting a status we cannot keep current ourselves.

Common questions about torhaven

Is torhaven a market or a directory?

No. torhaven is a reading library. It does not sell anything, does not list vendors, and does not rank markets. Where it discusses a specific project, such as the Torzon profile, it says plainly what is confirmed and what is not. If a page on this torhaven site ever reads like it is selling you something, that is a bug in the writing, not the intent, and worth flagging.

Why does torhaven have no ads or affiliate links?

Because both create an incentive to say a thing is safer than it is. A handbook that gets paid per click has a reason to keep you clicking; torhaven does not, and that absence is meant to be checkable the same way an onion address is — look at the page, there is nothing to click that earns anyone money.

How often is a torhaven guide updated?

Guides are revised when the underlying facts change — a tool's interface shifts, a verification step becomes outdated, a linked directory moves. There is no fixed schedule beyond that; a page that has nothing new to say stays as it is rather than being padded for the sake of a refresh.

Can I suggest a topic for a new torhaven guide?

The three torhaven guides marked "in progress" reflect the current priority queue, chosen by what readers ask about most. There is no public submission form yet, in keeping with the same checkable-source standard applied to everything else on the site.

Is torhaven affiliated with Torzon or any market it writes about?

No. We have no financial or operational relationship with Torzon or any other project covered here. The Torzon profile is written to the same independent standard as every other guide on the site, and it says explicitly where its confidence is limited rather than implying insider access it does not have.

Why is the site called torhaven instead of something more descriptive?

"Haven" was chosen for what the site is meant to be: a calm, stable place to read before acting, in contrast to the urgency that phishing pages and rushed forum threads tend to manufacture. The name is a statement of intent, not a claim of official status with the Tor Project or any market.

What to do if a torhaven guide here turns out to be wrong

Treat it the same way this torhaven handbook asks you to treat any other claim on the internet: check it independently before acting on it, and do not assume a page's careful tone is proof of its accuracy. Our editorial policy describes what happens when that occurs; the short version is that a factual error gets corrected on the page itself, not quietly buried, once it is confirmed.