Key takeaways
A test amount is not an arbitrary small round number; it must be large enough to credit yet affordable to lose.
The test passes completely only when the destination balance actually increases.
Valid lower bound = max(W, D + F)Calculate the lower bound of a valid test
Write down three values: source withdrawal minimum W, network fee F on the final screen, and destination deposit minimum D. When the fee is deducted from the request, the mathematical lower bound is max(W, D + F). If the platform charges F separately, compare W with D instead. The final screen’s actual received amount is therefore authoritative.
That lower bound is not yet a recommendation. Leave a small buffer above it, but keep the upper bound within what you are willing to lose to one address or network mistake. If platform thresholds exceed that loss limit, do not force the test; use another mutually supported route with lower thresholds.
Work through a hypothetical example
Suppose W = 8 USDT, the fixed fee F = 1 USDT, and the destination minimum D = 10 USDT, with the fee deducted from the request. The lower bound is max(8, 10 + 1) = 11 USDT: request 11 and expect 10. To avoid sitting exactly on a rounding, fee-update, or input boundary, choose slightly above 11 while staying within your loss limit.
By contrast, a request of 8 clears the source minimum but leaves only 7 after the fee, below the destination threshold. It may confirm on-chain without automatic crediting, so it is not a valid route test. These numbers illustrate the method and are not current parameters for any platform.
A passed test needs four pieces of evidence
First, the source record must show the intended asset, network, address, and request amount. Second, the TXID must be successful or confirmed on the correct network explorer. Third, its on-chain destination must match the current deposit page. Fourth, the available or designated destination balance must actually increase.
Do not send the remainder if any item is missing. In particular, on-chain success proves only that the network processed the transfer; it does not prove that an exchange recognized the asset, reached its confirmation threshold, and credited your account.
Changes that invalidate an earlier test
A new destination address, network, source or destination platform, or first use of an allowlist entry creates a new route. Treat an old success as expired after a long gap, address rotation, recently ended maintenance, or a change in minimums or fees.
A successful test does not lock later conditions. Before sending the remainder, reopen both the deposit and final confirmation pages and recheck the address, network, Memo/Tag, fee, and actual receipt. Testing reduces operational uncertainty; it does not transfer responsibility for the next transaction.
FAQ
Is the fee deducted from the request or charged separately?
Either model may be used, so do not assume. Read the request, network-fee, and actual-receipt fields on that withdrawal confirmation screen, then compare actual receipt with the destination minimum.
Can a test be below the deposit minimum?
It should not. A below-minimum deposit may not credit, fails to validate the route, and can create recovery cost.
Must every transfer be tested?
Testing is especially useful for a new address, network, rule change, or large amount. Always recheck the current deposit page even when not retesting.
How long before a test transfer counts as successful?
Wait until the destination balance actually increases, not until the chain shows success. Between those two events sit the destination’s confirmation requirement and its crediting process. If the chain succeeded but the balance has not moved, the test has not passed.
Sources and verification
Sources prioritize protocol, network, and exchange documentation. External pages can change; signed-in confirmation screens remain authoritative for fees and account status.
- BinanceHow to deposit and withdraw cryptocurrencyChecked 2026-09-04
- OKXDeposit and withdrawal fee guidanceChecked 2026-09-04
- OKXWhy a deposit has not been creditedChecked 2026-09-04