Simpleswap Simpleswap is a wallet flow from network check to finished status
Updated:
Simpleswap is an interface that turns a wallet-to-wallet exchange into a traceable sequence: choose the exact asset network, review the quote and recipient details, send the deposit, and follow confirmation through payout. Each state reflects a specific handoff between your wallet, a blockchain, the exchange route, and the receiving wallet.
Jump to a section
Key takeaway: A fixed-rate order needs at least one blockchain confirmation inside its 20-minute lock.
Matching the asset to its network before quoting
One matching ticker doesn't prove network compatibility, so the first Simpleswap decision is pairing the asset with the exact chain accepted by the receiving wallet.
Ticker and token standard
USDT shows why ticker matching alone fails. USDT appears on Ethereum under ERC-20, on TRON under TRC-20, on BNB Smart Chain under BEP-20, and on Solana through the SPL Token program. The receive screen must identify the same route selected in the swap interface. BTC on the Bitcoin network is separate from tokenized forms of Bitcoin, while native ETH on Ethereum is separate from ETH represented on another chain. The selected row defines the blockchain that will carry the payout, not just the symbol displayed beside the amount.
EVM routes that share an address shape
Ethereum-compatible networks make the network check harder because several chains accept the same visual address format. An Ethereum-style address contains 20 bytes, printed as 40 hexadecimal characters after the 0x prefix, for 42 characters in total. Ethereum mainnet uses chain ID 1, BNB Smart Chain uses 56, Polygon PoS uses 137, and Arbitrum One uses 42161. A valid-looking address therefore proves the format, not the route. Simpleswap's network label and the wallet's active network must name the same chain before the quote matters.
Wallet confirmation before exchange creation
MetaMask exposes the active EVM network, while Phantom identifies the selected Solana account. Solana addresses encode 32-byte public keys in base58, so their shape differs from EVM addresses. Copy the receive address from the asset's deposit screen, preserve its case, and compare the first and last 6 characters after pasting. This check has one firm boundary: address inspection never substitutes for the network label shown by the receiving wallet.
What appears before you create the exchange?
Two rate modes, 1 send amount, the output estimate, and the recipient details form the Simpleswap decision record before any deposit address exists.
Amount and quote precision
The amount field works in the input asset's native units, while the displayed minimum belongs to that specific pair and moment. Bitcoin represents 1 BTC as 100,000,000 satoshis, giving it 8 decimal places. Ethereum represents 1 ETH as 1,000,000,000,000,000,000 wei, or 18 decimal places. Those fixed units explain why a wallet balance that looks rounded may still be slightly short. The order amount excludes the deposit network fee charged by the sending wallet, so leave that fee asset outside the amount entered.
Recipient and refund details
The recipient field controls the final payout, and some routes add a MEMO, Destination Tag, Payment ID, or Extra ID. A refund address, when requested, must accept the original deposit asset on its selected network. Review the asset names, network labels, exact amount, rate type, recipient address, and extra identifier together. Creating the exchange freezes this data into one order and produces its unique Exchange ID; it doesn't broadcast a blockchain transaction or move the wallet balance.
Fixed or floating execution
Floating mode shows an estimate that is recalculated when the route processes the deposit. A fixed rate is locked for 20 minutes and requires at least 1 blockchain confirmation inside that window. That clock makes the sending chain's confirmation pace part of the choice. The output-side network cost is included in the fixed-rate amount shown, while the input wallet charges its own deposit fee separately.
Worked example: every changing input here is hypothetical - a send amount of 0.010 BTC, a displayed minimum of 0.002 BTC, a wallet miner fee of 0.0002 BTC, and a fixed output of 0.18 ETH. The wallet needs 0.0102 BTC in total, and the order amount stands 0.008 BTC above the displayed minimum. After confirming Ethereum as the output network and checking the ETH address, the concrete result is a funded, createable order whose displayed output is 0.18 ETH during its lock.
From deposit address to finished status
Five forward states - Pending deposit, Confirming, Exchanging, Sending, and Finished - describe the normal Simpleswap path after an order exists, with each label marking a different system or network action. Pending deposit means no qualifying transfer has been detected; Confirming means the input chain is accumulating the required confirmations. Exchanging covers route execution, Sending covers payout broadcast, and Finished records completion. Failed, Verifying, Expired, and Refunded bring the full status set to 9 labels. Keep the Exchange ID until Finished and the payout transaction appears on-chain.
Verifying both blockchain legs
Two transaction records provide independent proof of progress: the deposit TXID from the sending wallet and the payout hash on the destination chain.
Deposit proof
Open the deposit TXID in an explorer that matches the sending network. Blockchair can display Bitcoin activity, Etherscan covers Ethereum, TronScan covers TRON, and Solscan covers Solana. Confirm the destination address, transferred asset, amount, block inclusion, and confirmation count. A Bitcoin TXID is a 32-byte hash shown as 64 hexadecimal characters, and the network targets one block every 10 minutes. Ten minutes is a protocol target rather than a countdown; a Pending transaction still hasn't supplied the confirmation that a fixed-rate order requires.
Payout proof
The payout belongs in the explorer for the output network, even when its address resembles one on another EVM chain. Ethereum transaction hashes contain 32 bytes and display as 64 hexadecimal characters after 0x, making 66 visible characters. Ethereum divides time into 12-second slots, with 32 slots in an epoch; an empty slot means those figures don't promise delivery time. Match the hash recipient to the address saved in the order, then verify the token contract for ERC-20 transfers. Finished status and explorer data should describe the same destination event.
What happens when a MEMO is missing?
One missing MEMO can separate a valid on-chain payout from the receiving service's internal credit, because the shared address doesn't identify an individual account.
The XRP Ledger uses a 32-bit unsigned Destination Tag, allowing values from 0 through 4,294,967,295. Stellar defines 4 memo types: text, ID, hash, and return. A Stellar text memo holds up to 28 bytes, while its memo ID is a 64-bit unsigned integer. These fields don't change the blockchain address. They give a custodial recipient the routing data needed to associate XRP or XLM with the intended account after the transaction reaches its shared wallet.
If the deposit hasn't been sent, leave the incomplete order and create a new one with the correct identifier. Once the deposit is confirmed, cancellation is no longer a wallet action. Keep the Exchange ID, deposit TXID, recipient address, and intended tag together, then give those details to support. Recovery depends on the receiving route's ability to locate and reassign the payout, so the complete record is the practical limit of the interface.
The right fit for a one-off wallet transfer
Four prerequisites define a clean Simpleswap flow: an accepted pair, an amount above the displayed minimum, a network-matched recipient, and enough native balance for the deposit fee.
This sequence fits a discrete transfer where the user wants a quoted output sent directly to a known wallet. It works cleanly when MetaMask, Phantom, Ledger Live, Trezor Suite, or another wallet exposes the exact receiving network and later displays a transaction hash. The workflow also suits a payment to a custodial account when that account supplies its required MEMO or tag. The decision point arrives before order creation: the receiving system must state the asset, network, address, and any routing identifier in terms that match the form.
Execution becomes easy to audit when the Exchange ID and both chain records stay together. The interface tracks the order, explorers verify the transfers, and the receiving wallet confirms usable delivery. Create the exchange only after the receiver has supplied every required field.
Worth knowing
Can a Simpleswap deposit come from a centralized exchange?
Yes, a Simpleswap deposit can originate from a centralized exchange when that platform supports the exact asset, network, amount, and destination details shown by the order. The withdrawal screen must reproduce any MEMO or tag and leave enough balance for its withdrawal fee. Save the platform's withdrawal TXID. Batch withdrawals or delayed broadcasts can consume part of a 20-minute fixed-rate window, so a self-custody wallet gives tighter control over dispatch timing.
Where should the refund address point before execution?
The refund address should point to a wallet that accepts the original deposit asset on the same network. A BTC deposit needs a Bitcoin refund address; an ERC-20 USDT deposit needs an Ethereum address supporting USDT. Avoid a deposit-only address that expires or omits a required tag. If no refund address is supplied, the sending address may become the return destination, so confirm that it can receive funds.
What happens if the sent amount differs from the order amount?
An amount mismatch moves the order outside the exact inputs used to create its quote. A small excess or shortfall may trigger recalculation, manual review, cancellation, or a refund offer, based on the pair and provider route. Sending below the displayed minimum is particularly restrictive because network costs can consume the transferable balance. Keep the Exchange ID and TXID, don't send a second transfer to the same deposit address, and use support to establish the available outcome before the order proceeds any further.
Does Finished mean the receiving wallet must already show the payout?
Finished means Simpleswap has completed the exchange and broadcast the payout, while a wallet interface may still need to refresh or index the destination transaction. Check the payout hash in the appropriate explorer and compare its recipient address, token contract where relevant, and status. Etherscan covers Ethereum activity, TronScan covers TRON, and Solscan covers Solana. If the explorer confirms delivery, adding the token account or refreshing wallet history often exposes the balance.
When is a new exchange order required instead of an old deposit address?
Create a new exchange order for every new swap, even when the asset pair and amounts look identical. Each order receives its own Exchange ID, quote context, recipient data, and deposit instructions; an earlier address may be tied to an expired or completed route. Reusing it disconnects the transfer from the state you're watching and can complicate reconciliation. Copy the deposit address only from the newly created order, then send once and preserve that order's identifiers through Finished status in the same browser session.
Should support receive the Exchange ID or the blockchain TXID?
Support should receive both identifiers because they describe different layers of the same swap. The Exchange ID selects the Simpleswap order and its internal status, while the TXID identifies a broadcast transaction on a blockchain. Include the deposit TXID first, plus the payout hash if one appears. Also state the asset, network, amount, recipient address, and missing MEMO when relevant; omit private keys, seed words, and wallet passwords entirely.