Simpleswap
Simpleswap limits for comparing and reconciling withdrawals
Last updated:Simpleswap limits determine whether an exchange request can proceed and which deposit amounts it can accept. The transfer records and destination balance show whether a payout or refund arrived. The displayed minimum is specific to the selected pair and networks, while capacity, authorization, and processing state may change with the request. Reconciliation therefore follows the order record, blockchain transfers, and destination balance rather than a single status label.
On this page, withdrawal means the outgoing settlement from a swap or refund, not a withdrawal from a stored customer balance. Compare options using the same requested assets, amount, rate type, networks, destination, and supporting records.
The short version: Match each exchange request to its authorization state, transfer hashes, and destination balance before treating its payout or refund as settled.
Limits that apply before funding
A displayed minimum is a live acceptance condition for the selected assets, networks, and amount. It can reflect network costs, available liquidity, and current exchange conditions. If the planned deposit falls below that figure, the safe exit is to leave the request unfunded and obtain a new range. Sending first and checking later can leave an amount that cannot complete and may not qualify for a refund.
Simpleswap states that floating-rate exchanges have no strict upper amount limit. That service-level rule does not guarantee acceptance of every requested amount. Liquidity, network conditions, internal checks, and transaction-specific restrictions can still affect execution. Fixed-rate availability may also carry an upper bound and a deposit-confirmation window. The values shown for the particular request govern the next action.
Three records for one withdrawal
Reconciliation separates the exchange request, the blockchain transfers, and the destination balance. These records answer different questions, so one cannot replace the others.
The request record
The request record establishes the selected input and output assets, both networks, the deposit amount, rate type, receiving address, and any required memo or tag. It also supplies the Exchange ID and the amount constraints displayed when the request was created. Preserve this version because a later quote may carry different limits or expected output.
The blockchain transfer record
The transfer record begins with the deposit transaction hash, often called a transaction ID or TXID. It shows the asset, network, amount delivered, relevant input and output address data, and confirmation state. A separate payout or refund TXID is needed for the outgoing leg. One hash cannot prove both transfers because each represents a distinct blockchain transaction.
The destination record
The destination record shows whether the intended wallet or credited account received the correct asset on the selected network. Compare its credited amount with the applicable settlement figure, not automatically with the first estimate. A floating-rate estimate, fixed-rate amount, and refund amount have different bases and should remain separate.
Three stages from request to destination
When the proposed amount is near a displayed limit, trace these three stages. On the normal path, each stage supplies evidence for the next one. An amount change, an authorization decision, or a missing transfer record breaks that chain.
| Stage | Evidence of normal progress | Main limit or failure signal |
|---|---|---|
| Request and authorization | The order records the pair, networks, amount, rate type, destination, and applicable range. | The amount is outside the displayed range, the fixed-rate conditions lapse, or verification interrupts acceptance. |
| Deposit and processing | The deposit TXID matches the requested asset, network, address, and amount, then accumulates confirmations. | An insufficient or excess deposit, wrong network, missing identifier, or unresolved confirmation prevents a clean match. |
| Payout or refund | An outgoing TXID identifies a transfer to the eligible receiving or refund address on the correct network. | No outgoing hash appears, the destination data differs, or the credited amount cannot be reconciled to the applicable terms. |
The normal path assumes that the accepted request remains valid and both transfer legs appear on their selected networks. If the amount or authorization changes, the original expected payout no longer proves completion. An agreed new rate or eligible refund may become the valid exit. The case closes only when its outgoing transfer and destination record agree.
How can a finished payout still look missing?
A Finished status means the service considers the exchange complete, while the payout TXID and destination record show where the assets went. Check whether the outgoing transaction exists, has reached the required confirmation state, and names the intended address on the selected network. A status label without an outgoing hash cannot establish the destination balance by itself.
If the blockchain record confirms the transfer to the correct address, compare the wallet view with that same asset and network. A wallet interface may not present every supported asset in the same place. If the transaction is absent, unconfirmed, or addressed elsewhere, the discrepancy belongs to the transfer record rather than the displayed balance.
Like-for-like comparisons across withdrawal options
A fair comparison holds the requested assets, networks, input amount, and rate type constant. It then compares the displayed range, authorization requirements, expected settlement basis, and evidence supplied after processing. Mixing a fixed-rate commitment with a floating-rate estimate produces an apparent difference that does not describe the same obligation.
Timing also changes the comparison. A later request may encounter different liquidity, network conditions, or amount bounds, so it is not a control for an earlier one. Compare each completed withdrawal with its own saved request and outgoing TXID. Use another request only to evaluate the available option under its separately recorded conditions.
Authorization before settlement
Authorization can stop an otherwise supported request before settlement. Crypto-to-crypto exchanges may proceed without account creation, but Simpleswap or a participating provider can request Know Your Customer (KYC) information when monitoring, anti-money laundering requirements, or other compliance conditions apply. A Verifying status represents that review, not an estimate of queue duration.
When verification appears, preserve the Exchange ID and deposit TXID, then contact support through an official service channel. Do not create another transfer to force progress. A legitimate investigation may request evidence about the transaction or ownership, but it does not require a wallet seed phrase or private key. Those credentials do not help reconcile a payout.
Pending states without a timing promise
Pending states identify the current stage but do not promise a completion time. Awaiting a deposit means the service is waiting for funds at the assigned deposit address. Confirming means the deposit is accumulating the network confirmations required for processing. Exchanging and Sending indicate later service stages, although neither proves that the destination has credited the final amount.
Blockchain congestion, transaction replacement, compliance review, and service processing are different conditions. Recheck when the underlying record changes: a deposit confirms, a payout TXID appears, or the service requests action. An unchanged clock alone does not reveal which constraint applies.
Changed amounts and partial outcomes
A changed payout is reconciled against the selected rate type. A floating-rate request begins with an estimate, and the final amount can move as the market rate and liquidity change during processing. A fixed-rate amount applies only while its stated deposit and confirmation conditions remain satisfied. If those conditions lapse, the request may fail, move to a newly agreed rate, or become eligible for a refund.
A partial-looking outcome needs separate figures for the delivered deposit, executed output, payout, and refund. Do not subtract unrelated numbers until the transfer direction and asset match. A refund may also reflect network or recovery charges allowed for that case. The Exchange ID, both TXIDs, and the applicable rate record should explain the difference without treating the initial estimate as a settled balance.
Refund paths after a stopped exchange
A stopped exchange has different exits depending on whether the deposit left the wallet and whether the order qualifies for a refund. The absence of a payout does not itself prove that a refund has started.
Unfunded requests
An unfunded request can generally be left unused. No blockchain transfer needs to be reversed because no deposit was sent. If its range, destination, or rate conditions are no longer suitable, create a fresh request and use only the new deposit details. The earlier deposit address should not be repurposed for another transaction.
Funded and failed exchanges
A confirmed blockchain transaction cannot be cancelled. After funding, Failed, Verifying, or Expired states require case-specific handling rather than another deposit. A refund or revised exchange may be offered when eligible, but neither outcome should be assumed before it appears in the case record. Save every instruction that changes the expected settlement.
The eligible refund destination
A refund may be sent to the original sending address or a refund address recorded for the request. In some cases, the original address may be the only available destination. Ownership confirmation can be required, and network or recovery costs may affect the returned amount. Reconciliation uses the refund TXID and the balance at the address that was actually approved.
Evidence that makes a discrepancy actionable
An actionable discrepancy states exactly where the records stop agreeing. It avoids broad claims such as missing funds when the unresolved point is a pending deposit, absent payout TXID, changed settlement amount, or uncredited destination transfer.
Exchange and transfer identifiers
The Exchange ID ties the case to one request, while the deposit, payout, and refund TXIDs identify separate transfers. Record only the hashes that exist. Do not invent a payout leg from a Finished status or treat a support message as blockchain evidence. Keep these identifiers private except when submitting them through the service channel handling the case.
Amounts, networks, and addresses
The amount trail should distinguish the wallet debit, amount delivered to the deposit address, applicable output figure, and destination credit. Record the asset and network beside each amount. Include the recipient or refund address and any required memo or tag. This structure exposes a network mismatch without blaming it on a rate or limit.
Status changes and requested action
The event trail should preserve status changes, transfer confirmation states, and any request for verification or approval of a new rate. Timestamps are useful as sequence evidence, not as a promise of completion. If support changes the expected exit, retain the instruction and compare the eventual outgoing transfer with that revised outcome.
The condition that closes reconciliation
Reconciliation ends when the applicable payout or refund TXID confirms on the correct network, points to the approved destination, and matches the destination record under the governing rate or refund terms. A service status can support that finding, but it does not replace the outgoing transaction.
If any limit, authorization condition, destination, or settlement basis changes, reopen the comparison at the stage where the change occurred. The updated record, rather than the original expectation, then determines whether the withdrawal is complete, recoverable, or still unresolved.
Simpleswap limits - common questions
Can a second transfer top up the same exchange?
A second transfer should not be assumed to complete the first deposit. Each deposit address is assigned to a particular transaction, and an additional transfer can be treated as inconsistent with that order or prompt creation of a revised order. Use the instructions attached to the existing case before sending more assets.
Does the sending wallet fee count toward the required deposit?
The sending wallet fee is separate from the amount that must arrive at the deposit address. Wallets can add the fee to the total debit or deduct it from the entered transfer, depending on their design. Confirm that the blockchain record shows the required deposit amount delivered, not merely the wallet’s larger or smaller debit.
Are refund network fees allowed to reduce the returned amount?
Refund network fees may be deducted in some cases, and exceptional recovery work can carry other charges. Reconcile the returned balance against the refund terms for that specific case and its refund TXID. A difference should not automatically be classified as a swap payout shortfall because the transfer serves a different settlement path.
Where can a refund be sent after an exchange fails?
An eligible refund may go to the original sending address or the refund address saved with the request. Simpleswap may limit a case to the original address, and proof of deposit ownership can be required. The approved destination and refund TXID determine whether the return completed, not the address originally intended for the swap payout.
Is a new swap created status proof that another deposit is required?
No, that status only indicates that a revised trade order was created for the case. Read the current order details and any accompanying instructions before acting. Another deposit is justified only when the revised request explicitly requires one; otherwise it could create a second mismatch instead of resolving the first.