Quantum Layer 2 Blockchain
Product 01
📋 RESEARCH COMPLETE — DEVELOPMENT PLANNED

Quantum-Resilient Layer 2 Blockchain

We now explore the next logical phase of our research initiative: designing a quantum-resilient Layer 2 blockchain. The central question is whether a blockchain system can be secured against future quantum adversaries without fundamentally redesigning existing Layer 1 networks. The answer is yes—and Layer 2 architectures provide the most practical and scalable path to achieving this goal.

Layer 2 solutions, particularly rollups, execute transactions off-chain and rely on cryptographic proofs for validity. This architectural separation offers significantly greater flexibility to integrate post-quantum cryptographic primitives while avoiding disruptive changes to base Layer 1 protocols. As of late 2025, emerging efforts such as experimental work by Abelian (QDay) and QRL's Project Zond signal a growing industry trend toward post-quantum-secured Layer 2 designs.

Why Layer 2 Is Better Suited for Quantum Resistance

Layer 1 blockchains (e.g., Ethereum or Bitcoin) require broad soft or hard forks to migrate toward post-quantum cryptography—changes that directly affect consensus rules, block formats, and transaction sizes. Recent cryptographic research (e.g., ePrint 2025/1626) highlights that such migrations are operationally complex and socially challenging at Layer 1.

Layer 2 architectures, by contrast, provide several key advantages:

  • Post-quantum cryptographic proofs without modifying the underlying Layer 1 protocol, allowing Ethereum or Bitcoin to remain operational during the transition period.
  • Isolated overhead, where post-quantum computation is limited to sequencers, provers, and verifiers rather than the entire network.
  • Preserved scalability, as larger post-quantum primitives (e.g., Dilithium or SPHINCS+) are amortized through batching, aggregation, and zero-knowledge proof compression.
  • Existing quantum-resilient foundations, as zk-STARKs—already deployed in systems like StarkNet—rely solely on hash-based assumptions and are widely regarded as quantum-resistant.
  • Strategic alignment with Ethereum's long-term roadmap, which increasingly acknowledges the need for quantum resistance, with Layer 2 systems serving as practical experimentation environments.

Chosen Methodology for a Quantum-Resilient Layer 2 Design

We propose a PQZK Rollup (Post-Quantum Zero-Knowledge Rollup) architecture that combines mature Layer 2 technology with NIST-standardized post-quantum cryptography.

Proof System

  • Primary Proof Mechanism: zk-STARKs (preferred), due to their reliance on collision-resistant hash functions and absence of trusted setup.
  • Alternative Research Direction: zk-SNARK systems augmented with post-quantum-secure authentication layers. While classical SNARK constructions are not post-quantum by themselves, their use in conjunction with post-quantum signatures remains an active research area.

Transaction and Batch Signatures

  • Primary Signatures: ML-DSA (Dilithium) for sequencer authentication and batch commitments.
  • Fallback Option: SLH-DSA (SPHINCS+), offering stateless operation and cryptographic diversity for high-assurance scenarios.

Hash Functions

  • Quantum-Resistant Hashing: SHA3-512 or BLAKE3, maintaining sufficient security margins against Grover-style quadratic speedups.

Hybrid Compatibility Mode

  • Support for classical ECDSA signatures during the transition period, ensuring compatibility with current Layer 1 ecosystems such as Ethereum.

This methodology reflects early experimental signals from projects like QDay and Project Zond, which demonstrate how post-quantum primitives can be incrementally introduced without sacrificing performance or ecosystem compatibility.

Overall Proposed Layer 2 Architecture

Rollup Type

  • ZK-Rollup (preferred over Optimistic Rollups), providing cryptographic validity guarantees without challenge periods and enabling faster settlement under quantum-resilient assumptions.

Core Components

  • Sequencer: Collects and batches transactions, authenticated using ML-DSA signatures.
  • Prover: Generates zero-knowledge validity proofs using STARK-based or research-stage post-quantum-friendly proof systems.
  • Verifier (Layer 1): A smart contract deployed on Layer 1 that verifies proofs. Hybrid verification logic is used where the base chain is not yet post-quantum secure.
  • Data Availability: Supports on-chain data availability via Ethereum blobs or modular data availability layers such as Celestia, secured using post-quantum hash functions.

Additional Security Measures

  • Periodic sequencer key rotation.
  • Post-quantum threshold signatures for sequencer decentralization.
  • Optional zero-knowledge privacy proofs for confidential transactions.

Compatibility and Migration Strategy

The system is designed for gradual migration, enabling coexistence with classical cryptography over a projected 5–15 year transition window. Key compatibility features include:

  • EVM-compatible execution, lowering the barrier for existing decentralized applications.
  • Hybrid cryptographic support, allowing classical signatures until Layer 1 ecosystems complete post-quantum upgrades.
  • Interoperability adapters and bridges for ecosystems such as Solana, BNB Chain, and Bitcoin.

