A prerequisite map for Zion Market. Read the arrows, not the list. Dependency map Onion addresses
zionmarket.biznothing works until

This is not a to-do list and not a walkthrough. It is a set of conditions and the arrows between them, so you can see what your problem is actually waiting on.

Zion Market onion addresses, printed here exactly as they were supplied

Two strings, reproduced character for character as they were handed to this site. Neither one is ranked above the other and neither carries a label, because a label would be a claim and this site is not in a position to make one. Nothing here opens them, so nothing here can tell you what happens when you do.

A2 · Ground you are standing on

A condition that must already be true

The clock is close enough to right

The system clock has to be within a few minutes of real time, because the documents the network hands you are only valid inside a window.

Confirm by: Compare the machine clock and time zone against a phone or a watch you did not set from the same source.
Not this: Not about time zones being pretty. A wrong zone is cosmetic; a wrong absolute time is fatal.

How far out of true a clock is allowed to be

The tolerance is minutes, not hours, and the reason is dull and mechanical. The documents the Tor network hands a client are signed, and they carry validity windows written into them: a time from which the document is good and a time after which it is not. The consensus that tells a client what the network currently looks like is one of these. So is the descriptor that tells a client where to find an onion service. Both are checked against the clock on your machine, because your machine has nothing else to check them against.

That is the whole mechanism. The client compares a date in a signed document against a date it reads locally, and if the local date sits outside the window the document is rejected as expired or as not yet valid. Material that is freshly published and correctly signed is discarded because the machine reading it believes it is a different day.

Two things follow. The failure is symmetrical, so a clock running ahead breaks things in the same way as a clock running behind. And the size of the error matters far more than the direction. A machine a minute out will be fine. A machine hours or days out will fail every time, in a way that looks nothing like a clock.

The clock belongs to whoever administers the machine

One arrow arrives here, from The machine is one you actually control, and what it supplies is the right to set the clock rather than merely to look at it.

Time is a system setting like any other. On a machine somebody else administers, the time source can be pinned by policy, automatic synchronisation can be switched off or forced on, and a correction you make can be undone before you next sit down. There is also a case that catches careful people: a machine sharing a disk with a second operating system, where one of them writes local time into the hardware clock and the other expects that clock to hold coordinated universal time. Every reboot into the other system then shifts the reading by the size of your offset. Fixing that is an administrative act, which is what the upstream card is about.

Where the upstream condition holds, this one is usually free. A machine you administer will normally keep its own time without being asked. This is one of the cheapest cards on the dependency map to satisfy and one of the most expensive to misdiagnose.

What a wrong clock stops

Exactly one card depends on this one, and it happens to be the narrow point that most of the rest of the map passes through: The client can build a circuit at all.

The mechanism is direct. Before a client can build anything it needs a current view of the network, and that view arrives as a signed document with a window in it. A clock badly out of true causes that document to be rejected, so the client has no usable picture of the network and no basis on which to choose a path. There is nothing for it to build with. The same problem repeats one level down for onion addresses in particular, because the descriptor that locates a service also carries a validity period, so even a client that somehow had a path would then throw away the material it needs to resolve an address.

Because that card is the neck of the map, its downstream inherits everything. You can tell a mirror from a copy of the market lists a working circuit among its own conditions, because you cannot compare two addresses in any way that involves reaching them when nothing can be reached. Whole stages sit behind that, and none of them will tell you why.

Clock stateWhat the client concludes
Correct to within minutesSigned documents fall inside their windows and are accepted normally.
Hours aheadCurrent documents are treated as not yet valid, so the network view is missing.
Hours or days behindCurrent documents are treated as expired, and the client keeps rejecting fresh ones.
Correct time, wrong zoneNo effect whatsoever, because the absolute moment is unchanged.

The failure presents as a network problem, so it competes for the reader's attention with There is a route out of the network you are on. Those two produce similar screens and have nothing in common, which is why this card is worth ruling out before that one.

What a clock failure looks like from the chair

You start the client. It reports progress and then stops reporting progress. Whatever text it shows describes connecting, or a failure to establish a connection, and it says nothing about time. Then the address you paste does not resolve. Then a second address does not resolve either. Then every address you own behaves the same way, which is the one genuinely useful clue and the one nobody reads correctly at the time.

What happens next is the actual cost. Identical failure across every address reads as a dead destination rather than a broken client, so the reader goes hunting for a replacement address. They collect strings from wherever strings can be collected and end up holding material whose origin they cannot revisit, which is the condition on The address arrived by a route you can use again. A wrong clock has quietly converted a two minute fix into a much harder problem.

Comparing against a source you did not set

Look at the machine clock. Then look at a clock you did not set from the same source: a phone that gets its time from a mobile network, a watch, a clock on the wall in another room. Read the minutes, not the hour.

A pass is agreement to within a couple of minutes. A fail is anything larger, and a large fail is often obvious in a way that is easy to dismiss, such as a date out by a day or a year that is wrong. Do not compare the machine against a device that synchronises from the same place you suspect, because two devices agreeing on one wrong answer is not evidence. The check needs no network and never involves opening an address, which matters because at the moment you need it nothing is opening anyway.

Not a matter of the right time zone

A wrong time zone is cosmetic. It changes what the clock displays and leaves the absolute moment untouched, so signed documents still land inside their windows and nothing breaks. A wrong absolute time is the fatal case. This card is also not a claim that a correct clock makes anything connect. It removes one reason for failing, which is not the same as supplying a reason to succeed.

The chain around this condition

Read downwards. Everything above this card has to hold before it can, and everything below it is waiting on it. Two levels are shown in each direction; the full graph is on the dependency map.

Two steps back
Nothing. The chain reaches a root within one step of here.
You are here
A2 The clock is close enough to right

Connected to this one

Where you are in the map