Is Janction Quantum Safe?

Is Janction quantum safe? It is the question every serious JCT holder should be asking right now, because the answer has direct implications for whether your private keys will remain secure as quantum computing matures. This article breaks down the cryptographic primitives Janction relies on, maps them against the known threat model of a cryptographically-relevant quantum computer (CRQC), examines what a realistic migration path would look like, and benchmarks the standard against projects that have already built post-quantum security into their architecture from day one.

What Cryptography Does Janction Actually Use?

Janction (JCT) is a decentralised exchange and cross-chain liquidity protocol. Like the vast majority of EVM-compatible and Layer-2 projects launched before 2024, Janction relies on the Ethereum cryptographic stack for key management and transaction signing. That stack is built on two primitives:

• ECDSA (Elliptic Curve Digital Signature Algorithm) using the secp256k1 curve, the same curve underpinning Bitcoin and Ethereum mainnet. Every externally owned account (EOA) address in the Ethereum ecosystem is derived from an ECDSA public key.
• Keccak-256 hashing, used for address derivation and Merkle tree construction.

Janction has not published a standalone cryptographic specification that diverges from this baseline. Its smart contracts live on EVM-compatible chains and its wallet integrations (MetaMask, WalletConnect-compatible wallets) all consume ECDSA signatures. Until a project explicitly documents a departure from this standard, the default assumption must be that it is fully exposed to the same quantum threat as every other EVM project.

Why ECDSA Is the Weakest Link

ECDSA security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP). On a classical computer, extracting a private key from a public key is computationally infeasible. Secp256k1 offers approximately 128 bits of classical security.

The problem is that Shor's Algorithm, running on a sufficiently large fault-tolerant quantum computer, can solve ECDLP in polynomial time. IBM, Google, and academic institutions have consistently published roadmaps projecting fault-tolerant quantum systems with millions of logical qubits within the next decade. At that point, any exposed public key — meaning any address that has ever signed a transaction and therefore broadcast its public key to the mempool — becomes retroactively crackable.

EdDSA: A Lateral Move, Not a Solution

Some newer protocols use EdDSA (Edwards-curve Digital Signature Algorithm) over Curve25519 (Ed25519). This is faster and avoids some implementation pitfalls of ECDSA, but the underlying hardness assumption is still the ECDLP on an elliptic curve. A CRQC breaks Ed25519 just as efficiently as secp256k1. Switching from ECDSA to EdDSA is a lateral security move that offers zero quantum resistance.

---

The Q-Day Threat Model Explained

"Q-day" refers to the moment a cryptographically-relevant quantum computer exists with enough logical qubits and low enough error rates to run Shor's Algorithm at scale against real-world key sizes. Estimates from NIST, NCSC (UK), and BSI (Germany) range from the early 2030s to the late 2030s, though some researchers argue timelines could accelerate with breakthroughs in error correction.

Two Attack Vectors That Matter for JCT Holders

1. Harvest-Now, Decrypt-Later (HNDL)

Adversaries — nation-states in particular — are already recording encrypted blockchain data and signed transactions. When a CRQC becomes available, they can retroactively derive private keys from any historical public key exposure. Every Janction user who has ever signed a transaction has already broadcast their public key. That data is immutable on-chain and cannot be recalled.

2. Real-Time Signing Attacks

Once a CRQC is operational, an attacker watching the mempool could see your public key in an unconfirmed transaction, derive your private key faster than the block confirms, craft a replacement transaction with a higher fee, and drain your wallet. Standard Ethereum transactions have a confirmation window of seconds to minutes. A CRQC operating at speed could exploit that window.

What Keccak-256 Exposure Looks Like

Keccak-256 is generally considered more quantum-resistant than ECDSA. Grover's Algorithm can speed up hash pre-image attacks from O(2^256) to O(2^128), but 128-bit quantum security is still considered adequate by current NIST guidance. Hash functions are not the urgent problem. Signature schemes are.

---

Has Janction Announced Any Quantum Migration Plan?

As of the time of writing, Janction's public documentation, GitHub repositories, and official communications contain no published quantum-resistance roadmap or post-quantum migration plan. This is not unusual. The majority of DeFi protocols have not addressed post-quantum cryptography in their documentation. The issue is industry-wide, not specific to JCT.

However, the absence of a plan is itself a risk factor. Post-quantum migration for a live protocol is significantly more complex than designing for quantum resistance from inception. It involves:

1. Replacing signature verification logic in every smart contract that validates user signatures.
2. Migrating all existing EOA-based accounts to new post-quantum key pairs.
3. Coordinating wallet infrastructure upgrades across every third-party integration (MetaMask, hardware wallets, mobile apps).
4. Maintaining backward compatibility during the transition window without opening new attack surfaces.

