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.

E2 · Value you can move

A condition that must already be true

The balance has confirmed and can be spent

The value has to be settled far enough that it can be spent now, not settled enough to be displayed.

Confirm by: Look for the spendable figure rather than the total, and check the confirmation count against what the receiving side asks for.
Not this: Not a rule about how many confirmations are enough. That number is set by whoever is receiving, not here.

The number you see and the number you can use

There are two figures in any holding, and most of the time they agree, which is why most people never learn there are two. One is the total the wallet knows about. The other is the part of it that could be included in a transfer right now. Value that has arrived but has not settled far enough belongs to the first and not the second. It is real, it is yours, it is visible, and it cannot be spent.

The gap opens in two ordinary ways. The first is a recent incoming transfer: it exists and the wallet can see it, but it has not aged into something anyone downstream treats as final. The second surprises people more. Change returning from your own outgoing transfers is a new arrival, and a new arrival waits like any other, so the act of spending can temporarily reduce what you are able to spend by more than the amount you sent.

The condition here is the second figure. Settled far enough to be spent now, rather than settled far enough to be shown. This site sets no threshold. How far is far enough is decided by whoever is receiving, and it can be changed by them without anything visible happening at your end. That is a fact about the arrangement rather than a gap in this page, and treating it as a fixed universal quantity is one of the ways this condition goes quietly false.

Why this rests entirely on custody

One card sits above this one and the dependency is total. a wallet exists and the keys are yours makes settlement a question about you at all. When you hold the keys, the transfer that arrived ended at an address you control and its progress is a public fact you can read for yourself. Settlement is then a property of the transfer, and the spendable figure is your wallet's honest opinion about what it could build a valid transfer from now.

When somebody else holds the keys, none of that survives. What you are shown is an entry in their records, and whatever stands between that entry and your ability to move value is a policy, not a settlement. Reading a figure there tells you what they are prepared to display, not what you can do, so the question this card asks cannot even be put.

With the parent satisfied, this card is at least answerable. Everything below assumes you can inspect the arrival yourself rather than being told about it.

What an unspendable number stops

Two children carry the rest of the value stage into the order stage, and the failure here never looks like a failure. You look well funded and you are unable to act.

Cannot holdThe reason it cannot
the deposit address came from the session you are inThe whole value of a fresh destination is that it is used immediately. If the value is not spendable when the destination appears, you store the destination and come back, and a stored destination is what that card exists to prevent.
there is something left over for the feeThe margin for the fee comes out of spendable value, not out of the total. A total that comfortably covers amount and fee can sit on a spendable figure that covers neither.

The destination card is the more interesting of the two, because this condition breaks it indirectly. It asks for a destination produced by the session in front of you and used at once. Suppose the spendable figure is short when that destination appears. Nothing forces an error. What happens is a delay, and delay is fatal to that card in a way it is not fatal to most others. You copy the destination into a note, come back later, paste and send. The transfer will very likely succeed, and the condition has still been broken.

The fee card breaks directly. Fees come from the same pot as the amount, and the pot is the spendable part, so people check the total, see room, set the amount, and meet an error about insufficient funds while the balance on screen plainly disagrees.

Both children feed the total is covered at the moment you press the button, which needs several conditions true at the same instant. Spendability is the one that changes on its own, in both directions, without you touching anything. A condition that moves while you are not looking is the natural enemy of a card about simultaneity. the dependency map shows how narrow the path here is.

A shortfall discovered at the moment of committing cannot be repaired inside the window that is running. Waiting is the only remedy, and waiting is what the window does not allow.

How the confusion arrives on the screen

The sequence is always roughly the same. You move value in, the wallet acknowledges it, the total updates, and that reads as completion, because everywhere else a number that has updated is a number that is done. You work through to the point of paying and set the amount.

Then one of two things happens. Either the wallet refuses to build the transfer and reports insufficient funds, which is infuriating when the displayed balance is larger than the amount, or it builds the transfer from what is available and less leaves than you meant. The second is worse and far less obvious, because everything reports success on your side. On the market side there is nothing, or something short, and the message you get points at the arrival, which makes the destination look guilty. The cause is that the figure being spent from and the figure being read were never the same figure.

Finding the smaller of the two figures

This needs nothing but the wallet you already have, and it opens nothing. Look for where the wallet distinguishes available value from total value. Almost every wallet does, though the words differ, and the distinction is often shown only when the two disagree, which is exactly when it matters. A pass is that you can point at the available figure, name it as separate from the total, and see that it moves after an incoming transfer rather than at the same moment. A fail is finding one number and assuming it is the second.

The other half of the check concerns the receiving side. Find out what they treat as settled, in their own words, wherever they state it. Not to memorise a threshold, but to establish that the threshold is theirs. If your model is that settlement is a single universal event, this condition is already half false.

Settlement is not safety

This card names no threshold, because the threshold is not this site's to set. It also does not claim that settled value is protected value. It says only that spendable and displayed are different quantities, and that the smaller one is what you actually have. words used here keeps the two terms apart on purpose.

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