Simpleswap
SimpleSwap uses exchange statuses to show when to wait, retry, adjust, reconcile, or stop
Last updated:Each SimpleSwap exchange status points to a practical next move. Wait while a valid deposit is confirming or the payout is being sent. Retry before funding when the pair, network, amount, or address needs correction. Reconcile an incomplete order with its Exchange ID and transaction hashes. Stop without sending while the order still awaits a deposit; once funds have been sent to the deposit address, the swap generally cannot be cancelled.
A bounded first attempt and its reversible stop
Readiness begins with the details displayed for one specific order. The selected input and output assets, networks, deposit amount, receiving address, rate type, and any required memo or tag must agree. Save the Exchange ID before moving funds. It connects later status checks or support requests to that order without relying on memory or a wallet label.
The last clearly reversible point is the Awaiting your deposit state, provided no transfer has left the sending wallet. A missing quote, unavailable pair, expired fixed-rate window, wrong network, or incomplete destination detail is a reason to leave that order unfunded. Create a corrected order rather than sending assets to instructions that no longer match the intended swap.
Completion requires more than seeing a progress animation. The order should reach Finished, an outgoing transaction hash should identify the payout when one is available, and the receiving wallet should show the asset on the intended network. Until they agree, keep the order record and avoid funding a duplicate order for the same purpose.
What actions fit the main exchange statuses?
An exchange status narrows the actions that fit its current stage. Awaiting your deposit leaves room to stop or replace the order before funding. Confirming generally calls for checking the deposit transaction and waiting for the required blockchain confirmations. Exchanging and Sending indicate that processing has moved beyond the initial deposit, so creating a second transfer does not repair the first one.
- Awaiting your deposit: verify the instructions or stop before sending.
- Confirming: match the deposit transaction hash, network, amount, and deposit address.
- Exchanging: retain the order details while processing continues.
- Sending: look for the payout record and check the receiving wallet.
- Finished or Refunded: reconcile the reported result with the blockchain records.
- Failed, Verifying, or Expired: pause and use the Exchange ID when contacting support.
The order page and a blockchain explorer answer different questions. The order status reports the service stage. A transaction hash reports whether a particular transfer is pending, confirmed, failed, and associated with the expected addresses and amount. One record cannot substitute for the other when a swap appears incomplete.
A status change also narrows the available choices. Before funding, retrying may be harmless because no assets have moved. After the deposit confirms, the valid choices may be limited to waiting, providing requested information, accepting an offered resolution, or requesting a refund where the order remains eligible.
Completion shown by separate records
The completion check begins by matching three records: the Exchange ID identifies the order, the deposit transaction hash shows the funded transfer, and the payout transaction hash shows the outgoing transfer. A Finished label without a visible wallet balance calls for checking the payout network and destination. A confirmed deposit with no corresponding progress calls for reconciliation, not another deposit. The receiving wallet remains the final place to confirm that the intended asset arrived.
A hypothetical swap that ends with matched records
The following example uses hypothetical assets, networks, addresses, amounts, minimums, and displayed order details. A reader creates an order for 137 units of a selected input asset. The hypothetical order shows a 117-unit minimum, so the 137-unit input is 20 units above it. It also shows a floating-rate estimate, a selected receiving network, and no destination tag requirement.
The reader saves the Exchange ID and checks every field before sending. A network mismatch appears in the receiving-wallet settings. Because the order is still Awaiting your deposit, the reader stops without moving funds and creates a new hypothetical order with the compatible network.
The corrected order again shows a hypothetical 137-unit deposit. Its input asset, deposit network, deposit address, and amount now match the order instructions. Its output asset, receiving network, and receiving address match the destination wallet. The reader sends that amount once and saves the deposit transaction hash rather than recreating the order when confirmation takes time.
The hypothetical deposit confirms, and the order moves through Exchanging and Sending before reaching Finished. A payout transaction hash then shows a confirmed transfer to the supplied receiving address. The destination wallet displays the output asset on the selected network.
The matched order status, deposit record, payout record, and wallet balance establish the completed end state. The earlier order moved no funds because the reader stopped at the reversible point. If the corrected order had not produced matching records, the saved identifiers would support reconciliation without a duplicate deposit.
When is waiting justified?
Waiting is justified when the observable records fit the displayed stage and no corrective action is requested. During Confirming, the deposit transaction should exist on the intended network and point to the order’s deposit address. During Exchanging, the confirmed deposit and Exchange ID remain the relevant evidence. During Sending, the outgoing transaction becomes the next record to inspect.
Elapsed time alone does not identify the cause of a delay. Confirmation requirements, network load, liquidity, maintenance, and additional monitoring can affect progress. A fixed deadline matters only when the order actually uses one. If a status changes to Failed, Verifying, or Expired, contact support with the saved identifiers instead of continuing to wait.
The practical limit is a mismatch between the stage and its expected evidence. Awaiting your deposit after a confirmed transfer, Finished without a traceable payout, or a prolonged unchanged state with no explanation all require reconciliation. Sending another deposit would create a separate blockchain transfer and complicate that work.
Retry and adjustment before funding
A retry is appropriate while no deposit has been sent and the current order no longer fits the intended transfer. Change the amount, pair, network, receiving address, or required destination identifier through a new order when necessary. For a fixed-rate order, the quoted rate is held for 20 minutes, provided the deposit receives at least one blockchain confirmation during that window. An expired or unsuitable quote should be replaced before funding rather than treated as an instruction that remains valid indefinitely.
How should an incomplete exchange be reconciled?
Reconciliation starts by matching the order to the transfer that actually occurred. Use the Exchange ID to locate the order, then compare its asset, network, deposit address, and expected amount with the deposit transaction hash. This separates an on-chain delay from an order that never received the intended transfer.
The payout side needs its own check. If an outgoing transaction hash exists, inspect its confirmation state, destination network, address, and transferred asset. A confirmed payout to the supplied address may point to a wallet display or network-selection issue. A missing payout record while the order remains Exchanging or Sending points back to the order state.
Failed, Verifying, and Expired states require support rather than an improvised second transfer. Provide the Exchange ID and relevant transaction hash through the service’s support channel. If a new rate or refund is offered, record the exact option before accepting it. A proposed resolution does not change the original deposit record, so both should remain available until the outcome appears on-chain.
Stop conditions after a deposit leaves
A clean stop remains available only while the order awaits a deposit and the wallet has not broadcast the transfer. Once a blockchain transaction confirms, it cannot be cancelled through the exchange page. A refund is a separate outcome, subject to the order state, the submitted details, and the applicable refund review. It is not the same as reversing the original transfer.
A deposit below the displayed minimum may be ineligible for a refund. Sending the wrong asset, using the wrong network, omitting a required tag, or funding expired instructions can also restrict recovery. Confirming, Exchanging, Sending, and Finished orders are not automatically refundable, although a request may be reviewed individually. No status label can reverse a confirmed blockchain transfer; it can only show which supported response remains available.
Helpful answers about Simpleswap
Can an expired deposit instruction be used for another attempt?
An expired order should not be treated as a fresh set of deposit instructions. Create a new order and use the asset, network, amount, address, and rate details shown there. If funds were already sent after the earlier order expired, do not repeat the payment. Keep the Exchange ID and transaction hash, then contact support so the existing transfer can be reviewed.
Does a changed receive estimate mean the exchange has failed?
A changed estimate does not by itself mean that the exchange failed. Floating-rate orders calculate the final output from the rate available during processing, so the result can differ from the initial estimate. A substantial change may lead to a pause and an offered refund or revised rate. The displayed order status determines whether action is required.
Is a refund automatic after a Failed status?
A Failed status does not make every deposit automatically refundable. Eligibility depends on the order details, transfer state, and whether the deposit followed the displayed instructions. A wrong asset, wrong network, missing required tag, expired order, or amount below the minimum can restrict recovery. Support may need the Exchange ID, transaction hash, and confirmation of a permitted refund address.
Can the receiving address be changed after funding?
A receiving-address change may no longer be available after the deposit enters Confirming, Exchanging, or Sending. Do not create a second order or send another deposit to correct the first one. Contact support with the Exchange ID and deposit transaction hash. Any permitted change or refund can require additional confirmation before it is processed.
Is an Exchange ID safe to post publicly?
An Exchange ID should be kept private rather than posted in a public message. It identifies one specific order and may expose transaction details that could help an impersonator construct a fake support request. Share it only through the service’s support channel when assistance is needed, together with the relevant transaction hash if the deposit or payout is delayed.