None of these steps are trivial. Ethereum itself has a multi-year account abstraction roadmap (EIP-4337 and beyond) that is partly motivated by making the transition to quantum-safe signatures more manageable, but full mainnet quantum safety on Ethereum is still a research-phase objective.

What a Realistic Migration Would Require

A credible post-quantum migration for an EVM protocol like Janction would likely need to include:

• Adoption of NIST PQC-standardised signature schemes, specifically CRYSTALS-Dilithium (now ML-DSA, FIPS 204) or FALCON (now FN-DSA, FIPS 206), both lattice-based algorithms that resist Shor's Algorithm.
• Account abstraction at the contract level, replacing ECDSA-based EOAs with smart contract accounts that can verify post-quantum signatures natively.
• Key migration incentive mechanisms, prompting users to rotate to new quantum-safe key pairs before Q-day.
• Audit and formal verification of any new cryptographic implementation, since lattice-based schemes have different security properties and implementation pitfalls from elliptic curve schemes.

---

Lattice-Based Post-Quantum Cryptography: How It Actually Works

The leading post-quantum alternatives to ECDSA are grounded in the hardness of lattice problems, specifically the Learning With Errors (LWE) problem and its ring variant (RLWE). These problems are believed to be hard for both classical and quantum computers.

CRYSTALS-Dilithium (ML-DSA)

Dilithium generates signatures by working with polynomial rings over modular integers. The security proof reduces to the hardness of Module-LWE and Module-SIS problems. NIST standardised it as FIPS 204 in August 2024. Signature sizes are larger than ECDSA (approximately 2,420 bytes for Dilithium2 vs 64 bytes for a compact ECDSA signature), which has on-chain gas cost implications, but the security margin against quantum attack is entirely different.

FALCON (FN-DSA)

FALCON uses NTRU lattices and achieves smaller signature sizes than Dilithium (approximately 666 bytes for FALCON-512), making it more attractive for constrained environments. It was also standardised by NIST (FIPS 206) in 2024. Its implementation complexity is higher, requiring careful handling of floating-point arithmetic during key generation to avoid side-channel attacks.

SPHINCS+ (SLH-DSA)

A hash-based signature scheme standardised as FIPS 205. It relies only on hash function security and carries no algebraic structure assumptions. Signature sizes are large (8-50 KB depending on parameter set), making it unsuitable for on-chain use in most contexts, but it serves as a conservative fallback in high-assurance environments.

---

Quantum Safety: A Comparison of Approaches

The table below positions Janction's current implied posture against different cryptographic approaches:

Projects building post-quantum security at the wallet and key-management layer from the ground up, such as BMIC.ai, are not burdened by the retrofit problem that EVM protocols like Janction face. Designing for lattice-based cryptography from inception means there is no legacy ECDSA infrastructure to unwind.

---

What JCT Holders Should Do Right Now

Regardless of whether Janction eventually ships a quantum migration, the risk exposure is at the wallet and key layer, not just the protocol layer. Individual holders carry their own quantum risk independent of any protocol's roadmap.

Practical steps to reduce exposure:

1. Minimise public key exposure. Use addresses only once for receiving, and avoid reusing signing addresses. This limits the window for HNDL attacks.
2. Monitor NIST PQC developments. FIPS 204, 205, and 206 are now final standards. Watch for wallet software that adopts them.
3. Track Ethereum's account abstraction roadmap. EIP-4337 smart accounts can theoretically support arbitrary signature verification, including post-quantum schemes, once wallet software catches up.
4. Assess hardware wallet upgrade paths. Ledger, Trezor, and other hardware wallet vendors have not yet shipped post-quantum firmware for consumer devices. Track their roadmaps.
5. Diversify custody approaches. Cold storage with strong operational security reduces real-time mempool exposure even if it does not eliminate HNDL risk.
6. Do not conflate "DeFi protocol security" with "key security." A protocol can have perfect smart contract audits and still expose users to quantum key theft if the signing infrastructure is classical.

---

The Broader Regulatory Pressure on Post-Quantum Migration

Regulators are accelerating the timeline. The US White House National Security Memorandum NSM-10 (2022) and subsequent OMB guidance require federal agencies to inventory and migrate cryptographic systems to NIST PQC standards by 2035. The EU's ENISA has issued similar guidance for critical infrastructure.

Financial regulators in several jurisdictions are beginning to classify post-quantum readiness as a component of operational resilience. While crypto protocols are not yet directly in scope for most of this regulation, institutional capital flowing into DeFi increasingly comes with operational risk criteria. Projects with no visible quantum migration plan may find themselves screened out of institutional portfolios as these criteria formalise.

For a protocol like Janction, demonstrating a credible post-quantum roadmap may become as important for ecosystem credibility as completing a smart contract audit.