Wallets and custody: who controls the keys?
The storage decision changes the kind of risk you take; it does not make risk disappear.
Start with authority
A wallet is a tool for interacting with a blockchain and managing the keys or signing arrangements that authorize actions. In self-custody, the user controls the relevant credentials. In custodial arrangements, another organization controls them and credits the customer under its own terms. Both can look similar on a phone screen, which is why the screen alone tells you very little about legal rights or recovery options.
Ask a practical question: if the provider’s website vanished tomorrow, what would let you access the assets? A recovery phrase may allow a compatible self-custodial wallet to restore signing access. A username and password for a custodial platform generally do not give that same independent ability. Conversely, a custodian may offer account recovery that a self-custodial arrangement cannot provide.
Hot, cold, and the signing process
A hot wallet has keys or signing capability accessible through an internet-connected environment. Cold-storage arrangements seek to keep signing secrets offline. A hardware wallet can protect key material, but it cannot make every transaction safe. If a person approves an unintended transfer or a dangerous contract permission, securely signing that instruction still executes the wrong decision.
A recovery phrase is not ordinary troubleshooting information. Someone who obtains it may be able to take control without knowing your platform password. Genuine-looking support conversations, sponsored search results, browser extensions, and fake updates can all be entry points for theft. A screenshot saved to a cloud account can create an additional path to the secret. Security requires thinking about the whole process, not just buying a device.
Custody includes contracts and failure scenarios
For a custodian, examine the legal entity, asset-segregation terms, withdrawal conditions, and treatment if the business fails. Marketing phrases such as institutional grade do not specify a customer’s legal claim. Insurance can have limits, exclusions, and a beneficiary different from the individual customer. Proof-of-reserves information also does not, by itself, provide a complete picture of liabilities or all encumbrances.
For self-custody, examine backup durability, inheritance arrangements, device failure, and the possibility of signing mistakes. More elaborate systems can introduce their own operational errors. A setup that one person understands today may be unusable by a future executor or by that same person after losing a device. The relevant objective is a comprehensible, tested process, not maximum complexity.
Networks, addresses, and records
A token symbol is insufficient to identify a transfer route. Similar names may exist on several networks, and receiving services may support only specific versions. Some destinations require an additional memo or tag. An address that looks valid does not prove it belongs to the intended recipient. Clipboard malware and address-poisoning tricks exploit superficial visual checks.
An educational transfer checklist separates the intended asset, network, destination, extra routing fields, fee, and confirmation requirement. A small test transfer can reveal some mistakes, but it is not a guarantee that a later transaction is safe or that an address has not been changed. Keep transaction identifiers and cost records for reconciliation. Tax and reporting requirements differ by location, and moving assets between accounts should not be confused with calculating taxable gains without local guidance.
An approval is a separate kind of authority
Sending a token and authorizing someone else to spend it are different actions. In the ERC-20 model, an allowance can let a specified spender transfer tokens up to a limit. The approval itself may not reduce the visible balance, which makes an unchanged balance a poor test of whether anything important happened. Read the spender, the asset and the amount—not just the transaction fee. The ERC-20 standard describes approvals and allowances.
Picture a fictional wallet holding 500 units. Its owner intends to exchange 20, but a request asks for permission to spend far more. The immediate transaction might succeed exactly as expected while leaving broader authority in place. In a paper review, separate “what I want to do now” from “what this permission allows later.” A familiar app name is not a substitute for identifying the actual spender, and some signature-based permissions require separate analysis even when no on-chain approval is visible yet.
Disconnecting a website is also not the same operation as removing an on-chain allowance. A connection governs what the interface can request or see; an existing permission may remain effective. Revocation changes permission going forward and cannot reverse a transfer that already happened. This is why a security review needs an inventory of authority, not just an inventory of balances.
Rehearse recovery without exposing the secret
A recovery plan should answer mundane questions before there is an emergency. Where are the instructions? Which network and wallet type are involved? Who is allowed to act if the owner is unavailable? What evidence would distinguish a lost device from a compromised signing secret? Write the process without writing the secret into the same document, and never include real keys or recovery phrases in a shared learning journal.
Run a tabletop exercise with three cards: device failure, cloud-account compromise and loss of a backup location. Explain what remains available in each case and which controls fail together. Two backups in the same bag are vulnerable to one loss; two copies in the same online account are vulnerable to one account takeover. The exercise is not a recommendation for a particular custody setup. It is a way to discover whether your stated recovery plan depends on resources that disappear in the very incident it is meant to handle.