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.

F5 · An order that can exist

A condition that must already be true

The total is covered at the moment you press the button

Every earlier value condition has to be true simultaneously at the moment of committing, not each in turn at some point in the past.

Confirm by: Check the quote timer, the spendable balance and the fee estimate in the same minute, then act inside that minute.
Not this: Not a warning about volatility. It is about simultaneity, which is a different failure.

Several facts, all true in the same minute

Every other card in this stage asks whether something is true. This one asks whether a set of things are true together, at one instant, which is a harder question and a different one. At the moment of committing, the destination has to be the one this session just produced, the spendable figure has to cover the amount, the fee has to be accounted for on top of it, the coin has to be the one the figure is quoted in, and whatever window the quote is running under has to still be open. Each of those satisfied at some point earlier in the afternoon is not the condition. The condition is all of them at once.

The failure is undramatic, which is why it is worth stating plainly. Nothing about your situation has to deteriorate for this card to go false. Time passing is sufficient. Windows expire on their own, a balance shifts as confirmations land, and fee estimates move because other people are transacting. You have no influence over any of the three.

The three inputs and what each one contributes

The deposit address came from the session you are in contributes the destination, with a short shelf life by design. An address recovered from a note is what that card exists to exclude, and the freshness it insists on is what forces this card to be about a moment rather than a state.

There is something left over for the fee contributes the arithmetic. The fee comes out of the same balance and is not quoted alongside the amount, so the figure you can actually commit is always smaller than the figure the wallet displays. That card in turn rests on The balance has confirmed and can be spent and You hold the coin this order is priced in, which is why a failure here so often traces back two cards rather than one.

The other side answered before you spent anything contributes the last cheap unknown. It is the only one of the three that costs nothing to close and cannot be closed afterwards.

All three are upstream conditions in the ordinary sense, and each is checkable on its own. What makes this card different is that checking them one at a time and then adding up the results is precisely the method that fails.

Why the stages after this one depend on the instant

Two cards sit below, in different halves of what comes next, and both fail here for the same reason. A commitment that was not covered at the instant does not produce a clean failure. It produces an ambiguous object, and neither downstream card knows what to do with ambiguity.

You decided in advance what happens if nothing arrives asks you to write one sentence naming a day and an action. Try writing that sentence about an order whose state is neither paid nor unpaid. You cannot name the day, because the clock you would count from has not started, and you cannot name the action, because it depends on what the order turns out to be. The card is not made harder. It is made unwritable.

Escrow is still holding when the problem appears is the more serious one. That card assumes there is something being held. If the window lapsed and the figure was recomputed, or the fee came out of the amount rather than out of the remainder, then value left your side and the order did not register as covered. Something has moved and nothing is being held on your behalf. There is no dispute available, because a dispute is an argument about who should receive a held sum. That removes You can describe the problem in the market's own terms and everything after it, which is most of the last stage of the Dependency map.

Cannot holdThe reason it cannot
A plan for nothing arrivingNo day to count from and no action that fits an undefined state
Escrow still holdingValue moved without the order registering as covered, so nothing is held
A problem you can describeInherited: it sits below escrow and never becomes reachable
Feedback after the outcomeThere is no outcome, only an unresolved transfer

This is the point on the map where a failure stops being recoverable by doing the same thing again more carefully. Every card before it can be redone. From here on, the state you created is the state you argue from.

The gap between reading the numbers and acting on them

The sequence is ordinary and that is what makes it common. You check the spendable figure and it is fine. You read the quote and it is fine. Then something interrupts: a message, a second look at the listing, a decision to get a coffee first. You come back and the screen still shows the numbers you already approved. Screens do not age visibly.

So you commit against a figure that has been recalculated, or inside a window that closed, or with a fee estimate from before the estimate moved. What arrives at the far end is short by a small amount, or arrives outside the window, or does not arrive as expected at all. Then the confusion lands on the market, because from your side the interface accepted everything without complaint and the numbers you remember reading were correct. They were. They were correct at a different time.

Reading three numbers inside one minute

Look at the quote timer, the spendable balance and the fee estimate in the same minute, in whatever order suits you, and then act inside what is left of that minute. If anything interrupts between the last reading and the commitment, discard all three readings and take them again. That is the whole check.

A pass is being able to say, without guessing, when you last read each of the three. A fail is not a wrong number. It is not knowing. If the honest answer to when you read the balance is a shrug, the condition is false right now regardless of what the balance said.

Simultaneity is not volatility

It is not a warning about volatility, and the distinction matters. Volatility is the value of a holding moving against you, and it would still exist if every other part of this were instantaneous. Simultaneity failure happens with a completely flat price, because the quote window, the confirmation count and the fee estimate each move on their own schedule for their own reasons. You can be perfectly hedged and still fail this card. It is also not a repeat of There is something left over for the fee, which asks whether the arithmetic works. This one asks whether it still works at the instant you act.

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.

Connected to this one

Where you are in the map