How to move crypto safely for the first time: a step-by-step runbook
Learn how to move crypto safely for the first time by checking the address, asset, network, fees and destination instructions before testing the transfer.

A first crypto transfer should be treated as a careful handover, not a race to press Send.
If you want to move crypto safely for the first time, make sure the destination address, asset and blockchain network agree before any funds leave your control. Different cryptocurrencies can have different receiving addresses, while fees can vary between blockchains and with network activity. This runbook provides a repeatable process for an ordinary direct transfer between wallets or between a wallet and an exchange account.
The Short Version
- Match the asset, receiving address and blockchain network.
- Follow every instruction displayed by the destination account or wallet.
- Check the amount, available balance and displayed fee.
- Send a small test and wait for it to arrive before sending the balance.
- Save each transaction hash and never share a private key or seed phrase.
What This Means For You
A careful transfer can be divided into three decisions. First, establish the exact asset, network and receiving address from the destination’s own Receive or Deposit screen. Second, compare those details with the sending interface and inspect the amount and fee. Third, prove the route with a small test transfer before putting the larger amount at risk.
This is an operational safety process, not a judgement about whether you should own or trade crypto. It cannot remove changes in an asset’s price or every risk associated with using a wallet or provider. Its purpose is narrower: to reduce avoidable errors when completing an ordinary direct transfer.
Do not begin with a preferred fee or an address saved without context. Begin with the destination’s Receive or Deposit screen for the exact cryptocurrency concerned. Read the entire set of instructions displayed there and enter only information you can verify from that screen. If either interface leaves you uncertain about the asset, network, destination or any required field, stop before authorising anything.
How to move crypto safely for the first time
1. Define the exact journey
Write down the starting wallet or account, the destination, the asset and the intended blockchain network. “Send my crypto” is too vague. Different cryptocurrencies can have different receiving addresses, and the receiver must be able to accept the specific coin on the specific chain.
Open the receiving wallet or account and select the exact asset you intend to transfer. Note the network identified or selected on that screen. Open the sending interface separately and choose the same asset and network. Keep both screens available so that you compare displayed information rather than relying on memory.
The Kraken guide to sending and receiving cryptocurrency recommends checking that the receiver can receive the specific coin on the specific chain. Do not select a network merely because it appears familiar or has a lower displayed fee.
2. Obtain and verify the receiving address
Use the destination wallet or account’s Receive or Deposit function to obtain its public receiving address. Copy and paste the address, or scan the displayed QR code, instead of typing a long sequence manually. These methods can reduce manual-entry errors, but they do not replace checking the resulting details.
Compare the address placed in the sending interface with the address displayed by the destination. Use the most complete view each interface provides. A shortened address can help with recognition, but checking only a few characters is not equivalent to comparing the complete destination. If the interface does not reveal enough information for a confident comparison, do not proceed.
A QR code carries information into the sending interface, but it does not decide whether you selected the right cryptocurrency or blockchain. After scanning, read the resulting asset, address and network fields as carefully as you would after pasting an address. Also check the destination screen for any additional instruction or field and stop if you do not understand how to reproduce it accurately.
3. Match the asset and network
Treat the address, cryptocurrency and network as one set of transfer instructions. The destination should display the address for the asset you intend to send, and the receiver should be able to accept that coin on the chosen chain. Do not assume that choosing the right asset name automatically chooses the right network.
Compare the network names shown at both ends before entering the final amount. If they do not agree, stop. Do not try to resolve a mismatch by guessing from the address format or by selecting whichever option costs less. The appropriate route is the one the sending and receiving interfaces identify consistently for the intended transfer.
This runbook covers an ordinary direct wallet or exchange transfer. It does not establish procedures for bridges, cross-chain swaps, Lightning payments, layer-2 withdrawals or smart-contract deposits. If the route involves something beyond a direct transfer, do not apply this runbook as though the mechanisms were interchangeable.
4. Enter the amount and inspect the fee
Enter the amount only after the destination details are settled. Check that the available balance can cover the transfer and any fee charged in addition to it. Network fees can vary with the blockchain and network activity, so review the fee displayed for this transaction rather than relying on the cost of an earlier transfer.
During busy periods, the displayed fee can be large compared with a small transfer. Look at every figure presented on the quote or review screen, including the amount being sent and the blockchain transaction fee. Check what will leave your balance and what the interface says will be transferred. If any figure is unclear or unacceptable, pause rather than confirming.
Fee presentation can differ between interfaces. The safe habit is to inspect the figures shown for the transaction in front of you. A low fee does not compensate for an asset, address or network mismatch, so complete the compatibility checks before comparing cost.
5. Read the final review screen slowly
Pause at the last screen and compare it with the receiving screen. Check the asset name, destination address, blockchain network, amount and displayed fee. Confirm that the available balance is sufficient and that every destination instruction has been followed. Do not approve the transfer while any field is unclear.
The Kraken transfer checklist advises confirming the wallet address, amount and network and ensuring that enough funds are available for the transaction and network fee. It also warns that confirmed cryptocurrency transactions are irreversible. As a practical rule for a direct blockchain transfer, never rely on being able to recall or correct a confirmed transaction.
Read what the review screen actually says, not what you expect it to say. If you go back and change the asset, network, address, amount or another destination field, repeat the comparison from the beginning. A review completed before a change does not validate the altered transaction.
6. Send a small test transaction
For a new destination, send a small test transaction first. The test should limit the value at risk while remaining a meaningful transfer for the route you are using. Review the address, asset, network, amount, fee and every destination instruction before authorising it.
A test can mean paying a transaction fee twice, but it provides practical evidence about the details entered. Kraken’s guidance says many users send a small test first, particularly when using a new wallet. The Yahoo guide to transacting with crypto describes testing a self-custody wallet address with a small amount, waiting for confirmation and checking that the balance arrives before sending the remainder.
Do not send the larger amount merely because the sending interface reports that the test was submitted. Wait until the intended destination shows the expected asset and amount. If the test has not arrived, do not send several more copies. Keep the transaction details and check the status of the original transfer first.
7. Track the test transaction
After the transfer is broadcast, use its unique transaction ID or hash with a compatible block explorer (a free public website that looks up transactions and balances on that blockchain) to monitor its status and confirmations. Kraken describes the transaction ID as a fingerprint for a specific transaction and explains that it can be entered into a block explorer to check processing and confirmation.
Save the transaction hash with a simple record of the amount, asset, network and destination label. This gives you a precise reference for the transfer and is more useful than relying on memory or a generic notification that does not identify the transaction clearly.
The explorer record and the receiving wallet or account serve different purposes. Use the explorer to follow the transaction identified by the hash. Separately, check the destination itself to confirm that the test amount has appeared where you intended it to go. Do not treat the route as proved until the destination shows the expected result.
8. Send the remainder only after the test succeeds
Once the test appears at the intended destination, repeat the checks for the remaining amount. Confirm that the asset, network, address and every destination instruction remain consistent with the successful test. Then enter the new amount and review the newly displayed fee. Do not assume that every field remained unchanged simply because you used the same interface.
Authorise the larger transfer only when the details remain consistent. Save its transaction hash as a separate record. Keeping both hashes allows you to identify the test and the later transfer independently instead of confusing their amounts or status.
Finish by checking the destination for the expected result. This final check closes the process and gives you a clear point at which to stop investigating the transfer.
Practical worked example
Suppose Priya wants to move a holding from an exchange account to a self-custody wallet for the first time. She opens the wallet’s Receive screen and selects the exact cryptocurrency. She notes the network shown there and reads all the displayed receiving instructions. She then opens the exchange’s withdrawal screen and selects the same asset and network. She does not choose another network simply because its fee is lower.
Priya scans the receiving QR code. She compares the address entered by the exchange with the wallet’s display, using the fullest view available. She checks the asset and network again because scanning the code does not make those choices for her. She also checks that no destination instruction has been overlooked. If a field or instruction is unclear, she stops rather than guessing.
Next, Priya enters a small test amount and reviews the available balance, amount and fee on the final screen. After sending the test, the exchange supplies a transaction hash. Priya saves it and enters it into a compatible block explorer to monitor the transaction. She also watches the destination wallet for the expected asset and amount instead of relying solely on a message from the exchange.
When the test appears in the intended wallet, Priya begins the final transfer as a fresh review. She compares the receiving details again, enters the remaining intended amount and checks the new fee. Only after the fields agree does she authorise the transfer. She saves the second hash separately.
If Priya later chooses a different asset, network or destination, she starts the runbook again. One successful transfer does not prove a different route.
Common mistakes and how to avoid them
Choosing by fee alone
A cheaper network can look attractive, especially when the amount is small. Cost should not decide the route before compatibility has been checked. First match the asset and network at the sending and receiving ends. Then inspect the displayed fee for that route.
Trusting an address without checking the asset
An address is one part of the transfer instructions, not the whole instruction. Generate or display the address from the destination’s screen for the correct cryptocurrency, then compare the asset, address and network before sending.
Ignoring part of the destination instructions
Do not assume the address is the only information shown on a Receive or Deposit screen. Read the whole screen and reproduce every required field accurately. If the destination instructions are incomplete, unavailable or unclear, stop rather than inventing a value or leaving a displayed requirement unresolved.
Relying on a partial address match
Recognising the first and last few characters can help you notice an obvious discrepancy, but it is not a complete verification method. Prefer the fullest comparison supported by the interfaces. If the destination cannot be established confidently, familiarity is not proof.
Skipping the test
A saved address or familiar interface can make a transfer feel routine. A small test remains useful for a new destination because it lets you confirm that the expected asset arrives before the remaining balance is sent.
Confusing submission with arrival
A sending interface may report that a transaction was sent or broadcast. That is not the final check required by this runbook. Use the transaction hash to monitor the specific transaction, then check the intended destination before sending the remainder.
Sharing wallet secrets
A public receiving address can be shared for a transfer. Private keys and recovery or seed phrases must remain secret because they can provide control of a wallet. The Yahoo guide explains that someone with a seed phrase can reproduce a wallet’s keys and control its crypto. A person sending funds needs the public receiving information, not the words used to recover the wallet.
Keep recovery information out of messages and forms used to arrange a transfer. Do not disclose it as part of troubleshooting. It is not required to receive an ordinary crypto transfer.
Assuming a confirmed transfer can be recalled
Banking habits can create an expectation that a mistaken payment can simply be cancelled. Confirmed direct blockchain transactions generally should not be treated as recallable or correctable. Prevention is therefore central: check the destination information, amount and fee, then use a test before sending the balance.
In Plain English
Think of a crypto transfer like sending a parcel through a transport system. The address identifies the destination, the asset is the parcel and the network is the route. Those details must agree, and every instruction provided by the destination must be followed. The test transfer is a low-value parcel sent first so that you can check whether it reaches the intended destination before sending the rest.
The transaction hash is the reference number for the particular journey. It lets you follow that transaction with a compatible block explorer. It does not replace checking the destination, because the purpose of the test is to see the expected asset and amount arrive where you intended.
A final decision check before Send
- Did you open the destination’s Receive or Deposit screen for the exact asset?
- Do the sending and receiving screens identify the same blockchain network?
- Does the destination address match as fully as the interfaces allow?
- Have you followed every instruction and completed every required destination field?
- Have you reviewed the amount, available balance and displayed fee?
- Have you stopped if any field is unclear?
- Has a small test appeared at the intended destination?
- Have you repeated every check before sending the remainder?
- Have you saved each transaction hash without exposing a private key or seed phrase?
If any answer is no or uncertain, do not confirm yet. Return to the relevant screen and check the information shown there. The central rule is simple: prove the route before risking the balance.
These steps cannot make every crypto activity risk-free, but they address avoidable errors in an ordinary direct transfer. A slow and carefully checked first transfer is preferable to relying on recovery after a confirmed mistake.