A Post-QuantumVault Protocolfor Any Chain.

Abstract

A sufficiently large fault-tolerant quantum computer would break the elliptic-curve and RSA signatures that secure virtually every on-chain asset today. The cost of breaking a single Bitcoin wallet, given a Cryptographically Relevant Quantum Computer (CRQC), is projected to be on the order of a few thousand dollars — and the cryptographic community estimates a non-trivial probability of such a device arriving within the decade.

Zivilia is a forward-compatible, opt-in custody layer. It does not attempt to migrate existing chains; instead, it wraps pre-quantum assets in a lattice-encrypted envelope, signs the resulting ciphertext with NIST-standardized post-quantum schemes, and re-anchors state on chains of the user's choosing. The protocol is chain-agnostic, client-side, and reproducible.

This document describes the threat model, the cryptographic primitives used, the four-phase protocol flow, the multi-chain wrapping mechanism, the security analysis, and the deployment roadmap.

1. Introduction

Public-key cryptography is the bedrock of every blockchain custody model. Bitcoin uses secp256k1 ECDSA; Ethereum uses the same curve with EIP-155 replay protection; Solana uses ed25519; most L2s inherit the parent chain's signature scheme. These schemes share a property that has been mathematically convenient for forty years and is about to become catastrophic: they are all vulnerable to Shor's algorithm running on a sufficiently large quantum computer.

The window of concern is asymmetric. A CRQC is not a single event; it is a transitional period during which a nation-state or well-funded adversary can break signatures retroactively, siphoning any address whose public key has been exposed. For Bitcoin, that includes every P2PK output and every reused address. For Ethereum, it includes every externally-owned account (EOA) and every multi-sig whose participants have ever signed a transaction.

We do not claim to know when a CRQC will arrive. We claim, with high confidence, that the time required to migrate an entire chain's worth of assets to post-quantum primitives is longer than the time between the first public demonstration of CRQC capability and its first profitable exploit. Pre-emptive work is the only safe posture.

"The harvest now, decrypt later" attack is already underway. Adversaries are recording today's encrypted traffic with the intent of decrypting it post-quantum. The same logic applies to signed blockchain transactions.

1.1. Why a Vault, not a Chain Migration

Zivilia does not propose a new base layer, a new consensus algorithm, or a hard fork of any existing chain. Those efforts are valuable but slow, political, and chain-specific. A vault layer is faster to ship, easier to audit, and trivially multi-chain. It also avoids the chicken-and-egg problem: users do not need to migrate their assets to use Zivilia, they only need to wrap them.

2. The Quantum Threat

2.1. Shor's Algorithm and Elliptic Curves

Shor's algorithm reduces the integer factorization and discrete logarithm problems — the security basis of RSA, DSA, ECDSA, and Schnorr — to polynomial time on a fault-tolerant quantum computer. Estimates of the resources required to break a 256-bit elliptic curve key in one hour range from 2,000 to 10,000 logical qubits, depending on error correction overhead.

2.2. Grover's Algorithm and Symmetric Crypto

Grover's algorithm provides only a quadratic speedup on unstructured search, so doubling the symmetric key length is sufficient to maintain security. Zivilia uses AES-256 for symmetric encryption and SHA3-512 for hashing.

2.3. What is Actually at Risk

We classify the post-quantum threat surface as follows:

• Direct exposure. Addresses whose public keys have been published (every P2PK Bitcoin output, every EOA that has sent a transaction, etc.) are vulnerable to retroactive private-key recovery.
• Indirect exposure. Multi-sig wallets, time- locked contracts, and DAO treasuries that depend on any pre-quantum signature are vulnerable to either-key recovery.
• Network-layer exposure. TLS, DNSSEC, and BGP-SEC signatures using pre-quantum algorithms will be broken; nodes that depend on them for transport security must migrate in parallel.
• Reorg exposure. A CRQC operator can mine faster than the rest of the network for the duration of a single block, enabling long-range reorgs. Zivilia does not solve this; the underlying chains must.

2.4. Non-Goals

Zivilia is not a consensus protocol, a privacy protocol, a scaling solution, or a chain abstraction layer. We explicitly do not attempt to: prevent chain reorgs; hide transaction amounts or counterparties; reduce gas costs; or substitute for the user's own operational security.

3. Cryptographic Foundation

Zivilia uses a small, audited set of cryptographic primitives. Every primitive is either a NIST Federal Information Processing Standard (FIPS) or a widely-deployed hash. We do not invent new cryptography; we compose known primitives carefully.

3.1. Signature Schemes

• ML-DSA-65 (Module-Lattice Digital Signature Algorithm, FIPS 204). Primary signature scheme. Lattice-based; security relies on the hardness of the Module Learning-with-Errors (MLWE) problem. Public key 1,952 bytes, signature 3,293 bytes, NIST security level 3 (~AES-192).
• SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205). Fallback for environments where lattice cryptography is not yet trusted (e.g., air-gapped systems). Hash-based; security relies on the second-preimage resistance of SHA-512.
• Falcon-512 (FN-DSA, FIPS 206 draft). Compact alternative to ML-DSA. Uses NTRU lattices; public key 897 bytes, signature 666 bytes. Best for on-chain storage where every byte costs gas.

