Why one market publishes several addresses
New users almost always read a list of three onion addresses as a sign that something is wrong. It looks like duplication, or like someone is hedging. It is neither. Running several addresses in parallel is the ordinary way a hidden service stays reachable, and understanding why makes the rest of this handbook easier to follow.
#A hidden service is not a server
The mental model most people bring from clearnet is that an address points at a machine. Type the name, a lookup turns it into a number, the number is a box in a rack somewhere. Onion addresses do not work that way. An onion address is a public key. The service proves it holds the matching private key by publishing a signed record, called a descriptor, into a rotating set of directory nodes. A client that wants to reach the service fetches that descriptor, learns which relays the service is currently listening behind, and builds a circuit to meet it there.
That indirection is the whole point. Nobody along the path learns where the service physically is. It also means the address and the machine are only loosely coupled. The same backend can sit behind several addresses at once, and a single address can be moved to entirely different hardware without anyone noticing. When you switch from one Nexus mirror to another you are not switching to a different market. You are taking a different route to the same place, and your account, your orders, and your balance follow you because they were never tied to the route in the first place.
#What actually breaks
If the backend is shared, why would one address work while another does not? Because almost everything that goes wrong on Tor goes wrong in the path, not at the destination. The failure modes are separate per address even when the service behind them is identical.
| Descriptor publish failure | The service failed to get its current descriptor into the directory nodes, or your client fetched a stale copy. The service is running fine. Your client simply cannot find the meeting instructions. This resolves on its own within an hour and is by far the most common cause of a single address going quiet. |
|---|---|
| Introduction point churn | Every hidden service picks a handful of relays to act as introduction points. Relays go offline, get overloaded, or drop out of consensus. While the service is picking replacements, connections to that address fail or hang. |
| Targeted flooding | An address that has been public for a long time accumulates attention. Someone pointing large volumes of junk traffic at one address degrades that address specifically. A newer address that has not been scraped as widely absorbs the same period without noticing. |
| Your own circuit | Sometimes nothing is wrong anywhere except the particular path your client built. A slow or failing relay in the middle produces timeouts that look exactly like the service being down. Building a new circuit, or trying a different address, sidesteps it. |
Read that list again and notice how much of it is per-address rather than per-market. That is the argument for publishing more than one. The probability that all three addresses are affected by unrelated path problems at the same moment is much lower than the probability that any one of them is. Redundancy here is not about capacity, it is about the failure modes being independent.
#Why not just one very reliable address
Because reliability of this kind cannot be bought. On clearnet you can put a service behind several data centres, add anycast, and buy your way to a very high uptime number. The equivalent levers do not exist for a hidden service. You cannot pay the directory system to prioritise your descriptor. You cannot pick better introduction points than the ones consensus offers you. You cannot stop someone from flooding an address they already know.
What you can do is publish several addresses and let users move between them. It shifts the redundancy from infrastructure you do not control to a decision the user can make in five seconds. That is an unusual design in most contexts and a completely normal one here.
#Why the addresses are not interchangeable in every respect
They resolve to the same market, but they are not identical in every property. An older address has been in circulation longer, which means it appears in more third party lists, gets more traffic, and attracts more abuse. A newer address is quieter and often noticeably faster, but it appears in fewer places, so a user who only ever saw the old one may be suspicious of it.
This is why the mirror roster is worth checking rather than memorising one address forever. The roster is the authoritative statement of which addresses are current. A list you saved eighteen months ago is not, and an address that has quietly been retired is exactly the kind of thing phishing operators like to pick up and reuse. The security chapter goes into what that reuse looks like in practice.
#How this changes what you should do
Once the model is clear the practical advice follows from it directly.
- Keep more than one address saved. If you only have one and it goes quiet, you have no way to distinguish a path problem from a real outage, and no way to get in either way.
- Try another address before concluding anything. This one step resolves the large majority of what users report as the market being down.
- Verify the signature at whichever address you land on. The addresses are equivalent for reachability. They are not self certifying. Verification is what tells you the door leads where you think. See getting started for the mechanics.
- Refresh your saved list occasionally. Addresses do get retired, and the ones that get retired are the ones that later show up in phishing kits.
The rest of this section covers what happens when an address is retired, why a mirror often gets slow rather than failing outright, and what a signature actually proves. Those three questions account for most of the confusion that reaches support.