Houdiniswap records show whether an incomplete swap needs more time, a fresh route, reconciliation, or no further action

Two evidence states separate a delay from a mismatch

An incomplete swap is a diagnostic description, not a Houdiniswap status label. A normal active order has evidence consistent with its stage: no detected deposit during WAITING, a detected source transaction during CONFIRMING, or active routing during EXCHANGING. The order remains unfinished, yet nothing in those records necessarily indicates failure.

A mismatch appears when the evidence and displayed state disagree. Examples include a confirmed source transaction while the order remains at WAITING, a FINISHED order without a matching destination transfer, or a refund status without a visible return transaction. Locate the mismatch before creating another order. Otherwise, two deposits or overlapping recovery attempts can complicate the record.

The order record controls the next move

The current status identifies the appropriate response, while transaction records confirm whether the displayed description matches activity on the relevant network.

FINISHED is different from every state in the table because it records completed delivery. REFUNDED records a return of the original funds, although network fees may reduce the returned amount. Neither label should be accepted from text alone when a transaction record is available for comparison.

Which incomplete states call for more time?

CONFIRMING, EXCHANGING, and ANONYMIZING call for more time unless the order contradicts on-chain evidence or remains stalled beyond the stated support threshold.

A CONFIRMING status means the deposit was detected and is awaiting the required blockchain confirmations. Confirmation of the source transfer does not prove the output was delivered. EXCHANGING follows after the deposit confirms, while ANONYMIZING appears only when a private route reaches its additional routing stage.

Network congestion, liquidity availability, routing complexity, and provider queues can affect completion time. An initiated order cannot be sped up or repriced. If it remains pending for more than one hour, the documented response is to contact support with the order identifier and transaction hash, not to fund the order again.

View image file

Retry only where the original commitment has ended

Create a new order only when no funds entered the earlier order or when a failed on-chain transaction has returned the funds to the source address. Retrying does not mean sending another deposit to the same address.

Before a deposit exists

An invalid or expired quote, an unavailable path, or an amount outside the route bounds prevents a valid commitment. Request a fresh quote and create a new order after resolving the stated error. If the earlier order produced a deposit address, leave that address unused once its validity window ends.

After an on-chain reversion

A reverted DEX transaction returns funds to the source address. Confirm the reversion and restored balance before requesting another route. A routed FAILED order is different because a provider may still be determining whether and how to issue a refund. In that case, a new attempt should not replace recovery of the funded order.

Adjust the route before creating a replacement

Adjustment belongs before a replacement order, not midway through a funded one. A fresh quote may expose different minimum and maximum amounts because those bounds come from the selected provider. An unavailable path may require another supported pair, a different amount, or a later attempt.

Some creation errors also identify a routing choice. Exact mode can prevent route creation, and the error may advise turning it off. A private path may be unavailable while a standard path exists. Changing either option changes the execution conditions, so compare the replacement quote before creating the new order.

Reconciliation follows the handoff between records

Reconciliation starts where one system handed the transaction to the next. For the input leg, compare the source transaction hash, network, token, amount, and deposit address with the order details. A confirmed source transaction proves the input transfer on its network, but it does not prove the order detected the correct transfer.

The move from WAITING to CONFIRMING supplies the next piece of evidence. It shows the deposit was detected. EXCHANGING or ANONYMIZING then records route processing. At the output end, the destination transaction hash, destination address, network, token, and final amount establish whether delivery occurred.

A disagreement at the earliest handoff defines the next action. A wrong address, token, or network belongs in recovery rather than a normal status wait. Matching input evidence followed by a stalled active state belongs with support. A matching destination transaction closes the swap even if a wallet interface has not yet refreshed its display.

How should expired and failed orders be handled?

An unfunded EXPIRED order can be replaced, while a funded or disputed EXPIRED order and every funded FAILED order must be reconciled before another deposit is considered.

Expired without a transfer

EXPIRED normally means the deposit was not detected within the allowed funding window. When the source wallet never sent funds, stop using the old deposit address and obtain a fresh quote. The new order may have different route conditions because availability and liquidity can change.

Expired after a claimed transfer

If a transfer was sent to an address tied to an expired order, do not assume a fresh order will collect it. Preserve the source transaction hash and order identifier, then contact support. The timing, network, asset, destination, and confirmation state determine whether the transfer can be located and recovered.

Failed and refunded

FAILED means execution encountered an error after the order began processing. Check the error and any displayed refund state. Some providers return funds automatically, while others require support involvement. REFUNDED is terminal, but the return should still be matched to the source or supplied refund address. Network costs can make the returned amount lower than the original deposit.

Private and DEX routes expose different evidence

The route type changes which records explain an incomplete swap. Treating every order as a single on-chain transaction can hide the handoff responsible for the delay.

Private route evidence

A private swap includes an additional routing stage. Its detailed record can track an input leg and an output leg separately, so one leg may be further along than the other. ANONYMIZING therefore describes active processing rather than missing funds. Partner screening or recovery requirements may also apply, and Houdiniswap cannot override a provider’s compliance process.

DEX route evidence

A DEX swap executes through on-chain transactions and uses the connected wallet. The transaction hash shows whether execution remains pending, succeeded, or reverted. Liquidity changes or price movement can cause a transaction to revert after a delay. Once the source funds are visibly returned, a fresh quote can start a separate attempt without confusing it with the earlier transaction.

The exit boundary is a matched settlement or recovery record

Waiting ends when FINISHED matches a destination transaction and the intended output reaches the recorded address. Recovery ends when REFUNDED matches the return transaction. A terminal label without its expected transfer remains a reconciliation case rather than a reason to send more funds.

Stop retrying when an unresolved funded order has moved into provider recovery or support handling. Stop using an expired deposit address. When the evidence closes the original order, any later swap should begin with a fresh quote, new order identifier, and current route conditions. That separation keeps settlement, recovery, and a later attempt from becoming one ambiguous transaction history.