Quantum Protection
Quantum computers pose a future threat to the cryptographic algorithms that secure all blockchains today. Drop's infrastructure is designed with upgradeability in mind, positioning the platform to adopt post-quantum cryptography as standards mature and blockchain ecosystems transition.
The Threat: Harvest Now, Decrypt Later (HNDL)
One of the most pressing quantum risks isn't a future attack — it's happening today. In a Harvest Now, Decrypt Later (HNDL) scenario, adversaries collect public keys and other cryptographic material from network traffic and on-chain data now, with the intention of using quantum computers to derive private keys from them later.
For crypto wallets, the core risk is public key exposure. A sufficiently powerful quantum computer running Shor's algorithm could derive a private key from its corresponding public key. Any public key visible on-chain today is a potential target in the future.
How Drop Mitigates Risk
Reduced Public Key Exposure
In traditional wallets, public keys are routinely exposed on-chain — recoverable from transaction signatures on EVM chains, and unavoidably visible on Solana, where an account address is the ed25519 public key. This gives adversaries ample opportunity to harvest them.
Drop reduces this surface where the chain allows it. On EVM and Bitcoin networks, addresses are one-way hashes of public keys — not reversible, even by a quantum computer — so using the address as the primary identifier keeps the underlying public key off-chain until the first outbound transaction. On Solana the address itself is the public key, so exposure is inherent to the protocol and can only be solved at the blockchain layer; Drop's other mitigations (split keys, upgradeable signing) still apply fully. The less a public key appears in network traffic and on-chain data, the smaller the HNDL window.
Distributed Key Architecture
Drop uses a split-key model where no single party holds the complete private key:
| Property | Benefit |
|---|---|
| Key shares split across locations | No single capture point for the full key |
| Passkey-protected client share | Biometric-bound, stored on the user's device |
| Server share in a secured environment | Isolated from other systems |
| Shares combined only when signing | Key material is short-lived in memory and zeroed after use |
An attacker would need to independently compromise both the user's device and the server infrastructure — capturing one share alone, even with unlimited compute power, is not enough to reconstruct the key.
Upgrade-Ready Design
Drop's infrastructure is built with cryptographic agility in mind:
- Multi-curve support — the platform already operates across multiple cryptographic schemes (secp256k1 for EVM chains, ed25519 for Solana), demonstrating the ability to work with different signing algorithms
- Abstracted signing layer — the signing architecture is not rigidly coupled to a single algorithm, making future algorithm changes feasible
- Blockchain ecosystem alignment — as NIST-standardized post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) gain adoption across blockchain networks, Drop's architecture is positioned to integrate them
- Seamless user experience — the goal is for cryptographic upgrades to happen transparently, without requiring users to migrate wallets or take manual action
What This Means for You
| Concern | Drop's Approach |
|---|---|
| HNDL public key harvesting | Hashed addresses on EVM and Bitcoin keep public keys off-chain until first spend; Solana exposure is inherent to the protocol |
| Future quantum attacks on keys | Split-key model — an attacker needs both your device and the server, not just one |
| Algorithm obsolescence | Already supports multiple curves; new algorithms can be swapped in |
| User disruption during transition | Cryptographic upgrades happen under the hood, no wallet migration needed |
Current vs. Quantum-Ready Comparison
| Traditional Wallet | Drop | |
|---|---|---|
| Public key exposure | Recoverable from every on-chain transaction | Hashed addresses on EVM/Bitcoin hide the key until first spend; Solana exposure inherent to the chain |
| Key storage | Single location | Distributed shares |
| Key lifespan in memory | Persistent | Short-lived, zeroed after signing |
| Algorithm flexibility | Typically single-curve | Multi-curve, abstractable |
| Post-quantum upgrade | Likely requires wallet migration | Designed for transparent transition |