Exchange, hot and cold wallets: how to store crypto assets

What a wallet actually holds

Crypto assets are recorded on a blockchain. A wallet provides the tools to view an account and authorise actions using its keys. Losing a phone does not delete the blockchain record; losing the only way to authorise spending can make that record inaccessible to you.

In an ordinary self-custody wallet, a private key authorises spending from an account. A public receiving address identifies a destination. The address can be shared to receive a payment; the private key must remain secret. An address is not a recovery method, and a screenshot of a balance is not evidence that you can spend it.

Custody has two separate dimensions: who controls the spending authority, and how that authority is protected. An exchange can keep its keys in cold storage while you still depend on the exchange. A self-custody wallet can be hot or cold. Keeping these dimensions separate prevents the common mistake of treating every cold-storage claim as personal control.

Exchange, hot wallet and cold wallet: compare the responsibilities

On an exchange, your login normally gives you access to a customer account; the operator controls withdrawals from its blockchain wallets. A hot self-custody wallet manages keys on a general-purpose phone or computer. Cold storage aims to keep signing keys isolated from internet-connected software, often with a dedicated hardware signer.

A hardware signer can communicate with an online app through a cable or QR code while keeping its keys isolated. That isolation does not make every requested signature safe. If you restore the same recovery phrase into a software wallet, you expose those keys to the software environment; the original hardware device cannot undo that exposure.

Choose an arrangement you can operate and recover

Begin with your actual use: trading, occasional payments, or holdings you expect to leave untouched. Decide how quickly you need access, which networks you use, who could help if you are unavailable, and whether you can reliably protect and recover keys. There is no universal allocation percentage that answers those questions.

For an exchange, identify the contracting legal entity and read how customer assets are held, whether they can be lent or pledged, and what happens during a withdrawal hold or insolvency. Regulation and insurance have specific scopes; do not assume the protection of a bank deposit. A reserve report alone does not establish every liability or your legal claim.

For self-custody, the device manufacturer supplies a tool and the wallet developer supplies software. They usually cannot replace your lost spending authority. Separate operating funds from longer-term holdings where that fits your needs, but remember that several wallets restored from the same phrase share a recovery secret and are not independent security boundaries.

A useful decision test is to explain, without opening the app: who can move these assets, what would stop a withdrawal, and how would I restore access tomorrow? If an answer is unclear, resolve it before increasing the amount held there.

Address, private key, recovery phrase, PIN and passphrase

These items solve different problems. A login password or device PIN can protect one interface while a person with the wallet's recovery secret restores the same keys elsewhere. Changing the PIN does not change the keys already derived from a compromised recovery phrase.

A watch-only wallet may display balances without holding spending keys. Some wallets use smart accounts, social recovery or distributed key shares instead of an ordinary phrase. Read the actual recovery design; a familiar wallet logo does not tell you which credentials are essential.

Create a backup before you depend on the wallet

Obtain software and hardware through independently verified official channels. Check the manufacturer's authenticity and setup instructions. Initialise the wallet yourself. A device or message supplied with a ready-made phrase or PIN is not a trustworthy starting point, even if it arrives in convincing packaging.

Let the wallet generate the backup using its supported process. Do not invent a memorable sentence or use a phrase supplied by a website. Ordinary BIP39 wallets often use 12 or 24 words, but other lengths and backup standards exist. Record the complete words in the exact order. Never translate the words, rearrange them, or silently correct a word you cannot read.

For a straightforward beginner setup, keep a legible offline backup in a private place protected from theft, fire and water. Paper and purpose-made metal backups have different durability and access trade-offs. A second protected location can reduce a single-site disaster risk; every additional copy also creates another place from which the secret can be stolen.

Avoid photographs, screenshots, email, chat messages and ordinary cloud notes for the phrase. A phone may automatically synchronise an image you intended to keep locally. Advanced encrypted digital backups require a separate, tested key-management plan; encryption with a forgotten password simply creates another recovery failure.

Keep recovery information separate from the device and document which wallet and backup format it belongs to. Do not put the full phrase on a label announcing a valuable crypto holding. Check occasionally that the record is readable and that the authorised recovery person can locate the instructions without exposing the secret to everyone who can open your email.

Test recovery without destroying your working access

Use the wallet's documented backup-check or recovery-test procedure where available. For a hardware wallet, follow the exact model's instructions and trusted device prompts; entry methods vary. Do not wipe your only working device merely to find out whether the backup is correct. Test early, while a recovery mistake would affect only a small amount.

A genuine restoration flow may require the recovery secret on the appropriate trusted device or in an intentionally chosen wallet application. A support chat, unsolicited link, online 'seed checker' or this article has no reason to collect it. Verify the software independently before beginning; a page that looks official can still be a phishing page.

If you use an optional BIP39 passphrase, record and test its exact spelling, spaces and letter case. It is not necessarily a '25th word'. A wrong entry can generate valid keys for another wallet rather than report an error. Losing the required passphrase can make the correct mnemonic insufficient to recover your assets.

