Simpleswap requirements are a compatible wallet address and network match

Complete the address-first exchange sequence

Five ordered checks carry a SimpleSwap exchange from pair selection to a verifiable payout without mixing the deposit and receiving networks together.

First, select the asset you’ll send and the asset you’ll receive, then choose the network label for each side. Next, open the receiving wallet and reveal the deposit address for that exact asset-network pair. Copy the address and every companion identifier, paste them into the exchange form, and compare the pasted value with the wallet display. Create the exchange only after those fields agree. Save the Exchange ID. Finally, send the displayed deposit amount to SimpleSwap’s deposit address from the selected input network, retain the TXID, and watch the order reach Finished before treating the payout as complete.

A fixed-rate order locks its quote for 20 minutes, and the deposit needs at least one blockchain confirmation within that window. Confirmation speed belongs to the input network, so an address-perfect order can still outlive its rate lock. A floating rate removes the 20-minute lock, yet the same address, network, memo, and minimum-amount checks remain in force.

The exchange page supplies the deposit destination; the receiving wallet supplies the payout destination. Keep those two roles separate throughout the order.

Match asset and network before copying an address

Three identifiers - the asset, network, and recipient address - must agree because a valid string can still point to a different ledger or token system.

USDT illustrates the mechanism. On Ethereum it follows ERC-20; on TRON it follows TRC-20; on BNB Smart Chain it follows BEP-20; and on Solana it uses an SPL token mint. These balances don’t share one ledger. If the output reads USDT on TRON, the receiving wallet must show a TRON deposit route, not an Ethereum receive screen carrying the same ticker. The same check applies to USDC and other multichain assets. Read the network name in both interfaces: ticker equality identifies the asset, while network equality identifies its settlement path. More context is available in Simpleswap withdrawals.

Address validation tests only part of the requirement. A 0x string can pass format checks on Ethereum, Base, and BNB Smart Chain because those networks share an account format. The network label tells SimpleSwap which ledger should receive the payout.

Treat identical EVM addresses as network-specific destinations

Six EVM mainnets share the familiar 0x address shape, yet their chain IDs separate Ethereum, BNB Smart Chain, Polygon, OP Mainnet, Base, and Arbitrum One.

Address structure

An Ethereum address is 20 bytes and displays as 40 hexadecimal characters plus the 0x prefix, for 42 characters total. EIP-55 adds a mixed-case checksum capable of catching transcription mistakes, although many tools also accept lowercase forms. Copy the complete string from MetaMask, Trust Wallet, or a device companion app; don’t retype it or change its letter case. The format identifies an EVM account shape, not a specific EVM chain.

Network identity

Chain IDs

Ethereum mainnet uses chain ID 1; OP Mainnet uses 10; BNB Smart Chain uses 56; Polygon PoS uses 137; Base uses 8453; and Arbitrum One uses 42161. Wallets use these identifiers to select a ledger, while SimpleSwap presents human-readable network labels. The chain ID doesn’t appear inside the 42-character address, which explains why identical-looking destinations still settle on separate networks.

Token contracts

An ERC-20 contract identifies a token on one chain; the recipient field still expects the user’s account address. Check the token contract or wallet asset page only to confirm identity. Don’t paste the USDT or USDC contract address as the payout destination.

Read non-EVM address formats without guessing

Four non-EVM families expose different address rules: Bitcoin, TRON, XRP Ledger, and Solana each encode destinations with their own structures and checksums. Bitcoin mainnet SegWit addresses begin with bc1, and Bech32 strings cap at 90 characters. TRON Base58Check addresses contain 34 characters and start with T. XRP Ledger classic addresses span 25 to 35 characters and start with r. Solana represents each account with a 32-byte address encoded in base58. A valid format narrows the possibilities; SimpleSwap’s selected network decides compatibility.

Supply memo and tag fields as part of the destination

Two destination components - the base address and its memo or tag - form one routing instruction whenever the receiving service assigns users a shared account.

XRP Ledger Destination Tags use 32-bit unsigned integers. Stellar supports a 28-byte text memo, a 64-bit unsigned Memo ID, or a 32-byte hash memo. These values route one shared on-chain address to the correct internal balance. SimpleSwap may label the extra field as MEMO, Destination Tag, Payment ID, Message, or Extra ID. Use the exact label and value supplied by the receiving platform, without trimming, translating, or rewriting it.

Copy both fields from the same deposit screen. An address saved earlier and a newly issued tag aren’t a dependable pair.

A self-custody wallet may not provide an extra identifier. Leave the field unset only when the receiving wallet and exchange form both indicate an address alone is sufficient; don’t invent a memo for an optional field.

Confirm token standards and contract identity

