Simpleswap withdrawals are wallet payouts awaiting chain confirmation

Last updated: 26 Jul 2026

Simpleswap withdrawals are outbound swap payouts broadcast to the recipient address on the exact network selected in the exchange. A payout isn’t complete merely because the service has calculated the output: the sending transaction still needs inclusion and confirmation under Bitcoin, Ethereum, Solana, XRP Ledger, or another destination chain’s rules. The receiving wallet then indexes that confirmed transaction and displays the asset. This page follows that narrow path from quoted payout and network fee through address routing, TXID evidence, confirmation depth, and delayed-balance diagnosis. It also separates Simpleswap’s exchange status from the blockchain state, because those two clocks describe different layers of the same withdrawal.

In short: One wrong chain ID can leave a confirmed payout invisible in the intended wallet view.

Payout costs inside the quoted amount

The payout amount reflects the selected rate mode and receiving-chain network cost, while the sender separately pays the deposit transaction’s network fee.

Simpleswap doesn’t publish a single percentage commission for every crypto-to-crypto swap. Its quote combines the exchange rate and service economics, while the output-chain transaction requires a network fee. On a fixed-rate exchange, the displayed receiving amount already includes the fee for sending the converted asset to the recipient. On a floating rate, the receive figure remains an estimate until processing uses the available market rate. Neither mode absorbs the separate fee the user’s wallet pays to send the input asset. For Bitcoin, 1 BTC equals 100,000,000 satoshis. Ethereum accounts use wei, where 1 ETH equals 1,000,000,000,000,000,000 wei.

Fixed-rate output

A fixed-rate quote locks the exchange rate for 20 minutes and requires at least one deposit-chain confirmation within that window.

If the confirmation arrives after the lock expires, Simpleswap may offer a recalculated exchange or a refund rather than preserve the original output. That event precedes withdrawal broadcast; once the payout has a TXID, confirmation timing belongs to the destination chain.

Deposit-side network cost

The sending wallet funds the input-chain fee separately, so the amount leaving it exceeds the amount deposited when the wallet adds its fee on top. If it subtracts the fee instead, the exchange receives less than intended, which can affect processing before any payout exists.

Worked example

Every changing input in this hypothetical example is identified here: the selected route is BTC to ETH, the fixed quote promises 0.250 ETH, and the Bitcoin deposit earns its first confirmation at minute 8. Because that confirmation falls inside the 20-minute lock and the receiving-side network fee is already included, the transaction’s expected Ethereum output is 0.250 ETH. Later wallet display timing doesn’t reduce that number; it reflects confirmation and indexing.

Network identity before payout

The recipient address must match both the output asset and its blockchain, because address syntax alone doesn’t always reveal the destination network.

Ethereum-style addresses create a specific ambiguity: the same 20-byte account appears as 40 hexadecimal digits with a 0x prefix, yet the text doesn’t identify its chain. Ethereum Mainnet uses chain ID 1, BNB Smart Chain uses 56, Polygon PoS uses 137, and Arbitrum One uses 42161. A wallet can accept the same 42-character address on all four networks while keeping balances in separate ledgers. USDT on Ethereum follows ERC-20; USDT on BNB Smart Chain follows BEP-20. Selecting the wrong network changes the asset’s ledger context even when every address character matches.

EVM network identity

MetaMask and Trust Wallet separate balances by network view, contract address, and account. A confirmed ERC-20 transfer on Ethereum won’t appear under BNB Smart Chain, while an Arbitrum One token requires the Arbitrum network view and the correct contract.

Memo and tag routing

The XRP Ledger uses a Destination Tag to map a payment sent to a shared address to the intended customer record. The tag is a 32-bit unsigned integer, so its range runs from 0 through 4,294,967,295. XRP itself uses drops: 1 XRP equals 1,000,000 drops. When a receiving platform supplies a tag, Simpleswap needs the address-and-tag pair for correct off-ledger crediting.

Confirmation clocks across destination chains

Alongside that, Simpleswap withdrawals inherit the destination chain’s settlement clock, so one universal payout time or confirmation count would describe the mechanism incorrectly.

Bitcoin targets a 10-minute average block interval. A transaction receives confirmation 1 when miners include it in a block, then gains another confirmation with every block built above it. At the target cadence, six confirmations span about 60 minutes, although actual blocks arrive irregularly. A receiving wallet or platform chooses its own required depth, so broadcast time and spendable-balance time remain separate.

