> For the complete documentation index, see [llms.txt](https://esper.gitbook.io/esperchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs/quantum-vaults.md).

# Quantum Vaults

Esper is a post-quantum security layer designed to **elevate existing blockchains into a quantum-resilient era**. Our mandate is simple: when large-scale fault-tolerant quantum computers (“Q-Day”) arrive, Bitcoin, Ethereum, Solana — and any chain that opts-in — should continue operating without disruption or loss of value.

To achieve this, Esper introduces **Quantum Vaults (QVs)**: one-to-one, cryptographically mirrored ledgers that preserve every economic and smart-contract state of the source chain while replacing its vulnerable primitives with post-quantum counterparts.

***

### What is a Quantum Vault?

A **Quantum Vault** is a shadow ledger that satisfies four key requirements:

| Requirement                 | Description                                                                                                                                                                                                                  |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **1:1 State Parity**        | Every block header, account/UTXO balance, contract bytecode, and event log from the origin chain is deterministically reproduced in the QV.                                                                                  |
| **Post-Quantum Primitives** | Classical signatures (ECDSA, Ed25519, secp256k1) are substituted with NIST-selected PQC algorithms (Kyber for key exchange; Dilithium or Falcon for signatures; SPHINCS+ as a stateless fallback).                           |
| **Verifiable Bridge**       | A canonical, non-custodial bridge locks assets on the origin chain and mints equivalent tokens inside the QV (and vice-versa). The bridge relies on succinct proofs (e.g., zk-SNARK or zk-STARK) to avoid trusted multisigs. |
| **Seamless Opt-In**         | Users migrate by signing exactly **one** transaction on the vulnerable chain, authorizing the bridge to lock their funds and publish a PQC public key. After that, all activity happens inside the vault.                    |

> **Threat Model Note**\
> A QV assumes an attacker wielding Shor-capable hardware can break ECDSA/Ed25519 but *cannot* yet defeat lattice-based or hash-based schemes at the chosen parameters.

Implementation sketch:

1. **Snapshot** – At T0T\_0T0​ the bridge contract commits the latest origin state root.
2. **Genesis Construction** – The snapshot becomes `Block 0` of the QV.
3. **Continuous Bridging** – Each new origin block triggers a light-client proof that appends the change-set to the QV.
4. **Consensus** – The QV runs its own validator set; PoS chains mirror staking weights, PoW chains adopt a PQC-PoW (see Bitcoin section).
5. **Rollback Guarantees** – Because state parity is strictly append-only, a re-org on the origin chain automatically invalidates downstream QV blocks until consensus is re-established.

***

### Bitcoin Quantum Vault

**Goal:** Preserve Bitcoin’s UTXO model and monetary policy while protecting signatures and mining from quantum attacks.

1. **Signature Upgrade**
   * Spend conditions change from `OP_CHECKSIG` (ECDSA) to `OP_CHECKSIG_PQ` which verifies Dilithium-III signatures embedded in witness data.
   * Legacy coins move via a one-time **locking script**:

     ```txt
     txtCopyEditOP_SHA256 <pk_hash> OP_EQUALVERIFY OP_CVAULT
     ```

     where `OP_CVAULT` burns the coin on Layer 1 and exposes the PQC pubkey hash inside the QV.
2. **Quantum-Resistant Proof-of-Work**
   * Replace SHA-256 double-hash with **RandomX-Q** (memory-hard, lattice mixing).
   * Difficulty retargeting and block interval (10 min) remain unchanged.
3. **Bridging Mechanics**
   * Layer-1 lock tx → Merkle proof → QV SPV contract → mint `vBTC`.
   * vBTC maps 1:1 to satoshis; burn in QV to unlock on mainchain (until Q-Day; after Q-Day mainchain unlocks are disabled).

***

### Ethereum Quantum Vault

**Goal:** Support the full EVM state, contracts, and DeFi ecosystem with quantum-safe accounts and validator keys.

1. **State Import**
   * At fork-height HHH, capture the Ethereum state trie root and deploy it as `GenesisBlock.stateRoot` in the QV.
   * Storage slots and contract code are byte-for-byte identical; only account `nonce` is incremented by 1 to mark the migration.
2. **Signature Upgrade**
   * Externally Owned Accounts (EOAs) swap `secp256k1` for **Falcon-512**. A new EIP (EIP-PQ-Accounts) introduces `tx.type = 0x2A` with Falcon sigs and enlarged `r,s` fields.
   * Validator BLS keys migrate to **Dilithium-II aggregates** for PoS consensus messages.
3. **Bridge Contract**
   * An on-chain zk-SNARK verifier ingests Ethereum block headers and transaction proofs.
   * Locked ETH becomes `qETH` (ERC-20 inside the vault). Gas is paid in qETH at parity with origin gas costs.
4. **Smart-Contract Compatibility**
   * Because the vault preserves the exact opcode set, existing Solidity/Vyper contracts need **zero** changes.
   * Libraries dealing with `ecrecover` must switch to a shim that wraps Falcon verification.

***

### Solana Quantum Vault

**Goal:** Mirror Solana’s high-throughput, Turbine/Gulf Stream pipeline while swapping Ed25519 and SHA-256 hashing.

1. **Ledger Snapshot**
   * A trusted execution of `solana-ledger-tool` exports the snapshot at slot `S_0`.
   * The QV genesis embeds the bank state and vote accounts.
2. **Signature & Hash Upgrade**
   * Transaction signatures: **Dilithium-III** (64-byte sigs → 2424 bytes; batched aggregation compresses them on-chain).
   * Replace `SHA256.hash` in runtime with `KangarooTwelve` (quantum-resistant hash based on Keccak).
3. **Validator Set Migration**
   * Current validator vote accounts publish Dilithium keys and re-stake via an inflight governance proposal.
   * Consensus continues with Proof-of-History, but the PoH sequence uses PQ-VRF outputs (BLS-like but lattice-based).
4. **Bridge**
   * A Wormhole-style light client on Layer 1 listens for SPL-token lock events; the Guardian set is replaced by **zk-proof attestors** that verify Dilithium sig chains, removing trust in multisig guardians.

***

#### Roadmap & Governance

| Milestone                                     | Description                                                                          |
| --------------------------------------------- | ------------------------------------------------------------------------------------ |
| **M-1: Reference Implementation**             | Open-source prototype QV for Bitcoin testnet; includes RandomX-Q PoW and SPV bridge. |
| **M-2: Auditor Program**                      | Third-party audits of PQC primitives and bridge circuits.                            |
| **M-3: Ethereum & Solana Alphas**             | Live devnets synced with mainnets, enabling qETH/qSOL faucets.                       |
| **M-4: Governance Vote for Mainnet Cut-Over** | Community decides sunset rules for legacy (non-PQC) withdrawals post Q-Day.          |

***

#### Security Considerations

* **Hybrid Signatures**: Until NIST finalizes all parameter sets, we support optional *dual* signing (ECDSA + Dilithium) to ensure backward compatibility while gaining PQC benefits.
* **Parameter Agility**: All signature checks reference an on-chain registry of algorithm IDs and parameters to allow seamless upgrades if cryptanalysis advances.
* **Social Recovery**: Multisig wallets migrate to *threshold Falcon* to preserve m-of-n semantics.
* **Bridge Liveness**: Because vaults depend on origin chain data, catastrophic origin downtime freezes QV state. Mitigation: periodic *state-checkpoint Merkle proofs* stored on IPFS/Arweave so QV can continue independently.

***

#### Conclusion

Quantum Vaults give existing chains a low-friction escape hatch: **one signature, one bridge transaction, lifelong quantum safety**. Esper’s role is not to replace Bitcoin, Ethereum, or Solana, but to ensure their economic history and network effects survive the upcoming cryptographic horizon shift.


---

# 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:

```
GET https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs/quantum-vaults.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.