Main Challenges and Scientific Solutions

  • Proof Size and Overhead: STARK proofs are larger than SNARKs. This is mitigated through recursive proof composition and aggregation, achieving 50–70% size reductions, consistent with StarkNet 2025 benchmarks.
  • Proof Generation Cost: Zero-knowledge proof generation is computationally intensive. GPU and ASIC acceleration—as explored in collaborations such as Cysic and zkSync—substantially improves throughput and cost efficiency.
  • Layer 1 Cryptographic Limitations: Current Layer 1 chains are not fully post-quantum secure. This design minimizes reliance on Layer 1 cryptography by using it primarily for data availability and settlement, while core security assumptions reside in Layer 2 proofs.

Performance and Conclusion

Theoretical modeling and benchmark analyses of post-quantum ZK-rollup architectures project the ability to sustain thousands to tens of thousands of transactions per second, depending on hardware acceleration and proof recursion depth. Systems such as StarkNet already demonstrate that quantum-resilient cryptography can coexist with high-throughput Layer 2 execution.

In conclusion, building a quantum-resilient Layer 2 blockchain is not only feasible but represents the most strategic and realistic pathway toward quantum-safe blockchain scalability. Our proposed architecture provides a foundation for secure interoperability with existing chains while preparing for the cryptographic realities of the post-quantum era.

Key Features

High Throughput

Target throughput exceeding 10,000 TPS

Quantum-Resilient Security

Post-quantum cryptographic primitives across execution and proof layers

Low Fees

Sub-cent transaction costs enabled by rollup batching

Multi-Environment Compatibility

EVM-compatible execution with interoperability support for Solana, BNB Chain, and Bitcoin

Technical Specifications

  • Consensus: Proof-of-Stake with post-quantum-secured validator authentication
  • Block Time: ~2 seconds
  • Finality: Fast finality upon proof verification
  • Smart Contract Support: Ethereum EVM (with interoperability adapters)
  • Data Availability: On-chain (Ethereum blobs) or modular DA layers
Quantum Wallet
🔧 ACTIVELY IN DEVELOPMENT — BETA COMING SOON

Quantum Wallet

Why Do We Need a Quantum-Resistant Wallet?

Current digital signature algorithms such as ECDSA (used in Bitcoin and most blockchains) and EdDSA are based on the hardness of the discrete logarithm and elliptic curve problems. A sufficiently powerful quantum computer running Shor's algorithm can solve these problems in polynomial time, thereby enabling efficient recovery of the private key by solving the underlying discrete logarithm problem from a publicly known key.

In contrast, Grover's algorithm provides only a quadratic speedup for brute-force searches over hash spaces. This impact can be effectively mitigated by selecting hash functions with sufficiently large output sizes (e.g., SHA3-256 or BLAKE3-256 and above), which still provide acceptable post-quantum security margins.

As a result, the primary design focus of our wallet is the replacement of classical signature schemes with NIST-standardized post-quantum algorithms, while preserving usability, performance, and compatibility with existing blockchain ecosystems.

Chosen Methodology for Implementation

Our team has selected a dual-algorithm approach based on two finalized NIST standards—FIPS 204 and FIPS 205, published in August 2024—which currently offer the best balance between security, efficiency, and implementation maturity.

  • ML-DSA (formerly CRYSTALS-Dilithium) — Primary Signature Algorithm
    • Lattice-based post-quantum signature scheme
    • High security guarantees with NIST security levels 2–5
    • Efficient signature generation and verification
    • Reasonable signature sizes (approximately 2.4–4.8 KB, depending on the security level)
    • Well-suited for frequent transaction signing in blockchain environments
  • SLH-DSA (formerly SPHINCS+) — Backup / Fallback Algorithm
    • Fully stateless and hash-based
    • Extremely conservative and lattice-independent security assumptions
    • Larger signature sizes (typically 8–50 KB), making it most appropriate for high-security or emergency fallback scenarios
    • Valuable as a secondary defense layer against unforeseen cryptanalytic advances

Why ML-DSA (Dilithium) as the Primary Algorithm?