3.2. Symmetric Primitives

• AES-256-GCM for symmetric encryption of vault payloads. Authenticated encryption with associated data (AEAD); 96-bit nonce, 128-bit tag.
• SHA3-512 for all internal hashing: address derivation, Merkle tree construction, and commitment generation.
• HKDF-SHA3-512 for key derivation from master seeds, with per-purpose subkeys and domain separation tags.

3.3. Zero-Knowledge Proofs

Zivilia uses Groth16 zk-SNARKs over BN254 curves for the proof of possession scheme that lets a user prove they control a vault share without revealing the share itself. The proving system is not post-quantum, but the statement being proven is a hash preimage, which is a hash-based scheme and is post-quantum-secure.

3.4. Cryptographic Stack Diagram

┌─────────────────────────────────────────────────────────────┐
│                    Application Layer                        │
│              (Vault creation, signing, recovery)           │
├─────────────────────────────────────────────────────────────┤
│  Sign        │  Encrypt     │  Store       │  Verify        │
│  ML-DSA-65   │  AES-256-GCM │  erasure     │  Groth16 zk    │
│  SLH-DSA     │  HKDF        │  coding +    │  + MLWE KEM    │
│  Falcon-512  │              │  5× replicas │                │
├─────────────────────────────────────────────────────────────┤
│                  Hash layer: SHA3-512                       │
│                  Curve: BN254 (zk only)                     │
├─────────────────────────────────────────────────────────────┤
│              Network: TLS 1.3 (PQ-hybrid 2026)              │
└─────────────────────────────────────────────────────────────┘

4. Protocol Architecture

The Zivilia protocol has four logical phases, executed in order. Each phase is a pure function of its inputs; the entire flow is reproducible from a single seed phrase.

4.1. Sign

The user generates a fresh ML-DSA-65 keypair on the client device. The private key never leaves the device. The seed phrase is generated from 256 bits of CSPRNG output, then expanded to a master key via HKDF-SHA3-512. The master key optionally derives Shamir-shared subkeys for multi-party custody.

Key generation completes in <50ms on a modern smartphone. The public key is the user's Zivilia address; it is 1,952 bytes and is safe to publish.

4.2. Encrypt

The user wraps their pre-quantum wallet (a Bitcoin seed, an Ethereum private key, a Solana keypair, or arbitrary bytes) with the Zivilia public key. We use a hybrid construction: MLWE-based KEM for key exchange, AES-256-GCM for payload encryption. The resulting ciphertext is ~1.5× the size of the original payload.

4.3. Store

The ciphertext is uploaded to Zivilia's storage layer — a decentralized, erasure-coded blob store replicated across 5 chains (Bitcoin, Ethereum, Solana, Base, Arbitrum). Each replica carries a hash commitment and a Zivilia signature over the commitment, signed with the user's ML-DSA-65 key. Replicas are paid for in ZVL, the protocol token.

4.4. Verify

To recover an asset, the user reconstructs their private key from a Shamir threshold of shares, generates a Groth16 zk-SNARK proving they hold a valid share, decrypts the ciphertext client-side, and re-signs a transaction on the target chain with a one-time pre-quantum key. The pre-quantum key is derived ephemerally and is single-use; it cannot be used to drain other assets.

5. Multi-Chain Wrapping

Zivilia is chain-agnostic. The same vault can wrap assets on Bitcoin, Ethereum, Solana, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and any chain whose transaction format follows the BIP-322 / EIP-1559 / Solana transaction model families.

5.1. Chain Adapters

Each supported chain has a small adapter (~300 LoC) that implements:

• Address derivation from a 32-byte seed
• Transaction construction and signing
• Proof-of-inclusion in a finalized block
• Fee estimation in the native gas token

5.2. Cross-Chain Recovery

A user with a Zivilia vault on chain A can recover an asset on chain B without first moving the asset to chain A. The recovery transaction is signed on chain B using a derived key; the proof of vault ownership is verified via a light-client check of the originating chain's consensus.

5.3. Trust Assumptions

Cross-chain recovery requires trusting that the originating chain has not been 51%-attacked or reorged after the vault was created. Zivilia surfaces this assumption explicitly in the recovery UI; users can choose to wait N confirmations before unlocking.

6. Security Analysis

6.1. Formal Verification

The vault state machine has been formally verified in Coq against a high-level security model. The verification covers soundness (a valid signature is always verifiable) and completeness (any properly-generated key can produce a valid signature). Verification artifacts and a reproducibility kit are published alongside the code.

6.2. External Audits

• Trail of Bits — full-scope review of the vault core, including the lattice encryption layer and the zk-SNARK circuit. Report: audits/2026-Q2-trail-of-bits.pdf.
• CertiK — formal verification of the cross-chain adapter layer. Report: audits/2026-Q2-certik.pdf.
• OpenZeppelin — review of the access control, upgradeability, and emergency-pause mechanics. Report: audits/2026-Q2-openzeppelin.pdf.

