An order nobody paid
3 October 2026 · figures measured 3 October 2026
A row in a ledger reads: 0.01 BTC into ETH, one provider, a date, a time. Beside it, where a status would be, nothing.
The obvious reading is that somebody sent money and the exchange never finished. The actual answer was that nobody sent anything at all — and the row could not have told you either way.
What a record is written from
An exchange record is written when the exchange is created, which is the moment a provider hands back a deposit address. Everything in it at that point is intent: the amount asked for, the rate quoted, the address the payout should go to.
None of that is evidence that money moved. The deposit happens afterwards, on a chain, by somebody else's wallet, on their schedule or not at all. A column headed with an amount is describing what the exchange was set up to do, not what it did.
Where a status actually comes from
The status is learned by asking the provider, and the asking is done by the page the customer has open. That is a reasonable design: it costs nothing when nobody is waiting, and it is accurate exactly when somebody cares.
It has one consequence that is easy to miss. Close the tab and the asking stops. An exchange that settles an hour later settles unobserved, and the record keeps whatever it last heard — which, for an exchange abandoned at the start, is nothing.
| What the record shows | What it can mean |
|---|---|
| A settled status | The provider said so while somebody watched |
| A failed or refunded status | Same — heard, and recorded |
| No status at all | Nobody asked, or nobody could |
The third row is the one that matters, because it looks like information and is not.
The fee is a clue, and only a clue
There is a second signal in the same row. A router that signs the sending transaction itself can take its fee as part of that transaction. One that hands over a deposit address and lets the customer pay from their own wallet cannot — there is no transaction of its own to take anything from.
So a blank fee means the customer paid by hand. Except that it also means a fee switched off for everybody, and the record has no way to say which. A figure that means two different things is not an answer; it is a coin flip with a plausible face.
What settled it
The provider's own order page, which states the case plainly: the order had expired, and underneath, that no transaction had been received. Not partially paid, not paid late — never funded. The customer opened an exchange, looked at a deposit address, and closed the tab.
That is an entirely ordinary thing to do. People price a transfer and change their mind. The interesting part is not the customer's behaviour, it is that a system holding a detailed record of the order could not distinguish it from a completed one.
What a record should be able to say
Three things close the gap, and none of them are clever. Record how the deposit was meant to be paid, as a fact rather than as something inferred from a fee. Keep whatever credential the provider requires to ask about an order later, because the moment of creation is the only time some of them hand it over. And give somebody a way to re-ask, so a record stops being frozen at the last moment anyone happened to be looking.
The underlying principle is older than any of this: a system should be able to tell the difference between a thing that did not happen and a thing it never checked. Most of the time those look identical, and the cost of not separating them is paid later, by whoever has to answer a question about it.
Method
Drawn from a single real exchange on this deployment, created and never funded, read on the date above from the ledger and from the provider's own order page. No customer details appear here: not the order id, not the addresses, not the network it came from. What the ledger keeps and why is set out on the privacy page.
Every figure above can be checked against the providers yourself — no account, no sign-up, and nothing is held for you at any point.