Simpleswap First Exchange Preparation and Result Verification
Simpleswap lets you prepare a crypto exchange without committing funds until you send the deposit. Record the selected input and output, quoted amount, rate type, minimum, receiving address, any required memo or tag, and Exchange ID. Stop if any item conflicts with your wallet. After sending, use the exchange status, both transaction records, and the receiving wallet entry to confirm the result.
That record separates what you requested from what later occurred. It also provides the identifiers needed if a deposit confirms but the exchange stalls, or if a floating-rate payout differs from its estimate.
Build a Record Before the Deposit
The first exchange record should capture the exact request before any funds reach the displayed deposit address. Values such as the minimum, estimated output, and available rate type can depend on the selected route and current conditions. Saving them at exchange creation gives you a stable basis for reviewing the outcome.
- The input asset, its network, and the amount you intend to send
- The requested output asset and its selected network
- The estimated receiving amount and chosen rate type
- The minimum deposit shown for this exchange
- The complete receiving address and any required extra identifier
- The Exchange ID associated with the request
The unsent stage is the reversible boundary. Compare the recipient details with the receiving wallet rather than relying on an address saved elsewhere. If the wallet cannot supply a compatible address, network, or required memo, leave the exchange unsent and correct the setup first.
Separate the Request From Blockchain Evidence
An Exchange ID identifies the service-side exchange, while a transaction hash, or TXID, identifies a blockchain transaction. They are related but cannot replace each other. The Exchange ID opens the exchange record and its reported status. The deposit TXID shows the outgoing transfer, including its destination, amount, and confirmation state.
A completed exchange may also have a payout TXID for the transfer to the receiving address. Keep the quote, Exchange ID, deposit TXID, and payout TXID together until the wallet reflects the result. Support can use the identifiers to trace different parts of the exchange, but they should not be posted publicly.
How Do the Exchange Records Fit Together?
Each record answers a different question about the same exchange, so verification works best when the records remain connected.
| Record | Question It Answers | Evidence It Provides | Continue or Stop Condition |
|---|---|---|---|
| Saved quote | What was requested? | Selected assets, networks, amounts, rate type, minimum, and destination | Stop before sending if any saved detail is wrong |
| Exchange ID and status | Which exchange is being processed? | The service record and its reported processing stage | Continue only with details belonging to this Exchange ID |
| Deposit TXID | What is the input transfer’s blockchain state? | Deposit destination, transferred amount, and confirmation state | Do not send a second deposit merely because processing is slow |
| Payout TXID | Was the output transfer broadcast? | Payout destination, output amount, and blockchain state | Investigate if it conflicts with the intended destination or network |
| Receiving wallet entry | Did the intended wallet recognize the result? | The wallet’s record for the selected asset and network | Close the task only after it agrees with the payout evidence |
No single record proves every stage. A deposit TXID does not prove conversion, and a Finished label does not show the receiving wallet’s own view. Together, the records connect the original request, the outgoing transfer, the service state, and the delivered asset.
Match the Asset, Network, and Destination
Compatibility depends on the asset and network as well as the address. The same asset can exist on multiple networks, while a wallet may support only selected versions. A valid-looking address therefore does not establish full compatibility. Confirm the receiving wallet names the same asset and network selected in the exchange.
Some destinations require a memo, destination tag, payment ID, message, or extra ID in addition to the address. Copy that identifier exactly when the receiving wallet supplies one. Omitting or changing it can delay crediting or make recovery difficult.
The deposit address and receiving address serve opposite directions. The deposit address receives the asset you send into the exchange; the receiving address gets the converted asset. If the wallet cannot produce a compatible destination or required extra identifier, choose a supported receiving arrangement before creating a deposit.
Choose the Rate Type Before the Clock Starts
The rate choice determines how to interpret the saved output figure. A floating rate records an estimate because market prices, liquidity, and confirmation time can affect the final amount. A fixed-rate exchange protects the displayed receiving amount only when the deposit meets the time and confirmation conditions shown for that exchange.
Record both the rate type and any displayed deadline. A fixed selection does not preserve its terms indefinitely, and a late confirmation can lead to a failed exchange, a refund option, or a revised rate. If the sending wallet cannot meet the displayed conditions, stop before depositing and create a new request when ready.
Floating-rate flexibility does not remove the minimum deposit or compatibility checks. The quote remains useful as a starting record, but the delivered amount must be assessed under the floating conditions selected at creation.
What Changes When the Deposit Is Sent?
The deposit moves the task from editable preparation to an on-chain transfer. Before sending, you can leave an incorrect exchange and create another. After the deposit receives blockchain confirmation, the transfer cannot be cancelled, so changes to the recipient or selected network may no longer be available.
The sending wallet may charge its own network fee for the deposit. Check whether it adds that fee to the total debit or subtracts it from the entered amount, since the exchange must receive at least the displayed minimum. Use only the deposit address and amount associated with the current Exchange ID.
Once broadcast, save the deposit TXID instead of repeating the transfer when a status update takes time. Checking the TXID’s blockchain state alongside the exchange status distinguishes a pending confirmation from a confirmed deposit the exchange has not yet matched to its record.
Read Status as Progress, Not Final Proof
An exchange status reports the service’s current processing state. Pending Deposit or Awaiting Your Deposit means it has not recognized the required transfer. Confirming means the deposit is accumulating blockchain confirmations, Exchanging covers conversion, and Sending indicates the payout is being dispatched.
The Finished status means the service has completed the exchange. That status is an important checkpoint, but the payout TXID and receiving wallet still show where the output went and whether the intended wallet recognizes it.
Failed, Verifying, Expired, and Refunded describe different exceptions. Failed indicates processing stopped, Verifying indicates additional monitoring, Expired means a required action was not completed within its applicable time, and Refunded means the deposited asset was returned. Keep the Exchange ID and relevant TXID available when asking support about any of these states.
Confirm the Receiving Wallet Entry
The receiving wallet supplies the final practical evidence for the task. Compare the payout TXID with the intended address, selected asset, network, amount, and confirmation state. A successful transaction on an unintended network or to an incorrect destination does not become correct because the exchange page says Finished.
The blockchain record and wallet display are separate views. If the payout is confirmed at the intended address but the balance is absent, make sure the wallet is displaying the selected network and asset. A wallet may need to refresh or recognize the asset before showing it, but the on-chain destination and transaction state remain the stronger evidence.
If no matching payout transaction exists, keep the exchange record open. Do not create another exchange merely to test the same receiving address while the first result remains unresolved.
Compare the Quote With the Delivered Amount
The saved quote is the baseline for comparing the delivered amount. With a floating rate, a difference from the estimate does not by itself show a processing error because the rate is determined during the exchange. With a fixed rate, compare the payout with the protected amount only if the deposit satisfied the displayed timing and confirmation conditions.
Keep unlike amounts separate during the comparison. The input and output may represent different assets, while the sending wallet’s network fee belongs to the deposit side. Compare the payout amount with the saved receiving figure, then use the chosen rate type to interpret any difference.
Asset, network, or destination mismatches require a different response from an amount variance. A rate movement can explain a floating output change; it cannot explain delivery on an unintended network or to the wrong address.
What If the Records Do Not Agree?
A record mismatch should be narrowed to the first point where the evidence diverges. If the deposit TXID shows a confirmed transfer but the exchange remains at a deposit or confirmation status, compare the transaction’s destination and amount with the deposit instructions tied to the current Exchange ID. Also check whether the blockchain has reached the required confirmation state.
Do not send a second deposit to force a status change. Preserve the exchange page, Exchange ID, and deposit TXID, then provide those details through the support channel if the status does not progress. This keeps the investigation tied to one transfer and avoids mixing two deposits with one request.
A support request should describe the mismatch plainly: the deposit is confirmed on-chain, but the exchange status has not advanced. Share identifiers privately, without exposing wallet balances, unrelated addresses, or credentials.
Close the Task on a Verified State
The task reaches a verified end state when the saved request, Finished exchange record, payout TXID, and receiving wallet entry agree on the asset, network, and destination, and the delivered amount is consistent with the applicable rate conditions. Retain the minimal record until the payout is settled and visible.
If the status says Finished but no matching payout reaches the intended wallet, the task remains unresolved. Keep the exchange evidence together and continue with the existing support case rather than treating the label alone as completion.
Before you start with Simpleswap
Do I Need a Simpleswap Account to Track My First Exchange?
No. Most crypto-to-crypto exchanges can be created without an account. Save the unique Exchange ID or exchange link so you can return to the status record and identify the swap if support is needed. An accountless exchange can still enter additional verification when compliance or monitoring requirements apply, so the absence of sign-up does not promise an exchange without further checks.
Can a Transaction Hash Replace the Exchange ID?
No. A transaction hash identifies a transfer recorded on a blockchain, while the Exchange ID identifies the service-side exchange. Support may need both because the transaction hash lets the team inspect the deposit or payout on-chain, while the Exchange ID locates the exchange record. Keep each identifier labeled so a deposit TXID is not mistaken for a payout TXID or an Exchange ID.
Is a Screenshot of the Exchange Page Safe to Share Publicly?
A public screenshot can expose the Exchange ID, wallet addresses, transaction details, amounts, or a link containing the exchange identifier. Crop or redact those fields before sharing an image. Send the complete Exchange ID and relevant TXID only through the support channel handling the case, and never include wallet credentials, seed phrases, or private keys.
Does Creating a Second Quote Update the First Exchange?
No. Each exchange has its own Exchange ID, displayed terms, and processing record. Treat a second quote as a separate request rather than an update to the first one. Keep its minimum, rate type, recipient details, and deposit instructions together, and do not combine an address or amount from one exchange with the identifier from another.
Why Can Confirmation Requirements Differ Between Exchanges?
Confirmation requirements are not a universal count across every blockchain and asset. They can reflect the selected network and the conditions used to process the exchange. Follow the current exchange status rather than assuming a count learned from another transfer applies. If the deposit TXID is confirmed but the status remains unclear, provide both identifiers to support instead of sending again.
What Does a Verifying Status Mean on a First Exchange?
Verifying means the transaction is undergoing additional monitoring rather than following the ordinary processing sequence. Contact support with the Exchange ID and relevant TXID, then follow the case-specific instructions. Additional identity, address, source-of-funds, or transaction information may be requested when compliance requirements apply. The status alone does not establish whether the exchange will continue, fail, or be refunded.