Where the destination in your clipboard came from
Everything on this card is about provenance and about a very short span of time. The destination you are about to send value to has to have been produced by the session in front of you, and used while that session is still the one you are in. A destination that came from anywhere else had an opportunity to become something other than what you think it is.
The list of anywhere else is short and unglamorous. A note kept from an earlier occasion. A screenshot. A page left open from before. A message somebody sent you. Each has the same defect: between the moment it was created and the moment you paste it, the string sat in storage that other things can reach. It takes one of those things to be a process that watches for strings of that shape and swaps them.
That substitution is the attack this card is built against, and it works because a destination string is long, meaningless and unmemorable by design. Nobody reads it. It is copied and pasted, and the copy and the paste are separated by a moment in which the contents can be replaced with no visible event. The replacement is valid and well formed, so everything downstream of it works perfectly. The transfer succeeds, and the wrong party has the value. Reuse deserves its own line here: a destination that worked before feels safer precisely because it worked, and that instinct is backwards. A stored copy has had longer exposure, and being correct then says nothing about what your storage holds now.
A live session and value that is ready to leave
you can log in a second time provides the source. A destination produced by the session you are in is only possible if you can get into a session reliably, at the moment you want to send. That is the difference between an account you got into once and an account you can become again. If getting in is uncertain, you will start hoarding destinations against the day you cannot get in, and hoarding is the failure this card describes. That is how a session problem turns into a value problem.
the balance has confirmed and can be spent provides the ability to act now. Freshness is only achievable if sending can follow generating immediately. If the value on hand is visible but not spendable, the destination has to wait, a destination that waits is stored, and a stored destination is stale by the definition used here. The settlement card is not a nicety underneath this one. It is the thing that keeps the interval short.
Both parents have a single purpose here. They compress the time between the destination appearing and the value leaving, and everything this card protects against lives in that interval.
What a stale destination stops
One card sits below this one, and it is one of the busiest joins on the map.
| Cannot hold | The reason it cannot |
|---|---|
| the total is covered at the moment you press the button | That card requires the destination, the spendable balance and the fee margin to be true in the same instant. A destination from an earlier occasion was true in a different instant, and there is no way to show it is still true now. |
The word covered is doing more work there than it looks. It does not only mean there is enough value. It means the value is going to the right place at the moment it goes. A transfer that leaves with enough in it, in the right denomination, with a fee margin behind it, and lands somewhere unintended, is not a covered order. It is a completed loss with an entirely clean record on your side.
This is the only card in the stage whose failure produces no error anywhere. A settlement failure gives you a refusal. A denomination gap gives you a mismatch you can see. A fee shortfall gives you an argument about a figure. A substituted destination gives you a success message, a transaction anyone can look up, and a market side reporting nothing arriving. Every check you run afterwards passes, because everything did work. It worked on a string that was not the one the session produced.
Further along, escrow is still holding when the problem appears assumes there is a mechanism holding something to argue about. Value sent to an unintended destination never entered any mechanism, so nothing is being held and there is no dispute to open. The chain does not break where you notice it. It stops existing rather than failing, and roots and endings describes what that means for everything that was supposed to follow.
A transfer that has left cannot be recalled by anybody, including whoever received it. This is the point after which no later condition on the map can do anything useful.
The send that goes perfectly wrong
Skipping this looks like efficiency. On an earlier occasion you saved the destination, reasoning sensibly that generating it again is a nuisance and the string does not change. This time you open the note, copy, paste, set the amount and send. The operation is smooth, there is a confirmation, the value leaves.
Then nothing happens on the market side. You wait, because waiting is reasonable and settlement takes time. After long enough that waiting has stopped being reasonable you go looking. Your wallet says the transfer went out and completed, the public record agrees, and the natural conclusion is that the market is at fault. The market side is also correct: nothing arrived at their destination. Both sides are reading truthful records that describe different destinations, and the discrepancy is visible only in the string itself, which nobody compared. People often send again at this point, from the same note, with the same outcome.
Comparing the ends, and admitting what that misses
The honest check is to compare the whole string, character by character, between what the session displays and what your wallet is about to send to. Nobody does it, so here is what people do instead. Compare the first several characters and the last several against the same positions in the pasted field. It is quick, and it is genuinely weaker, because a substitution designed to survive it produces a string matching at both ends and differing in the middle, which is work but not impossible work. People do it anyway for a good reason. A check performed every time is worth more than a thorough check skipped once, and the skipped occasion is the one that costs everything.
A pass is that the ends match, the destination came from the window in front of you, and you sent without leaving that window. A fail is any of these: the string arrived from storage, it arrived in a message, or you cannot say which session produced it. This is also why you hold the address as characters, not as a click appears so early on the map. A string you can read is a string you can compare, and here that is the difference between a check and a hope.
Freshness proves origin, not intent
A destination generated in the session in front of you is not a safe destination. It is a destination whose origin you can account for, which removes one specific substitution and leaves every other question untouched. This card also says nothing about what happens after the value arrives.