Unknown is a state. It is not a failure.
A transfer submitted with no arrival and no failure is the single most dangerous moment in this product. The instinct is to retry. The instinct is wrong, and acting on it costs somebody $40,000.
Two ways to lose certainty
An ordinary payment system has one: the partner accepted your instruction and then went quiet. Cross-chain adds a second: you submitted a transfer to a transport path, and neither an arrival nor a failure has come back.
Both look identical from the outside. Nothing has happened. Both are states we call unknown, and neither is a failure.
Why retrying is the expensive answer
Re-submitting a $40,000 transfer that quietly landed sends $80,000. One of those is unrecoverable. There is no customer-service script for that, no apology that helps, and no version where the clever reason it happened makes it acceptable.
Retry logic is the default in most systems for good reason — most operations are idempotent, or cheap, or reversible. A cross-chain value transfer is none of those.
The correct response to not knowing is to find out. It is never to act again.
What we do instead
Poll the source chain. Poll the destination chain. Poll the transport’s own status endpoint. Keep polling until the state is actually known, and hold everything downstream while we do.
Same rule on the fiat leg: a partner timeout is unknown, not failed. Hold, reconcile against the partner’s record, never resubmit.
At fifteen minutes, both escalate to a person, with a plain-language explanation of exactly what we do and do not know. Nothing in either path resolves itself on a timer, because a timer is just a slow way of guessing.
Idempotency, everywhere it can move money
Every value-moving call carries an idempotency key. A retried request returns the original result rather than making a second payment. This is not a clever feature; it is table stakes that a surprising amount of payments software still does not have, and it is much harder to add later than to start with.
The same principle drives the ledger. Double-entry from the first transaction, not a spreadsheet that gets promoted to a ledger once volume justifies it. Retrofitting an accounting system onto live money is how records go wrong quietly, and quietly is the bad way for records to go wrong.
What this means for you
Occasionally a payment will sit in a state that reads as “nothing is happening”, and a person will contact you to say so before you have to ask. That is the system working. The full state machine is here.