Based on the latest NIST evaluations, real-world blockchain initiatives, and ecosystem proposals (e.g., QRL's Project Zond, QANplatform, and related post-quantum research), ML-DSA currently offers the most practical trade-off across:

  • Signature generation and verification speed
  • Acceptable key and signature sizes for blockchain transactions
  • Mature, well-tested implementations (e.g., liboqs, pq-crystals, Cloudflare CIRCL)
  • Broad industry adoption following the finalization of FIPS 204

While Falcon (FN-DSA, FIPS 206 — in development) provides smaller signature sizes, its higher implementation complexity and increased sensitivity to side-channel attacks in constrained environments led us to retain it as a secondary option during the initial phase of the project.

Overall Proposed Wallet Architecture

Seed and Key Generation

  • Use of a resistant mnemonic scheme (BIP-39 with maximum entropy or an extended entropy mnemonic format)
  • Master key generation using HKDF or KMAC, based on SHAKE256
  • Derivation of child keys using hierarchical paths conceptually similar to BIP-32, but redesigned with post-quantum-safe, hash-based derivation

Address Generation

  • Addresses are derived as: BLAKE2b-256(ML-DSA public key), optionally combined with versioning and checksum fields
  • To minimize long-term public key exposure, one-time-use or stealth-style addresses are employed

Transaction Signing

  • Primary signing algorithm: ML-DSA (Dilithium)
  • Optional ultra-secure mode: Dual signatures (Dilithium + SPHINCS+), or post-quantum threshold / multi-signature schemes

Private Key Storage

  • Preferred option: Hardware wallets with post-quantum cryptographic support
  • Software wallets: Private keys encrypted using AES-256, password-based key derivation with Argon2id
  • Seed splitting via Shamir's Secret Sharing, providing information-theoretic security

Compatibility and Migration Strategy

  • Hybrid design supporting both classical (ECDSA) and post-quantum (ML-DSA) signatures during the transition period
  • Use of account abstraction mechanisms (e.g., ERC-4337 on Ethereum) to introduce post-quantum signature validation without modifying base Layer 1 consensus rules
  • Gradual migration paths leveraging Layer 2 solutions or protocol upgrades with dual-signature support

Main Challenges and Considered Solutions

  • Larger signature and key sizes: Mitigated through address abstraction, limited public key exposure, and batch verification at higher layers
  • Computational overhead: Reduced via SIMD optimizations, low-level assembly tuning, and efficient cryptographic libraries
  • Side-channel attacks: Addressed through constant-time implementations and protection against timing and cache-based leakage
  • Migration from existing blockchains: Handled through hybrid cryptographic support, Layer 2 integrations, and backward-compatible wallet logic

Development Status and Goals

Our objective is to deliver a practical, production-grade prototype that can serve as a reference implementation for next-generation blockchains or post-quantum upgrades of existing wallets. Current development efforts focus on:

  • Implementing ML-DSA in Rust
  • Performance benchmarking on simulated transaction workloads
  • Evaluating UX trade-offs between security modes

Key Features

Quantum-Safe Keys

Post-quantum key generation and signing

Biometric Authentication

Face ID and fingerprint support

Multi-Signature

Post-quantum threshold signatures

Multi-Chain

Multi-chain support — expanding with each release

Supported Platforms

iOS Android Browser Extension Desktop Hardware Wallet

Security Features

  • Quantum-resistant key derivation
  • Secure enclave and hardware-backed storage
  • Post-quantum transaction signing
  • Social recovery mechanisms (planned)
  • Built-in decentralized application (DApp) browser (planned)
Quantum Bridge
Product 03
📋 RESEARCH COMPLETE — DEVELOPMENT PLANNED

Quantum Bridge

Today, we present another core component of our research initiative: Quantum Bridge, a cross-chain bridge designed around a threshold architecture with post-quantum validators. This system builds upon our earlier post-quantum wallet research and aims to deliver a secure, decentralized, and future-resistant interoperability layer capable of withstanding even large-scale quantum adversaries.

By distributing trust across independent validators and eliminating single points of failure, Quantum Bridge achieves a strong balance between security, decentralization, and scalability—comparable to modern bridges such as Axelar or Threshold Network, but enhanced with post-quantum cryptographic guarantees.

Why a Threshold Bridge with Post-Quantum Validators?

Cross-chain bridges remain one of the most vulnerable components in the blockchain ecosystem. According to the Chainalysis 2024 report, more than $2 billion USD has been lost to bridge-related exploits (e.g., Ronin, Wormhole), primarily due to centralized key management, compromised validator sets, or weak cryptographic assumptions.

In the context of quantum computing, classical cryptographic primitives face additional risks. Shor's algorithm theoretically enables polynomial-time attacks against elliptic curve cryptography (ECDSA), with multiple academic and industry projections (e.g., IBM, Google) estimating feasibility at the scale of millions of fault-tolerant qubits. While Grover's algorithm accelerates brute-force attacks on hash functions, this threat can be mitigated through quantum-resistant hashes such as BLAKE3, which retains sufficient security margins.

The threshold post-quantum model directly addresses these risks by distributing signing authority across multiple validators using post-quantum multi-party computation (MPC). Leveraging Shamir's Secret Sharing, the system achieves information-theoretic security, remaining secure independently of advances in quantum computation. Real-world research efforts such as Polkadot JAM (2025 roadmap) and experimental platforms like QuantumShield-BC demonstrate that such architectures can scale efficiently, typically incurring only 10–20% additional latency while substantially increasing security guarantees.

Chosen Methodology for Implementation

Our architecture adopts NIST-standardized post-quantum algorithms (FIPS 204 and FIPS 205, finalized in 2024), deployed in threshold configurations to eliminate centralized trust assumptions:

  • Threshold ML-DSA (Dilithium) → Primary signature algorithm: Lattice-based cryptography providing 128–256 bits of post-quantum security (NIST security levels 2–5). Threshold variants, based on recent academic research (e.g., University of Bern, 2024), enable validators to independently produce partial signatures that are aggregated into a single verifiable signature. Ongoing work is focused on hardening these constructions toward production-grade implementations.
  • Threshold SLH-DSA (SPHINCS+) → Experimental fallback for ultra-high-security scenarios: Hash-based, stateless design with minimal cryptographic assumptions (collision-resistant hashes). Larger signature sizes (typically 5–10 KB in threshold configurations) and higher computational overhead. Provides cryptographic diversity, remaining independent of lattice-based assumptions.

Rationale: NIST IR 8413 (2024) highlights ML-DSA as offering the most favorable balance between performance and signature size, achieving millisecond-level signing latency even under threshold configurations. SLH-DSA serves as a conservative fallback option where maximum long-term security is prioritized. Compared to alternatives such as Falcon, Dilithium exhibits stronger resistance to side-channel attacks, as demonstrated in Crypto 2024 evaluations.

Overall Proposed Bridge Architecture

Validators Layer

  • Selection: Validators are selected via staking or governance mechanisms, similar to Cosmos-style networks, supporting 16–100 independent nodes
  • Key Generation: Validators generate post-quantum keys through MPC, grounded in threshold cryptography models validated in Eurocrypt 2023
  • Threshold: A 2/3 supermajority (e.g., 12 of 16 validators) prevents collusion, consistent with Byzantine Fault Tolerant (BFT) security models
  • Key Rotation: Regular key rotation (e.g., every 24–48 hours, configurable based on network conditions) minimizes long-term exposure

Threshold Post-Quantum Signature Layer

  • Message Processing: Validators verify cross-chain events (e.g., token burns or state commitments) using BLAKE3 hashes, then produce threshold signatures
  • Hybrid Mode: Concurrent support for ECDSA and ML-DSA ensures compatibility with legacy blockchains during the post-quantum migration period
  • Aggregation: Partial signatures are efficiently combined, leveraging SIMD-level CPU optimizations — a technique benchmarked in the Open Quantum Safe (liboqs) project to reduce computational overhead in post-quantum signature operations

Cross-Chain Message Layer

  • Input: Events or cryptographic proofs from the source chain
  • Output: A threshold post-quantum signature submitted to the destination chain for minting or state updates
  • Additional Security: Optional integration of post-quantum zero-knowledge proofs (e.g., STARK-based systems relying on hash-based assumptions) for privacy and data minimization

Storage and Security Layer

  • Key Storage: Post-quantum keys are protected using dedicated post-quantum-capable HSMs
  • Slashing Mechanisms: Economically penalize malicious or faulty validators via stake reduction, aligning incentives through game-theoretic Nash equilibrium models

Compatibility and Migration Strategy

Quantum Bridge is designed as a hybrid system to support a gradual transition over the next 5–15 years. It enables seamless interoperability across heterogeneous ecosystems, including Ethereum, Solana, BNB Chain, and Bitcoin, while maintaining backward compatibility with pre-PQC infrastructures.

Main Challenges and Scientific Solutions

  • Signature Size and Latency: Post-quantum signatures are inherently larger. This is mitigated through batch signing, signature aggregation, and low-level assembly optimizations — techniques actively explored in academic research and open-source PQC libraries to substantially reduce per-operation latency.
  • Post-Quantum MPC Complexity: Threshold MPC introduces operational complexity. This is addressed through liboqs-based implementations with threshold extensions, validated in real-world testing environments such as Cloudflare's cryptographic research stack.
  • Computational Cost: Post-quantum operations demand higher computational resources. Hardware acceleration (e.g., FPGAs) significantly reduces latency and operational costs while improving throughput.
  • Side-Channel Attacks: All cryptographic components employ constant-time implementations, consistent with best practices validated in CHES 2024.

Key Features

Multi-Chain

Support for 10+ blockchains (expanding)

Trustless

No centralized custody or single signing authority

Fast Transfers

Less than 2-minute finality

Quantum-Safe

Post-quantum cryptographic verification

Supported Chains

Ethereum
Solana
BNB Chain
Bitcoin

Bridge Mechanisms

  • Light client verification
  • Quantum-resistant threshold multi-signature
  • Optimistic rollup proofs
  • Automated liquidity management

Ready to Get Started?

Choose the product that fits your needs and join the quantum-resistant revolution.