The site's referral record is not registered; the code, benefits and commercial arrangement in the account-opening guide remain unverified. This page recommends no wallet or device and links to no vendor. Full disclosure.
Hot and cold storage are two different questions
The same two words describe a platform's internal architecture and an individual's storage decision. They are not the same question, and answering one with the other is how people reach confident wrong conclusions.
"We keep most assets in cold storage" is a sentence about a platform's operations. "I keep my holdings in cold storage" is a sentence about one person's habits. They share vocabulary and almost nothing else, and the confusion between them is load-bearing in a lot of bad advice.
Two layers, one vocabulary
Hot means keys are on a system connected to a network and can sign transactions on demand. Cold means keys are held on something not connected, and signing requires a deliberate physical step. That definition is the same at both layers, which is exactly why the confusion is so easy.
At the platform layer, the split is an operational design decision about a pool of assets belonging to many people. It is made by a team, enforced by procedure, and its purpose is to limit how much can be lost in a single compromise while still allowing withdrawals to process without human intervention.
At the individual layer, it is a decision about your own keys, made by you, enforced by nothing but your own habits, and its purpose is to decide who bears the risk.
A platform saying it holds most assets in cold storage tells you something about its stated operational discipline. It tells you nothing whatsoever about whether your balance is safer there than in a wallet you control, because those are not the same comparison.
What the platform-side split does and does not tell you
The claim you will see is a percentage in cold storage. Three things are worth understanding about it before you weight it.
It is about breach containment, not ownership. The split limits the damage from a compromise of the platform's live systems. It does nothing about the platform's solvency, its other liabilities, or whether it may use those assets in ways you did not anticipate. An entirely solvent-looking cold storage arrangement sits comfortably alongside an insolvent balance sheet, because they are measuring different things.
The percentage is rarely defined. Percentage of what, measured when, valued how? A figure computed at a quiet moment and a figure computed during heavy withdrawal activity are different numbers, and the claim almost never says which one you are reading.
The interesting part is the procedure, not the ratio. What matters operationally is how assets move from cold to hot: whether it requires multiple people, whether any single person can authorise it, whether the process is documented and reviewed. Platforms that describe this in any detail are unusual, and the detail is far more informative than the headline percentage.
None of this makes the claim worthless. It is a real statement about how a platform runs. It simply belongs in the same bucket as proof of reserves: a narrow piece of evidence that people routinely ask to carry a much broader conclusion.
The individual layer, where the decision actually is
Your own version of this question is not "hot or cold". It is closer to "how much friction do I want between me and my own assets, and what am I prepared to maintain".
A hot wallet you control is fast and forgiving of mistakes in one direction: you can always reach your funds. It is unforgiving in another: anything that compromises the device it lives on can reach them too.
A cold setup reverses both. Extracting funds requires a deliberate physical act, which is precisely the property that protects them — and precisely the property that makes an emergency inconvenient. The friction is the feature, and you do not get to keep the feature while removing the friction.
The honest framing is that this is not a security question with a right answer. It is a question about the shape of your own use.
Why most people end up with all three
The framing that survives contact with reality is not choosing one, it is deciding what proportion goes where. Most people who have been doing this for a while converge on something like three tiers, arrived at by experience rather than by planning.
- A small working balance wherever it is most convenient, including on a platform, sized so that losing all of it would be annoying rather than serious. Optimising the security of this tier is mostly wasted effort; optimising its size is not.
- A medium tier in a self-custody hot wallet, reachable in a few minutes, for anything with a foreseeable use.
- A long-term tier in cold storage, deliberately awkward to reach, for anything you do not intend to touch.
The proportions are personal. What is not personal is the observation underneath: the tier that causes trouble is almost always the one that grew without anyone deciding it should. A working balance that was meant to be small and has quietly become most of a portfolio, because moving it kept being a task for next week.
That drift is the single most common failure of custody planning, and it is not a technical failure. It is worth a calendar reminder more than it is worth another device.
What cold storage does not protect against
Coverage of this subject is heavily skewed, because exchange failures are newsworthy and private losses are private. It leaves people with the impression that cold storage is the answer and the remaining risks are small. They are not small; they are simply undocumented.
Cold storage removes counterparty risk and network exposure. It leaves you holding, in full:
- Backup failure. A recovery phrase discarded during a move, kept in a photo library that was later cleared, or split across two locations where one half was lost. No support process exists. The failure is quiet, total and permanent.
- Address error. Sending to the wrong address or over an unsupported chain is irreversible. Cold storage does not make this less likely; the extra confirmation step in the signing process is the only mitigation, and only if you actually read what you are confirming.
- Inheritance and incapacity. A setup that only you can operate becomes a setup nobody can operate. If anyone else may ever need access, that has to be designed in, and it is genuinely hard to do without weakening the arrangement.
- Signing something you did not understand. A hardware device protects the key, not the decision. Approving a transaction whose consequences you misread is executed faithfully.
The full comparison of both sets of failure modes, laid out without the usual thumb on the scale, is the subject of a longer page. If you want the short version aimed at your own circumstances, five questions produce a model and its cost.
Using the platform-side claim properly
Given all of the above, what should you actually do with a cold-storage claim on an exchange's website?
Treat it as one line in a pre-funding check, weighted below the things that tell you more. It is a statement about operational discipline, unverifiable from outside, and correlated with but not equivalent to the platform being a reasonable place to leave assets.
The things that tell you more are cheaper to check: whether a withdrawal actually completes, what the terms say about your assets in insolvency, and which entity you are contracting with. Our checklist orders them by information gained per unit of effort, and the storage claim does not appear on it — not because it is meaningless, but because nothing you can do from outside will confirm or refute it.
The one decision that is fully within your control is how much is sitting there in the first place. That number is not a security setting, and it is the one that determines what any of this is worth.
Run the recovery drill, not the slogan
A storage decision becomes real only when you rehearse the failure path. For a platform balance, confirm that you can sign in from a trusted spare device, reach the withdrawal screen, identify the approved destination and find the official support entrance without using a search result. Do not actually weaken a whitelist or security control for the exercise.
For a self-custody wallet, verify that the backup is readable, that the recovery instructions name the correct wallet type and network, and that a person who may need access understands where the instructions begin without being handed the secret itself. A small test wallet is safer for practising restoration than the wallet holding the real balance.
The drill often changes the allocation. If an arrangement cannot be recovered under calm conditions, moving more assets into it has not reduced risk; it has exchanged a visible counterparty risk for an untested operational one. That is the useful comparison between hot, cold and platform custody.
Write down what the drill exposed: a missing cable, an unreadable backup, a device update, an unclear network name or a recovery step that only one person understands. Fix one dependency at a time and repeat with the small test setup. Do not test by importing the real recovery phrase into an internet-connected device, and do not photograph it to make the exercise convenient. The point is to validate the process without creating a new copy of the secret.
Repeat after a move, device replacement or major change in who may need access. A custody plan is a maintained procedure, not a product purchase completed on the day a wallet arrived.