A legitimate cryptocurrency exchange requires transaction data, not the secret that controls your wallet. To send funds from a self-custody wallet, you normally need a receiving address, the correct asset and network, an amount, and sometimes a Memo or Tag. Your wallet uses the private key locally to sign the transfer. The private key itself—and the seed phrase from which wallet accounts may be restored—must remain secret.
Why an exchange does not need your wallet secrets
A private key authorizes transactions from the account it controls. A seed phrase, also called a recovery phrase or wallet backup, can restore access to the wallet and may expose multiple accounts derived from it. Anyone who obtains the relevant secret can attempt to move the assets without asking the original owner for further approval. Bitcoin documentation describes private keys as the credentials used to spend bitcoin, while Ethereum’s security guidance states that legitimate services and support agents do not need recovery phrases or private keys. [1]
| Information | Purpose in an exchange | Safe to provide? |
|---|---|---|
| Public receiving address | Identifies where the purchased or exchanged asset should be sent | Yes, after checking the asset and network |
| Transaction hash | Allows a transfer to be located in the relevant blockchain explorer | Generally yes |
| Application or order identifier | Connects a support request to the exchange operation | Yes, through the service’s designated channel |
| Memo, Tag, or similar destination identifier | Identifies the recipient account when the displayed deposit instructions require it | Yes, but only in the transaction field specified by the service |
| Seed phrase or wallet backup | Restores control of the wallet; it has no legitimate role in processing an exchange | No |
| Private key | Signs transactions and controls the corresponding account | No |
| Wallet password, PIN, or two-factor code | Unlocks a device or account and is not needed to verify an on-chain payment | No |
Identity or compliance information, when required, is a separate matter. Verification conditions can depend on the exchange direction and the results of compliance checks, so current requirements should be clarified before an application is created. No identity check requires disclosure of a self-custody wallet’s seed phrase or private key.
Operation state map: from exchange task to verified result
- State 1 — Define the task.
- Transition condition: you know which asset you are sending and which asset you expect to receive.
- Check: record the intended direction, destination wallet, and required amount without entering any wallet secret on a website.
- Success sign: the task can be stated clearly, such as “send one specified asset and receive another at my verified address.”
- If it does not match, stop: do not proceed if another person is directing the operation remotely, promising guaranteed profit, or claiming that wallet “synchronization” requires a seed phrase.
- State 2 — Collect the operational inputs.
- Transition condition: the required exchange direction is currently available.
- Check: verify the exact asset, supported network, destination address, amount rules shown in the application, and whether a Memo or Tag is required.
- Success sign: every input is visible in the application and can be compared with the sending and receiving wallets.
- If it does not match, stop: availability of an asset does not prove that every network, pair, or direction is supported. Do not substitute a similar ticker or a different network.
- State 3 — Verify the route.
- Transition condition: the exchange instructions and your wallet settings describe the same blockchain route.
- Check: compare the full deposit address, network name, token identity where applicable, Memo or Tag, expected service amount, network fee, and destination address.
- Success sign: the wallet’s confirmation screen shows the intended recipient, asset, network, and amount.
- If it does not match, stop: reject any page, message, browser extension, or support request that asks you to reveal or import the seed phrase or private key.
- State 4 — Sign and send.
- Transition condition: all pre-send checks pass and the final wallet summary still matches the task.
- Check: authorize the transaction inside your own wallet. The wallet should sign locally; the secret is not pasted into the exchange page or sent to an operator.
- Success sign: the wallet produces a transaction hash and broadcasts the transaction to the selected network.
- If it does not match, stop: do not sign if the displayed recipient, network, asset, contract interaction, or total debit differs from what you reviewed.
- State 5 — Wait for network and service processing.
- Transition condition: the transaction hash appears in the explorer for the network actually used.
- Check: monitor its status, recipient, transferred amount, and confirmations. Separately monitor the application status through the designated service interface.
- Success sign: the transaction is included in the relevant blockchain and the application recognizes the required payment.
- If it does not match, stop: do not send a second payment merely because an unsolicited message claims that the first one is “locked.” Diagnose the existing transaction first.
- State 6 — Confirm the result or enter recovery diagnosis.
- Transition condition: the expected outgoing transfer is shown at the destination specified in the application.
- Check: compare the received asset, network, address, amount, application status, and available payout transaction identifier.
- Success sign: the destination wallet or account records the expected asset and the operation status corresponds to the on-chain records.
- If it does not match, stop: preserve the application ID, transaction hashes, timestamps, and screenshots that contain no secrets, then use the delayed or erroneous transaction branches below.
Checks that must happen before signing
Asset and network
The asset name alone is insufficient when it can exist on more than one network. A destination address may even have a familiar format while belonging to a route that the receiving service does not support. Chain ambiguity can make funds unreachable through the intended route, so the network selected in the sending wallet must exactly match the network named in the deposit instructions. [2]
Do not infer network support from a previous operation. Available pairs, networks, and directions can change, and their current availability should be checked before each application. If the wallet cannot send the specified asset on the specified network, the route no longer matches the task.
Address and Memo or Tag
Compare the complete destination address rather than relying only on a few characters. Malware can replace clipboard contents, and a copied address may belong to an earlier application. If the deposit instructions display a Memo, Tag, or another destination identifier, copy it into the exact field requested. If no such field is shown, do not invent one.
A missing or incorrect Memo or Tag may prevent automatic attribution even when the transfer reaches a service-controlled address. Support may be able to investigate, but recovery should never be assumed or promised. The proper diagnostic evidence is the transaction hash and application information—not the wallet’s recovery phrase.
Amount, service total, and network fee
Distinguish the amount sent to the deposit address from the network fee charged by the wallet. Review the total wallet debit and the amount expected by the application. Fees depend on the selected blockchain and current network conditions; they must not be guessed from an earlier transaction. Ethereum transactions, for example, require a fee and must be included in a validated block before they are considered successful. [3]
Stop if the wallet shows an unfamiliar token approval, unlimited spending permission, contract call, or recipient that was not part of the planned exchange. Signing data that you cannot connect to the stated operation creates a different authorization from a straightforward transfer.
Final checkpoint
- The exchange direction is currently available.
- The sending asset and network exactly match the deposit instructions.
- The full address has been checked in the wallet’s confirmation screen.
- The required Memo or Tag is present and exact, or the instructions explicitly require none.
- The amount and total debit are understood, including the displayed network fee.
- The receiving address for the outgoing asset belongs to the intended wallet or account.
- No person, form, application, or extension has requested the seed phrase, private key, password, PIN, or two-factor code.
- The final transaction summary describes the same action that you intended to perform.
After these checks, the practical next step is to create an exchange application and verify its current payment instructions. Keep the application page separate from the wallet: the application supplies public transaction details, while the wallet privately signs the transfer.
Red flags that invalidate the route
Phishing pages often imitate wallet or support interfaces and ask the visitor to “validate,” “connect,” “restore,” or “synchronize” a wallet by typing its recovery phrase. Ethereum’s official security guidance specifically warns that phishing pages may request a seed phrase or private information. It also advises checking the domain and avoiding unrecognized links or attachments. [4]
| Request or event | What it indicates | Safe response |
|---|---|---|
| “Send your seed phrase so we can complete the exchange” | An attempt to obtain full wallet control | Close the page or conversation and do not disclose any words |
| “Import your wallet into this support form” | A recovery-phrase phishing pattern | Use only the wallet’s official recovery process on a trusted device |
| Remote-access request | The other party may be trying to observe secrets or approve transactions | Refuse access and secure the device |
| Demand for an additional transfer to unlock funds | The request is not evidence of the first transaction’s status | Check the existing transaction hash and application status first |
| Deposit details change in a private message | The message may be impersonating support or replacing the recipient | Do not send; verify instructions through the designated service interface |
| A “support agent” asks for a private key | The request would give the agent transaction authority | End the conversation and preserve non-secret evidence for reporting |
A real technical investigation can use public addresses, transaction hashes, block data, and application identifiers. A private key is used to authorize spending, not to prove that a previously broadcast transaction exists. Bitcoin and Ethereum documentation both describe signed transactions as the mechanism through which the holder authorizes a transfer. [1]
Delayed or erroneous transaction diagnosis
A delay does not justify exposing wallet secrets or immediately sending again. First determine which state failed. Blockchain status and service processing status are related but distinct: a transfer can be pending on-chain, confirmed but not yet attributed to an application, or successfully received while the next stage requires review.
| Observed state | Diagnostic branch | Evidence to collect | What not to do |
|---|---|---|---|
| No transaction hash | The wallet may not have broadcast the transfer, or signing may not have completed | Wallet activity status, selected account, network, and any local error message | Do not enter the seed phrase into a website to “find” the transaction |
| Hash exists but transaction is pending | Check the correct network explorer and the wallet’s fee-management options, if any | Transaction hash, sender, recipient, amount, nonce where relevant, and pending status | Do not follow fee-replacement instructions from an unsolicited contact |
| Transaction failed on-chain | Review the recorded failure and whether value was transferred; network fees may still have been consumed | Explorer status, transaction receipt, fee data, and wallet message | Do not assume that repeating the identical action will fix the cause |
| Confirmed to the wrong address or network | Identify who controls the destination and whether the receiving system supports that route | Full transaction record, intended instructions, actual network, and destination | Do not expect blockchain reversal or disclose keys to a recovery claimant |
| Confirmed but Memo or Tag is missing or wrong | Ask designated support whether manual attribution is possible | Application ID, transaction hash, sending address, amount, and the intended identifier | Do not promise yourself that recovery is available or send secrets as “proof” |
| Deposit is confirmed but application is paused | Check whether the payment terms matched and whether additional compliance review is required | Application status, transaction hash, and requested non-secret information | Do not attempt to bypass verification or create conflicting applications |
| Payout transaction exists but is not visible in the destination wallet | Verify the payout network, address, token display settings, and explorer status | Payout hash, destination address, asset identifier, and network | Do not import the receiving wallet into an unknown “balance recovery” tool |
Once broadcast, transactions pass through network-specific lifecycle states. On Ethereum, a transaction receives a hash, enters the pending pool, and must be included in a block; later consensus stages provide stronger finality. Bitcoin transactions are also recorded in the blockchain, and confirmed payments are generally not reversible by a central operator. [3]
If the seed phrase or private key has already been shared
Treat the affected wallet as compromised. Deleting a message or changing the wallet application’s password does not change a seed phrase or private key that another party has copied. The priority is to prevent further exposure and move any remaining assets to a newly created wallet whose recovery phrase has never appeared on the compromised device or service.
- Disconnect from the suspicious page, extension, application, or remote-access session.
- Use a clean, trusted device and an official wallet source to create a new wallet with a new recovery phrase.
- Store the new backup offline and do not photograph, upload, email, or message it.
- Transfer remaining assets to addresses generated by the new wallet, checking each asset and network separately.
- Where relevant, review and revoke suspicious token permissions from the compromised address using a trusted interface.
- Stop using the old seed phrase and derived accounts for storage, even if no unauthorized transfer is visible yet.
- Preserve public transaction records and report phishing through the appropriate service, wallet provider, platform, or authority in your country.
These steps cannot guarantee that funds will remain available: an attacker with the same secret may attempt to transfer them first. Never pay a person who claims that the wallet can be secured or recovered only after receiving the seed phrase, another private key, or an advance cryptocurrency payment. Official wallet-security guidance recommends keeping recovery information offline and never sharing it. [5]
What counts as a completed exchange
The route is complete only when the expected asset is visible at the verified destination on the intended network, the relevant transaction records show successful processing, and the application status is consistent with those records. A submitted form, a chat confirmation, or an unverified screenshot is not enough.
Some uncertainty may remain around network confirmation requirements, service processing, compliance review, current fees, and support options for an incorrect network or missing Memo or Tag. Those conditions must be checked for the specific operation. One point is not uncertain: neither a seed phrase nor a private key is required to exchange cryptocurrency. If either is requested, stop before signing or sending anything.