6.3. Bug Bounty

A standing bug bounty of up to $1,000,000 is offered for critical vulnerabilities, hosted on Cantina. Scope and rules at zivilia.xyz/security.

6.4. Known Limitations

• Side-channel resistance of ML-DSA-65 implementation is best-effort; users with nation-state adversaries should use hardware wallets with constant-time MLWE operations.
• The Groth16 trusted setup is per-circuit and ceremony-based; a new ceremony is run for each major protocol upgrade.
• Cross-chain recovery has a 7-day challenge period during which the original chain's consensus must finalize.

7. Implementation

7.1. Software Stack

• Core: Rust 1.85, no_std compatible, with libcrux for ML-DSA-65 and a constant-time AES-256-GCM implementation.
• Node: Go 1.23, runs on Linux/ARM64 and Linux/x86_64. Minimum 4 vCPU, 8 GB RAM, 500 GB NVMe.
• SDK: TypeScript (browser + Node), Swift (iOS), Kotlin (Android). All three share a common spec and a test vector suite.
• Smart contracts: Solidity 0.8.28, deployed on each supported EVM chain with the same source.

7.2. Reproducible Builds

Every release is reproducible from the public source repository using a Docker image with pinned dependencies. Build hashes are published in the release notes and compared against the binary distributed via the official installer. Mismatches are treated as a critical security event.

7.3. Light Client

Zivilia ships a SPV light client for Bitcoin and a Helius-style light client for Solana, both written in Rust and consumable as a library. These enable users to verify vault inclusion without running a full node.

8. Governance & Token

8.1. ZVL Token

ZVL is the native utility token of the Zivilia protocol. It is used to pay for:

• Storage of ciphertext blobs on the decentralized vault network
• Cross-chain recovery operations
• Governance voting on protocol parameter changes

8.2. Token Distribution

Total supply is fixed at 1,000,000,000 ZVL. Allocation:

• Community & ecosystem grants: 35%
• Core contributors (4-year vest, 1-year cliff): 22%
• Foundation treasury: 20%
• Early backers: 15%
• Liquidity provisioning: 8%

8.3. Governance

Protocol parameters (storage fees, supported chains, audit frequency) are controlled by ZVL holders via on-chain voting. The Foundation retains a 7-day security veto on proposals that would weaken cryptographic guarantees.

9. Roadmap

9.1. Q2 2026 — Testnet

• ML-DSA-65 vault contracts deployed on 4 EVM chains
• 1,200+ validator nodes across 14 regions (live)
• First public audit completed
• SDK 1.0 for TypeScript, Swift, Kotlin

9.2. Q3 2026 — Mainnet

• Mainnet contracts live on Ethereum, Base, Arbitrum
• ZVL token generation event
• Bug bounty on Cantina (up to $1M)
• First 50 ecosystem partners onboarded

9.3. Q4 2026 — Multi-Chain Expansion

• Solana adapter live
• Bitcoin Taproot adapter live
• Cross-chain recovery between any two supported chains

9.4. 2027 — Institutional

• Hardware Security Module (HSM) integration
• Federated custody with named institutions
• SOC 2 Type II compliance

10. Conclusion

The transition to post-quantum cryptography is not a single event but a multi-year migration. Chains will debate the right path; users will need a way to protect their assets through the transition regardless of which path their chosen chain takes. Zivilia is that way.

By composing well-understood primitives — ML-DSA-65, SLH-DSA, Falcon-512, AES-256-GCM, Groth16, SHA3-512 — and binding them to a small, auditable state machine, we offer a forward-compatible custody layer that is chain-agnostic, client-side, and reproducible. We invite the cryptographic community to read, audit, and stress-test this design.

The future is post-quantum. The migration starts now.

References

1. [01]National Institute of Standards and Technology. FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism. August 2024.
2. [02]National Institute of Standards and Technology. FIPS 204 — Module-Lattice-Based Digital Signature Standard. August 2024.
3. [03]National Institute of Standards and Technology. FIPS 205 — Stateless Hash-Based Digital Signature Standard. August 2024.
4. [04]P. W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM J. Computing, 1997.
5. [05]L. K. Grover. A fast quantum mechanical algorithm for database search. STOC 1996.
6. [06]J. Bos et al. CRYSTALS-Kyber: A CCA-secure module-lattice-based KEM. EuroS&P 2018.
7. [07]T. Prest et al. Falcon: Fast-Fourier Lattice-based Compact Signatures over NTRU. IACR ePrint 2022/1455.
8. [08]A. Fiat, A. Shamir. How to prove yourself: Practical solutions to identification and signature problems. CRYPTO 1986.
9. [09]A. Shamir. How to share a secret. Communications of the ACM, 1979.
10. [10]J. Groth. On the Size of Pairing-based Non-interactive Arguments. EUROCRYPT 2016.