Your Bitcoin exchange can have an impressive security team, an expensive custody system, and a website covered in reassuring promises.
It can also hold your coins behind public keys visible on the blockchain for years.
Both things can be true.
That is the uncomfortable conversation opened by the latest data from Glassnode co-founder Rafael Schultze-Kraft. In his ** October 8 update**, he estimates that
These are exposure figures. They are not a report of stolen coins.
There is no publicly demonstrated quantum computer capable of breaking Bitcoin’s standard wallet cryptography at the scale required for this attack. Coinbase’s ** September account of a post-quantum Bitcoin workshop** likewise described the threat as a long-term preparation problem rather than an immediate crisis.
But a threat does not have to be operational today for today’s decisions to matter.
If you entrust your savings to a company, you are trusting its ability to anticipate changes, understand its dependencies, and act before a difficult migration becomes an emergency.
That is where this story gets interesting.
When you outsource custody, you also outsource the timetable for protecting your money.
Starship could unlock industries that barely exist today. The $12 quadrillion question is how much of its value SpaceX can keep.
The cryptography is easier to understand than the headlines suggest.
A private key authorizes spending. The corresponding public key lets the network verify a signature. Knowing the public key does not currently give an observer a practical way to recover the private key.
A sufficiently capable quantum computer running Shor’s algorithm could change that relationship. The concern is the mathematics securing signatures, as explained in ** Glassnode’s original methodology**.
That is what “exposed” means here.
It does not mean somebody published their seed phrase. It does not mean their exchange leaked its signing keys. And it does not establish a date when those coins could be stolen.
The distinction matters because an alarming number becomes useless if we attach the wrong meaning to it.
The latest breakdown attributes roughly 4.33 million BTC to address reuse and 1.94 million BTC to structural exposure, where the output format reveals a public key by design. The category estimates are rounded.
That makes wallet behavior central to the discussion.
The update also puts the exposed share of tracked exchange balances at 57%, compared with 55% in May 2026 and 39% in early 2021. This is a changing snapshot of labeled holdings, but the direction deserves scrutiny.
You can argue indefinitely about the arrival date of a powerful quantum computer. An exchange can still examine its address practices this afternoon.
The exchange comparisons make the issue concrete. These are selected figures from Glassnode’s October update:
Read the column heading carefully: the percentages concern the balances attributed to those entities in the dataset.
They are not probabilities of a hack. They are not solvency scores. They do not measure every protection an institution has, and they cannot establish that every address has been identified correctly. Glassnode explicitly limits its ** analysis to public-key exposure**.
A low number cannot certify an entire custody business. A high number cannot tell you when an attack will become possible.
My takeaway is that customers deserve an explanation of these differences. A security claim becomes more useful when a provider specifies the threat it addresses and the assumptions it depends on.
“Your funds are secure” is a conclusion. I want to understand the work behind it.
A custodian can demonstrate that it controls coins today while leaving unanswered how it would protect those coins if the underlying cryptography changed.
That is the distinction I want customers to keep in mind when they see a proof-of-reserves badge.
** Kraken’s own explanation** makes an important limitation explicit: its process demonstrates control over funds at the review date, but cannot establish exclusive possession of the private keys. It also acknowledges other limits, including hidden encumbrances and changes after the snapshot.
That transparency is useful. Customers should read it.
My conclusion is that reserve verification and migration preparedness deserve separate evidence. A provider could make progress on one while neglecting the other. Combining them into one reassuring word, “security,” makes that difference harder to see.
Think about what you would want to know if the funds belonged to your family business.
You would want evidence that the assets backing the account exist. You would also want confidence that the people responsible can preserve access when a critical dependency changes.
Those questions remain distinct even when the same company answers both.
I would welcome a regular preparedness statement alongside reserve reporting: what has been inventoried, what has been tested, which dependencies remain unresolved, and who is accountable for the next milestone.
That statement would still need scrutiny. It would not become a guarantee because somebody put a logo on it.
But it would give customers something concrete to compare.
A snapshot can help establish what a custodian controls. A rehearsal can help establish what it is ready to do.
Consider a simple wallet example.
You receive two separate payments at the same address, using a format that initially hides the public key behind a hash. Later, you spend one of those outputs. That spend reveals the key. The other output remains controlled by the same key, which is now public.
A future payment to that address inherits the exposure.
Your private key has stayed secret throughout. No conventional breach has occurred. Yet the information available to a hypothetical quantum attacker has changed.
