Coins sent to the wrong place

The wait, in plain words

A transaction that has gone somewhere it should not have is not a delay. That is the first thing to be clear about, because the screens involved look like the screens of a delay. There is an amount, there is a record of it, there is a place it went, and all of that is complete. Nothing further is pending.

The versions of this are ordinary and none of them are dramatic. An address copied out of the wrong tab. A deposit address that belonged to an account you no longer hold. A string typed from memory with a character wrong, which is why reading the address string again is a card of its own. An asset sent across a network the destination does not use. Different mistakes, same ending.

What follows has no ceiling because it is not a process. A ceiling requires the outcome to depend on a mechanism, and mechanisms have properties: they run, they fail, they take a knowable band of time. This depends on a person deciding to do something they are not obliged to do, and people do not have properties like that.

Underneath, while nothing moves

Settlement runs one way. A transaction that has been included and then built upon is not sitting anywhere waiting for a confirmation of intent, and there is no instruction available on the sending side that undoes it. A deposit reaching enough confirmations covers the point at which that stops being provisional. The only thing that moves value back is a fresh transaction in the other direction, and that transaction can only be made by whoever holds the key on the destination side.

This is worth stating flatly, because the language used around payments elsewhere suggests otherwise. There is no operator sitting between the two ends with the ability to reverse an entry. A withdrawal being sent describes where the market part ends: once it has signed and broadcast, the market is no longer a party to the transaction and has nothing left to act on.

Sent to a market deposit address that has since rotated

The destination is controlled by the market rather than by you. Whether anything can be done with it is a question for the market, and not one the network can answer.

Sent to an address with a character wrong

If the string was still a valid one, the destination belongs to somebody. There is a holder, and they are unreachable by any reliable route.

Sent across the wrong network

The same string may exist on both, controlled by different keys or by nobody at all. This is a question about who holds keys, not about the transaction.

Sent to an account you have lost access to

The value is where you meant it to go. The problem is the key, and a lost key is a separate wait with its own shape.

In every one of those rows the question stops being about the payment and turns into a question about who controls the destination. That is the entire content of this wait.

Behaving, and not behaving

There is a version of this that is a request with somewhere to go, and a version that is a request into the air.

The second case is where the loss usually doubles. A person in this wait is easy to spot and easy to approach, and the offers that arrive are shaped exactly to fit it. Anyone who contacts you first, unprompted, about a transaction they were never told about is telling you something about themselves.

The condition that ends this wait is therefore not a reply. It ends when the request has been made once, in the only place it could have been made, carrying enough detail to identify the transaction, and written down. After that there is nothing left that is yours to do, and refreshing a transaction view is not waiting. It is watching.

Safe to do meanwhile

The work here is short, and most of it is about not making a second mistake on top of the first one.

• Record the transaction as it standsThe identifier, the destination, the amount, the moment you noticed. Written once, kept, and never retyped from memory afterwards.
• Ask once, through a route that existed alreadyIf a party controls the destination and has a support route, that route is where the request belongs. One clear message beats several.
• Repair the habit that produced itPaste, then read both ends and a run in the middle before anything is sent. That card is short for a reason.
• Learn where the market part of a payment endsSo that next time you know which side of the boundary a problem has landed on.

What makes it longer

This wait has almost no natural length of its own. What extends it is entirely a matter of what gets done after the transaction settled.

• Accepting help from anyone who arrived on their own. Recovery offers are a category, and the category has one shape.
• Publishing the transaction detail more widely in the hope of reaching the holder.
• Sending a second payment to the same destination to prove something, or to test something.
• Waiting for a reply as though a reply had been scheduled. Nothing scheduled it.
• Re-reading the transaction view for changes. It records a completed thing, and completed things do not develop.

What this card is not. This card is not a recovery guide, and there is nothing on this site that can move a transaction which has already settled.