> For the complete documentation index, see [llms.txt](https://solana-unchained.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://solana-unchained.gitbook.io/whitepaper/technical-specifications/crypto-agility-and-post-quantum-readiness.md).

# Crypto-Agility & Post-Quantum Readiness

1\. **Current Cryptographic Baseline**

Solana wallets currently use:

* Ed25519 elliptic curve signatures for transaction signing
* SHA-256 / Keccak for address derivation and hashing
* BPF bytecode for on-chain programs

Ed25519 is not quantum-resistant. A sufficiently powerful quantum computer running Shor's algorithm could derive a private key from a known public key exposed on-chain.

2\. **Risk Tiers by Wallet State**

| Wallet State                     | Quantum Risk Level | Reason                              |
| -------------------------------- | ------------------ | ----------------------------------- |
| Created, never transacted        | Low                | Public key not yet exposed on-chain |
| Transacted at least once         | Medium-High        | Public key permanently on-chain     |
| Large balance, high-value wallet | Critical           | High incentive target               |

3\. **Unchained Wallet's Mitigation Architecture**

*Layer 1 — Social Recovery as Migration Escape Hatch*

* Pre-configured guardians can co-sign a recovery transaction to migrate assets to a new quantum-resistant keypair
* Does not require the original private key — effective even if the old key is already compromised

*Layer 2 — On-Chain Inheritance as Contingency*

* A post-quantum beneficiary address can be registered in advance
* Time-lock mechanism releases assets to the designated address if the original wallet is compromised

*Layer 3 — Planned Post-Quantum Key Support*

* Key management modules are abstracted from the signing layer
* When Solana introduces post-quantum schemes (e.g., CRYSTALS-Dilithium, SPHINCS+, XMSS), the wallet integrates them as drop-in signing modules

*Layer 4 — Proactive User Guidance*

* App notifications before any upgrade window
* One-tap "Migrate to Quantum-Safe Key" flow
* Guardian co-signatures authorize migration on-chain

4\. **Migration Flow for Pre-Upgrade Wallets**

Pre-quantum wallet (Ed25519)

        ↓

Guardian co-signs migration transaction

        ↓

New wallet generated with post-quantum keypair

        ↓

Assets transferred atomically in single transaction

        ↓

Old address marked deprecated on-chain

5\. **Residual Risks**

| Risk                                   | Status                                                                                |
| -------------------------------------- | ------------------------------------------------------------------------------------- |
| User never sets up social recovery     | Unmitigated — dependent on Solana's base layer upgrade path                           |
| Quantum computing timeline uncertainty | Estimates range 10–30 years for cryptographically relevant machines                   |
| Solana core protocol dependency        | Unchained cannot implement post-quantum signatures until Solana runtime supports them |
| Guardian collusion                     | Mitigated by M-of-N threshold requirement                                             |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://solana-unchained.gitbook.io/whitepaper/technical-specifications/crypto-agility-and-post-quantum-readiness.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.