Record the backup standard and relevant account setup, not only the brand name. A BIP39 mnemonic and a SLIP39 share set are different formats. Smart-account recovery and multisignature wallets have their own requirements. Compatibility must be verified before relying on a replacement product.

After a recovery check, confirm the expected receiving account, network and transaction history. An empty balance can result from the wrong passphrase, account, network or derivation settings. Separately imported private-key accounts may need separate backups. Do not start entering the secret into more websites while trying to make the balance appear.

Verify the complete address from a trusted source

Open the recipient's current receiving screen for the chosen asset and network. For an exchange, use the authenticated deposit page and its current instructions. For your own hardware wallet, verify the receiving address on the trusted device display when the product supports it. For another person, verify the details through an independently established channel.

Copy the address or scan its QR code, then compare the complete result with the trusted source before authorising the transfer. Clipboard malware can replace a pasted address; a QR code can encode the wrong destination. Checking only the first and last characters is not enough because an attacker can generate a similar-looking address.

Do not select a destination from an unsolicited small transfer, an airdrop or an old transaction-history entry. Address-poisoning attacks deliberately place lookalike addresses in that history. Return to the verified receiving source for both the test transfer and the later transfer, and check the address again each time.

A valid address format or checksum helps catch some typing errors; it does not prove the identity of the recipient. Addresses, memos and transaction hashes are generally public information, but publishing them can reveal financial activity. Share only the information needed with the intended recipient or verified support team.

Match the asset, network and receiving service

Write the transfer route as a complete combination: exact asset, exact blockchain, receiving address, and memo or tag if required. Both the sending service and the recipient must support that combination. Distinguish the live mainnet from a testnet used for development. A low withdrawal fee is irrelevant if the receiving side cannot credit the transfer.

USDC on Ethereum and USDC on Arbitrum are on different networks. A receiving service that lists only Ethereum deposits does not thereby support Arbitrum. Ordinary accounts can share the same 0x-style address across several EVM networks; the matching address text does not make those networks interchangeable. Smart-account behaviour can differ.

Check the token version too. An issuer-native token, a bridged representation and a counterfeit token can use similar names. Confirm the accepted version and, when relevant, the token contract against the issuer's documentation and the receiving service's instructions. The token contract identifies the token; it is not your personal deposit address. Do not assume a bridge is necessary just because two network names appear in a wallet.

Wrong-network transfers are not all recoverable and not all automatically destroyed. A self-custody owner may be able to access an asset on another supported chain if they control the required account; an exchange may support recovery only for specified assets and networks, or not at all. Never choose a route on the assumption that support will repair it afterwards.

Memos, minimums and fees can determine whether a deposit works

Some services use a shared receiving address and a destination tag or memo to identify your customer account. XRP deposits to an exchange are a common example. If the receiving page requires that field, copy it exactly as well as the address. A correct address with a missing or wrong tag may produce an on-chain transfer that is not credited to you.

Check the sending minimum, receiving minimum, supported token version, confirmation requirement, maintenance status and final amount after fees. A test below the recipient's crediting minimum proves little and may not be recoverable. New-account reserves or other chain-specific receiving requirements can also apply; use the current instructions for that network.

Separate an exchange withdrawal charge from a blockchain transaction fee. A service may deduct its charge from the amount or charge it separately. Read the preview's amount debited and amount expected at the destination. Fee rates and network conditions change, so an earlier successful transfer does not lock in the next cost.

For an ordinary Ethereum account, sending USDC normally requires ETH for gas. Receiving USDC does not by itself supply ETH for a later outgoing transaction. Other networks use their own fee arrangements, and some supported smart wallets can sponsor fees. Verify the exact setup instead of assuming the token you hold can always pay its own transaction fee.

Prepare the account and device before opening the withdrawal form

Protect the exchange account and its linked email with strong, unique credentials and suitable multi-factor authentication. Where supported, review passkeys, withdrawal allowlists and address-change delays. An allowlist helps only if you verified the address before adding it. Keep recovery codes protected separately from the logged-in device.

Use an updated, trusted device and verify the app, browser extension and website independently. Avoid recovery instructions from search advertisements, direct messages or a caller claiming an urgent wallet problem. If you suspect malware or a stolen recovery secret, resolve that incident before using the routine transfer procedure below.

A practical transfer procedure, step by step

The sequence below applies to a planned transfer from an exchange or wallet to a verified receiving destination. Stop whenever a required field or receiving condition is uncertain.

1. Define the route

   Identify the asset and token version, sending service, destination, network and purpose. Decide how much you can afford to lose in the test and whether both sides support the route.

2. Open fresh receiving instructions

   Obtain the address from the authenticated recipient or verified wallet. Read the network, tag or memo, minimum deposit and confirmation requirements; save a non-secret record of the route.

3. Check the address independently

   Compare every character after copying or scanning. Verify on the hardware display when applicable, and confirm changed details with the recipient through a trusted channel.

