Houdiniswap routes non-custodial swaps through tracked stages to settlement

Houdiniswap aggregates non-custodial routes for standard, private, and direct on-chain swaps, then records each order from setup through settlement. A swap is complete only when the intended output reaches the destination and the order record supports that result. Before funding, save the route details, destination, and order identifier.

Updated September 2026

Key takeaway: Track the order record, source transaction, and destination payout before treating a Houdiniswap order as settled.

Three routing paths create different records

The available paths are Private, No Wallet Connect, and DEX swaps. Houdiniswap itself does not take custody of the funds. An underlying protocol or exchange partner handles each leg of execution, so the records and commitment point depend on the chosen swap type.

A No Wallet Connect swap provides a temporary, one-time deposit address. The sender transfers the selected asset to that address without connecting a browser wallet or approving a contract. A single exchange partner then processes the conversion and delivers the output to the supplied destination address.

Private routing also uses a deposit flow, but it adds another exchange step. A DEX route works differently: the wallet connects, approves token spending when required, and submits an on-chain transaction to a decentralized exchange or bridge. Its execution is public, and network confirmations provide much of the evidence needed to follow settlement.

The commitment boundary comes before execution

Route selection remains reversible while the funds have not left the sender’s control.

View image file

Before that point, a reader can reject the quote, correct the destination, choose another route, or wait for different conditions. A manual-deposit order should be replaced if its destination details are wrong and no deposit has been made. Any required token approval comes first and may be a separate on-chain transaction. The swap itself remains uncommitted until its execution transaction is signed and submitted.

Once a funded order has been received, its execution cannot be cancelled. A receiving address may be changed after funding only if the order has not reached the payout stage, and that exception requires immediate support intervention. After payout begins, the destination belongs to the committed order rather than an editable quote.

Which records should you save before sending funds?

Save the order identifier, selected input and output networks, token names, amount, destination address, and any required memo or tag. For a deposit-based route, also retain the temporary deposit address and its expiry information. These details establish what the order was supposed to do before market movement or later status changes complicate the comparison.

Once the source transfer is submitted, record its transaction hash and sending address. The order identifier locates the service record, while the hash proves what entered the source network. Neither record replaces the other. Support may need both, along with the receiving address, to distinguish an unfunded order from a detected deposit or a payout problem.

Order states turn route activity into evidence

The lifecycle separates setup, deposit detection, execution, and terminal outcomes. Not every route uses every state.

In-progress states

Waiting and confirming

Initializing means the order is still being prepared. New or Waiting indicates the route is ready but has not yet advanced beyond its deposit condition. Confirming means the deposit has been detected and is accumulating the confirmations required by the selected network or provider. A slow confirmation state is different from an order with no detected deposit.

Exchanging and anonymizing

Exchanging indicates the conversion or route execution is underway. Anonymizing appears only where the privacy route includes its additional transfer stage. These labels describe work in progress, not delivery. A route can therefore have a confirmed input while its intended output has not reached the destination.

Terminal states

Finished identifies successful completion in the order system. Expired, Failed, and Refunded describe different exits and should not be treated as synonyms. An expired order missed its permitted funding window, a failed order could not complete, and a refunded order records a return path. Deleted can also appear in integration data, but it is an order-record state rather than proof of payment.

What proves a Houdiniswap swap is complete?

Completion requires a Finished order and evidence the intended output reached the stated destination. Match the order identifier, output asset, destination network, receiving address, and payout transaction. A status label alone describes the service record; the destination transaction or resulting balance confirms the delivery the reader actually requested.

For an on-chain route, the submitted transaction and resulting settlement can be checked through the relevant network data. Deposit-based routes may expose separate input and output hashes because a partner handled the conversion between them. When those records differ, that is expected route structure rather than an automatic mismatch.

On a floating-rate route, the final amount can differ from the earlier quote when liquidity or market prices move during execution. A fixed-rate Standard or Private route guarantees the quoted output only when the exchange is created within the quote’s validity window. Reconcile the delivered amount against the selected rate type and final order record.

Quote data defines the order before commitment

A quote joins the source asset, source network, amount, destination asset, destination network, and route type. It may also carry minimum and maximum bounds supplied by the available provider. Those bounds and route availability are live variables, so an older quote should not be reused after it expires or becomes invalid.

The destination deserves a separate check because identical-looking token symbols can exist on different networks. Confirm the network, address format, and any memo or tag before creating or funding the order. If the interface reports an unavailable path or an out-of-bounds amount, change the unresolved input and obtain a fresh quote instead of sending funds against the rejected route.

Private routing changes the observable trail

A Private Swap routes the order through two separate non-custodial exchange partners and uses a temporary Layer 1 asset between the two legs. The first leg accepts the source asset, while the second delivers the requested output. This construction avoids placing the sender and receiver in one direct transaction path.

The extra leg affects both status interpretation and recovery. An order can be past source confirmation while the second exchange is still processing, and the Anonymizing state may appear between exchange and payout. Privacy does not remove the need for records: the order identifier, source hash, and destination evidence remain necessary for verification. It also does not override partner screening or recovery rules.

What happens when an order expires or fails?

An expired order usually means the deposit arrived outside its allowed funding window or did not arrive in time. Do not treat its old deposit address as a fresh quote. Keep the order identifier and source transaction hash, then reconcile whether a transfer was sent and when the network confirmed it.

A Failed state means execution did not finish, but it does not by itself describe where the funds ended. Check for a refund state or return transaction before taking another action. For direct DEX routes, a reverted transaction returns the input to the source address, although the network fee for the attempted transaction may still have been spent.

Sending the wrong token or using the wrong network creates a different recovery problem. Manual recovery may be possible in some cases, but unsupported deposits can be unrecoverable. A second deposit is not a repair method: only the first detected deposit is processed, while later deposits are refunded only where the route permits it.

Reconciliation starts with the earliest mismatch

Compare the saved order against the source transaction before focusing on the payout. If the order is Waiting but the source transaction exists, verify the deposit address, asset, network, amount, confirmation state, and memo. A mismatch at this stage explains why exchange processing has not begun and prevents a later status from being misread.

If the deposit is confirmed and the order has moved to Exchanging or Anonymizing, the unresolved work sits inside the selected route. Repricing or sending more funds cannot accelerate that existing order. Keep the original records together and use the order identifier, transaction hash, sending address, and receiving address when escalation becomes necessary.

For a Finished order with no apparent destination balance, match the payout hash to the expected network and address. Wallet interfaces and portfolio trackers can lag behind network settlement, so the underlying transaction is the better first check. A confirmed payout to the saved destination closes the reconciliation even if a separate display has not refreshed.

The exit boundary follows settlement or documented recovery

A successful exit consists of the final order state, destination transaction, and received asset agreeing with the saved request. Archive the order identifier and both transaction sides until the balance is visible and usable on the destination network. For a DEX route, any token allowance left after completion is separate from the settled swap and can be reviewed independently.

A non-successful exit needs equally concrete evidence: a confirmed refund, a reverted DEX transaction, or a recovery decision tied to the funded order. Starting another swap does not close the first one. Compared with a manually assembled bridge-and-trade sequence, Houdiniswap combines route selection and order tracking, but the provider records and network transactions still determine whether each transfer finished.