A ledger-wide audit by XRPL validator Vet identified two dormant whale accounts with exposed public keys holding 21 million XRP, described as 0.03% of circulating supply. The same discussion contrasted that figure with a Google-cited estimate that about 6.9 million BTC, nearly 35% of bitcoin’s circulating supply, could be vulnerable under quantum key-recovery scenarios.
Vet, an XRP Ledger validator, ran a ledger-wide “quantum vulnerability” audit this week that framed exposure in a trader-friendly way: how much supply sits behind public keys that have already been revealed on-chain.
The audit’s headline split was stark. Vet identified around 300,000 XRPL accounts holding 2.4 billion XRP that have never sent funds. Because those accounts have only received funds, their public keys have never been exposed to the network and were described as quantum-safe by default.
On the other side of the ledger, Vet flagged two dormant whale accounts that previously transacted, meaning their public keys have been exposed. Those two accounts hold 21 million XRP in total, described as 0.03% of XRP circulating supply. The packet’s comparison then set that against a Google-cited estimate that about 6.9 million BTC, nearly 35% of bitcoin’s circulating supply, could be vulnerable.
The threat model in the packet is specific: a sufficiently powerful quantum computer running Shor’s algorithm could theoretically derive a private key from an exposed public key and drain funds. That makes “vulnerable supply” less about who holds the most coins and more about which coins sit behind keys that have already been shown.
On many chains, receiving funds puts an address on-chain, not the public key. The public key typically becomes visible when an address spends. That’s why Vet’s audit uses send-history as the exposure proxy for XRPL accounts.
Bitcoin’s exposure discussion is framed as larger not only because of user behavior, but because of legacy design choices. Early P2PK outputs exposed public keys directly in transaction outputs without requiring a spend. The packet uses Satoshi Nakamoto’s 1 million BTC that has never moved as the cleanest illustration of why “never moved” does not necessarily mean “never exposed” on Bitcoin.
XRPL’s key rotation is presented as the structural differentiator. The ledger allows an account to rotate the signing key without moving funds, reducing the need to broadcast a spend just to regain “unexposed key” status. Vet summarized it bluntly: “The XRP Ledger is account based and allows for signing key rotation. so you can rotate keys that sign on behalf of an account without switching the account. this is obviously not a perfect solution at all and actual quantum resistant algorithms will eventuell be adopted,” he wrote on X.
The caveat is operational, not theoretical. The packet ties residual XRPL risk to long-dormant accounts where owners may be unable or unwilling to rotate keys due to lost access, death, or inattention.
Ripple staff software engineer Mayukha Vadari also pointed to escrow time-locks as a partial defense for escrowed XRP because the restriction is logic-based rather than cryptographic: “Time locks aren't hash based either, you just can't get in until that time has passed (at least not via quantum - you'd need some other bug for that). Yeah that's true, can't stop a blackholing - but the attacker is less incentivized to do that because they don't get the funds,” he said. The packet also flags the boundary of that protection: if the controlling account is compromised, an attacker could potentially cancel or modify the escrow or wait out the lock.
The biggest gap in the comparison is methodological clarity on the Google-cited estimate that ~6.9 million BTC are vulnerable. Any follow-up publication that defines “vulnerable” output types and assumptions would tighten or weaken the 35% headline.
On XRPL, the real-world test is adoption. Key rotation exists, but the packet’s risk concentrates in exactly the cohort least likely to act quickly: long-dormant, high-balance accounts that have already exposed public keys.
On Bitcoin, the packet notes that developers have initiated several proposals to develop quantum resistance, but it provides no names or timelines. Traders will care whether any proposal directly addresses legacy P2PK exposure rather than only modern wallet types.
Finally, the mempool matters because it sets the theoretical attack window when moving BTC to a new address. If average confirmation times stretch beyond the packet’s ~10-minute baseline, the window expands. If they compress, the window shrinks.
I treat this as a market-structure story disguised as a tech debate. Vet’s audit turns “quantum risk” into a measurable proxy, public-key visibility, and that creates a clean supply-at-risk framing for XRP that the packet contrasts against a much larger BTC estimate.
The threshold that matters is whether mitigation is something holders can do without touching liquidity. XRPL’s signing key rotation is positioned as structural because it can reduce exposure without moving funds, while Bitcoin’s described mitigation is to move coins and accept a mempool window where the old public key is exposed. If that gap persists and the Google-style vulnerable-supply narrative gains traction, it matters in practical terms because it can reprice tail-risk premia and shift relative positioning between assets with different “exposed supply” overhangs.