4. Check costs and receiving eligibility

   Read the exact withdrawal preview: amount debited, fee and expected receipt. Keep any required native fee asset available for a wallet transfer, and make the test large enough to satisfy the receiving minimum after fees.

5. Send the test only

   Select the same network and asset version you intend to use later. Recheck the address, required tag and amount at the final confirmation screen; read the hardware signing display rather than approving automatically.

6. Confirm the actual result

   Obtain the transaction hash when broadcast, inspect it on an independently verified explorer for that network, and confirm the recipient has actually credited the correct asset. A successful chain transaction and an exchange deposit credit are separate checks.

7. Investigate any mismatch before continuing

   If the amount, network, token or recipient balance differs from the plan, stop. Compare the sending record, on-chain transaction and receiving rules. Do not make another large transfer to 'unlock' the first one.

8. Verify again before moving the remainder

   Return to the original trusted receiving source. Recheck the route, complete address, tag, current fees and receiving status. The successful test does not protect a second transfer with changed details.

9. Keep records and the next-use fee buffer

   Record date, asset, network, amount debited, fee, amount received, public destination and transaction hash. Verify the final balance and whether you can later send the assets out. Never include the phrase, private key or PIN in this transfer log.

Worked example: a test transfer has a cost

This is fictional arithmetic, not a current exchange quote. Assume an exchange balance of 100 USDC, a 2 USDC fee deducted from each withdrawal, and a destination that supports the selected USDC network and credits the test amount. The withdrawal amount in this example is the total debited, including that fee.

The test debits 10 USDC and delivers 8 USDC; the remaining withdrawal debits 90 USDC and delivers 88 USDC. The destination receives 96 USDC in total and the two fees cost 4 USDC. One hypothetical withdrawal would instead deliver 98 USDC after one fee. The extra test costs 2 USDC under these assumptions.

Those figures do not make 10 USDC a universal test amount. A different minimum, fee or fee-charging method changes the calculation. If the test is not credited, the large transfer does not proceed. If the destination is your ordinary Ethereum wallet, you may also need ETH there for a later USDC transfer; that future fee is outside this ledger.

Protect the wallet when signing, not only when storing keys

Receiving assets at a verified address normally does not require connecting to an unfamiliar application or signing an 'activation' message. Treat demands to verify a deposit through a supplied link, approve a token or pay an unexpected release charge as a reason to stop and verify independently.

A wallet connection, a transaction, a token-spending approval and a message signature grant different powers. A hardware device can keep keys secret while you authorise a harmful transaction. Read the network, recipient or spender, token, amount, allowance and expiry where shown. If important details are unreadable, find an understood alternative rather than enabling blind signing by habit.

An unlimited token approval can leave continuing authority with a contract. Disconnecting an app does not revoke that on-chain approval. Some off-chain signatures can also authorise spending, even when signing shows no immediate gas charge. Review permissions through verified tools; understand what a revocation changes before signing it.

When funds do not appear: diagnose the stage that failed

Use the sending record and the explorer for the actual network. An app's display, a blockchain transaction and a custodian's internal credit can disagree without describing the same failure.

If keys or the recovery phrase were exposed, treat the affected ordinary wallet as compromised. Changing a password, PIN or token approval cannot remove another person's copy of its keys. Use a verified clean environment and a new, independently generated recovery setup for assets that can still be moved; do not continue receiving into the compromised wallet.

If funds disappear immediately, automated theft may be involved. Do not repeatedly send ETH or other fee assets into a suspected compromised address: an attacker can take those too. Follow the wallet provider's verified incident guidance and report the incident through the appropriate official channels. A stranger offering guaranteed recovery creates another exposure.

Keep a recovery plan that survives a device failure or your absence

Maintain a separate, non-secret inventory: wallet type, networks, backup standard, account setup, official recovery documentation and where authorised instructions can be found. Update it when adding a passphrase, imported account, new wallet or different recovery method. Do not put secret material in the same everyday email or shared document.

Plan who could act if you are unavailable and what legal and practical authority they would need. Instructions should help the intended person locate protected recovery material without giving unrestricted access to every reader. Applicable inheritance and ownership rules depend on jurisdiction; cryptographic access and legal entitlement are separate questions.

Multisignature and standardised threshold backups can distribute control, but they introduce more recovery requirements. A multisignature wallet may need its configuration or descriptor as well as enough signing keys. A share-based backup needs the correct format and threshold. Do not invent a word-splitting scheme and assume it is equivalent to a supported secret-sharing system.

Mistakes that look harmless until recovery or withdrawal

Three final questions about control

The record to keep before a significant transfer

Be able to answer: who controls the keys; which verified backup restores each account; where the protected recovery material is; which exact asset and network the recipient accepts; whether a tag and minimum apply; what is debited and received after fees; whether the test is actually credited; and how you will later move the assets out.

Keep the non-secret transfer record and recovery instructions current. Resolve uncertainty before increasing the amount. A storage arrangement becomes useful when you can explain its control, carry out its checks and recover it under the conditions that would otherwise interrupt access.