Three token systems - ERC-20, TRC-20, and SPL Token - show why ticker matching alone doesn’t prove the receiving wallet supports the selected asset.

ERC-20 tokens run through token contracts on Ethereum and compatible EVM networks. TRC-20 tokens run through contracts on TRON, while SPL Token and Token-2022 define token accounts on Solana. A USDC or USDT balance on one of these systems isn’t automatically the same deposit route on another. Open the wallet’s receive screen and confirm all three nouns: asset, standard, and network. MetaMask works with EVM chains, TronLink exposes TRON addresses, and Phantom exposes Solana accounts. Those interfaces provide the recipient account; the token contract or mint provides a separate identity check for that asset.

Wallet software can hide an unsupported token until its contract or mint is added. That display issue doesn’t move the balance between chains; inspect the intended network first, then add the verified asset representation inside the wallet.

Use the receiving wallet as the compatibility test

Five yes-or-no conditions establish wallet compatibility before SimpleSwap creates an order, and each condition is visible in the receiving wallet or deposit screen.

Use this short decision checklist before creating the exchange:

• The SimpleSwap output lists the same asset and network as the wallet’s receive screen.
• The address comes from a mainnet account, not a testnet account or developer faucet.
• The destination supplies every required memo, tag, Payment ID, Message, or Extra ID.
• The wallet or custodial platform accepts the selected token standard at that address.
• The expected payout clears the receiving platform’s own deposit minimum and credit rules.

Simpleswap requirements pass only when all five conditions are true. If one answer remains uncertain, change the output network or receiving wallet before generating an order. A new address on the correct ledger is cleaner than adapting an incompatible destination.

Keep deposit-side and payout-side requirements separate

Two blockchain transfers surround every completed crypto-to-crypto exchange: your deposit reaches SimpleSwap first, and the converted asset then reaches your recipient address.

On the deposit leg, your wallet sends the input asset to the address SimpleSwap displays. It must use the input network and cover that chain’s transaction cost. Token deposits require the relevant gas asset or network resource: ETH on Ethereum, BNB on BNB Smart Chain, POL on Polygon PoS, SOL on Solana, or TRX resources on TRON. The recipient wallet isn’t involved in this transfer.

On the payout leg, SimpleSwap sends the converted asset to your recipient details. For a fixed-rate exchange, the displayed receiving amount already includes the payout network fee, while your deposit-side fee remains separate. Compare the destination TXID with the recipient address and selected network before marking the order complete.

Two ledgers may therefore appear in one order. Treat each leg as its own asset-network pair instead of assuming the output follows the input route.

Check temporary and special destinations before reuse

Three destination types deserve fresh data for every order: Lightning invoices, custodial deposit details with extra IDs, and exchange-specific addresses shown for a new transaction.

When Bitcoin Lightning appears as the output network, the destination is a Lightning payment invoice rather than a Bitcoin base-layer address. A BOLT 11 invoice carries a payment hash, timestamp, signature, and optional expiry field. If the invoice omits that field, the protocol default is 3,600 seconds, or 1 hour. Wallets can set a different explicit expiry, so generate the invoice close to order creation and ensure it covers the expected payout.

A custodial platform may rotate addresses or issue a new memo for each deposit. Copy the complete deposit details from the platform’s active receive screen, not a previous transfer record. Saved self-custody addresses are more stable, yet the asset and network still need a fresh check.

In that configuration, SimpleSwap creates a separate Exchange ID for every swap. Use the deposit address displayed inside that order and keep its ID with the input TXID. Fresh order data is preferable to a remembered destination when any temporary field is involved.

Clear recipient-field errors before funding the order

Four pre-deposit failures have distinct causes: invalid syntax, unsupported network, missing extra ID, and an output wallet that doesn’t accept the chosen token standard.

An invalid-address message first calls for a clean copy from the wallet’s receive screen. Remove accidental spaces, then compare the complete value. If the syntax passes but the network remains unavailable, choose another supported output network or a wallet capable of receiving the offered network. When the form requests a memo or tag, return to the recipient platform and obtain it there; formatting guesses don’t create a valid routing value.

Some chains expose several legitimate destination formats. Bitcoin supports legacy, nested SegWit, native SegWit, and Taproot forms, while XRP Ledger supports classic addresses and X-addresses. Use a format the SimpleSwap field accepts and the receiving wallet directly generated; manual conversion adds another point of mismatch.

If an unfunded order contains wrong recipient details, leave it unused and create a new exchange. Once the deposit has been sent, don’t open a second order for the same funds. Preserve the Exchange ID and TXID so support can identify the exact transaction state.

A fresh receive screen resolves most pre-deposit ambiguity. It gives stronger evidence than an address copied from old history, especially when a tag or invoice expires.