Ethereum divides time into 12-second slots, and 32 slots form a 6.4-minute epoch. One slot presents an opportunity for a validator to propose a block, but an empty slot doesn’t confirm a pending payout. Wallets may show an included transfer before Ethereum reaches the stronger “safe” or “finalized” block states exposed by JSON-RPC.

XRP Ledger reaches a new validated ledger roughly every 3 to 5 seconds, and validation makes included results immutable under its consensus model. Solana instead exposes processed, confirmed, and finalized commitment levels. These names describe different confidence stages, so comparing chains by the word “confirmation” alone produces a false equivalence.

When has the payout actually arrived?

A payout has arrived on-chain when its TXID resolves on the selected network, records the supplied recipient and amount, and shows the expected finality state (compare Simpleswap requirements ).

Use the payout TXID, not the recipient wallet’s notification, as the primary record. Bitcoin hashes a raw transaction into a 32-byte TXID, typically displayed as 64 hexadecimal characters. Ethereum transaction hashes also occupy 32 bytes and appear with a 0x prefix. Before inclusion, a Bitcoin transfer has 0 confirmations; the block containing it supplies confirmation 1, and each later block increases the count. An Ethereum explorer distinguishes pending, successful, and failed execution, while the wallet interface might refresh later. Match the asset, chain, recipient, and amount before treating the balance display as authoritative.

The same question is answered in Simpleswap checklist. The Exchange ID identifies the Simpleswap order, while the payout TXID identifies the blockchain transaction. Keep both identifiers until the receiving wallet has indexed the final balance.

Reading Simpleswap’s exchange states

Where that applies, Simpleswap’s status tracker describes service-side progress, whereas a chain explorer reports whether the deposit or payout has reached network consensus.

Sending and Finished

Sending means the exchange has reached the payout stage and is sending the converted asset to the recipient wallet. The useful transition is the appearance of a payout TXID.

Finished means the service regards the exchange as completed. A wallet can still apply its own confirmation threshold or indexing delay after that state appears. Compare the displayed payout TXID with the destination chain before assuming a late notification represents a missing transaction.

Confirming, Verifying, Failed, Expired, and Refunded

Confirming refers to the incoming deposit, not the later wallet payout. The remaining states describe an interrupted, reviewed, expired, or reversed exchange path.

Verifying marks additional transaction monitoring. Failed and Expired require resolution before a normal payout completes, while Refunded sends the input asset back through a separate blockchain transaction. These states belong to the exchange order, so the Exchange ID is the useful service reference; any actual refund or payout needs its own TXID for chain-level proof.

Diagnosing a payout with no settled balance

A delayed balance becomes diagnosable once the service status, payout TXID, explorer result, destination network, and wallet view are treated as separate observations.

If Sending appears without a usable TXID, the withdrawal hasn’t yet produced public chain evidence. If a TXID exists but no explorer on the selected network recognizes it, the purported broadcast isn’t yet observable. A recognized pending transaction is already a different case: it has reached network infrastructure but still awaits inclusion. Once execution succeeds, a missing wallet balance points toward confirmation policy, network selection, token indexing, or an omitted destination identifier.

A recent Solana blockhash remains valid for 150 slots, while every Ed25519 transaction signature occupies 64 bytes. A transaction that doesn’t land inside that validity window expires and needs a newly signed submission. Solana charges a base fee of 5,000 lamports per signature, and 1 SOL contains 1,000,000,000 lamports; optional prioritization fees add to that base.

Support needs the Exchange ID to locate the order and the payout TXID to trace a broadcast. Add the selected ticker, network, recipient address, and observed status. Those fields distinguish an exchange-layer delay from an already settled transfer.

Where direct wallet payouts fit

Direct wallet payouts fit recipients who control a chain-compatible address and are prepared to verify settlement independently of a service notification.

A self-custody destination such as MetaMask, Trust Wallet, Ledger, Trezor, or Exodus exposes the on-chain asset after the wallet indexes its network and token contract. A custodial destination adds an internal crediting layer, especially for XRP Destination Tags and similar identifiers. Simpleswap withdrawals therefore work most cleanly when the recipient knows the exact chain, saves the Exchange ID, and reads the payout TXID through that chain’s explorer. The exchange page describes the order; the ledger establishes delivery.

Practical questions