Is Radworks Quantum Safe?

Is Radworks quantum safe? It is a question that matters more each year as quantum computing hardware closes the gap on cryptographic assumptions that have protected blockchain assets since Bitcoin's genesis block. Radworks (RAD) is a decentralised development platform built on Ethereum, which means it inherits Ethereum's cryptographic stack, including ECDSA on the secp256k1 curve. This article breaks down exactly what that means for RAD holders, when the threat becomes real, what migration paths exist, and how the broader ecosystem is responding to the quantum threat.

What Cryptography Does Radworks Actually Use?

Radworks is an Ethereum-native protocol. Its governance token, RAD, lives as an ERC-20 token on the Ethereum mainnet. That single fact determines the entire cryptographic surface area of concern.

Ethereum's Cryptographic Stack

Every Ethereum account, including every wallet that holds RAD, is secured by:

• ECDSA (Elliptic Curve Digital Signature Algorithm) on the secp256k1 curve, the same curve Bitcoin uses.
• Keccak-256 hashing to derive account addresses from public keys.
• RLP (Recursive Length Prefix) encoding for transaction serialisation.

When you sign a transaction to move RAD tokens, transfer governance votes, or interact with Radworks smart contracts, ECDSA is the mechanism that proves ownership without revealing your private key. The security of ECDSA rests on the hardness of the elliptic curve discrete logarithm problem (ECDLP): a classical computer cannot derive a private key from a public key in any practical timeframe.

Where EdDSA Appears

Radworks also operates Radicle, its peer-to-peer code collaboration network. Radicle uses Ed25519, a form of EdDSA (Edwards-curve Digital Signature Algorithm) built on Curve25519, for signing Git commits and authenticating node identities within the peer network. Ed25519 is faster and cleaner than secp256k1 ECDSA, but its security rests on the same underlying mathematical problem: the discrete logarithm on an elliptic curve.

This is an important nuance. Many developers assume Ed25519 is "more modern" and therefore more secure. Against classical adversaries, that is largely true. Against a sufficiently powerful quantum computer, Ed25519 and secp256k1 ECDSA are equally vulnerable.

---

The Q-Day Threat Explained

Q-day is the colloquial term for the future moment when a cryptanalytically relevant quantum computer (CRQC) can run Shor's algorithm at scale. Shor's algorithm solves the discrete logarithm problem and the integer factorisation problem in polynomial time, rendering both ECDSA and RSA cryptographically broken.

How Shor's Algorithm Breaks ECDSA

The mechanics are worth understanding:

1. A quantum computer initialises a superposition of all possible private keys.
2. Shor's algorithm exploits quantum interference to amplify the probability of measuring the correct discrete logarithm.
3. Given a public key, an attacker recovers the private key in roughly O(n³) quantum operations, where n is the bit-length of the curve parameter (256 bits for secp256k1).
4. Current estimates suggest a fault-tolerant quantum computer with approximately 2,000 to 4,000 logical qubits could execute this against secp256k1 in hours.

Today's best quantum computers (IBM's Heron, Google's Willow) operate with hundreds to low thousands of physical qubits, but logical qubits, which account for error correction overhead, remain orders of magnitude fewer. The consensus estimate among cryptographers places a CRQC capable of breaking 256-bit elliptic curves somewhere between 2030 and 2040, though some national-security agencies are planning for earlier scenarios.

The Exposed-Public-Key Problem

A critical and often overlooked nuance: not all Ethereum addresses are equally exposed.

Radworks governance is active. RAD holders regularly vote on proposals, delegate voting power, and interact with on-chain contracts. Each signed transaction exposes the sender's public key. Frequent governance participants have fully exposed public keys on-chain right now, stored permanently and available to any future adversary with a CRQC.

This is not a theoretical concern for distant wallets. It is an existing data-harvesting opportunity. Adversarial nation-states or well-resourced attackers could already be archiving public keys with the intent of decrypting them once the hardware matures, a strategy known as "harvest now, decrypt later."

---

Does Radworks Have a Quantum Migration Plan?

As of the most recent publicly available Radworks governance discussions and documentation, there is no formal quantum-resistance roadmap for RAD or the Radicle peer network. This is not unusual. The majority of Ethereum-native protocols have deferred this question, largely because the answer depends heavily on what Ethereum itself does.

Ethereum's Own PQC Roadmap

Ethereum's core developers are aware of the quantum threat. Vitalik Buterin has publicly written about a quantum emergency recovery path that would involve:

1. A hard fork to invalidate all ECDSA-based transactions.
2. Migration to STARK-based account abstraction, where account ownership is proven via zero-knowledge proofs using hash-based cryptography (which is quantum-resistant).
3. A recovery mechanism for users who can prove pre-fork ownership without revealing a private key.

This approach is technically plausible but represents a significant coordination challenge. Any protocol built on Ethereum, including Radworks, would inherit whatever migration Ethereum executes. However, the timeline for Ethereum's PQC migration is not fixed, and in a sudden Q-day scenario, the gap between a CRQC becoming operational and a coordinated hard fork being deployed could be measured in weeks, creating a window of genuine vulnerability.

Radicle Network Cryptography Migration

The Ed25519 signatures used in Radicle's peer-to-peer layer present a separate migration problem. NIST's post-quantum cryptography standardisation process (finalised in 2024) produced three primary standards:

• ML-KEM (CRYSTALS-Kyber) for key encapsulation.
• ML-DSA (CRYSTALS-Dilithium) for digital signatures.
• SLH-DSA (SPHINCS+) for stateless hash-based signatures.

Replacing Ed25519 with ML-DSA in Radicle's node identity and commit-signing layer is technically feasible. ML-DSA signatures are larger (roughly 2.4 KB versus Ed25519's 64 bytes), which has storage and bandwidth implications for a Git-based system that handles large repositories. A migration would require a protocol-level upgrade and backward-compatibility planning across all Radicle nodes. No such upgrade is currently in the Radworks roadmap.

---

How Lattice-Based Post-Quantum Wallets Differ

The practical question for a RAD holder today is not whether Radworks will eventually migrate, but whether their wallet provides any additional protection in the interim.

Standard Ethereum wallets, including MetaMask, Ledger, Trezor, and most hardware wallets, use ECDSA/secp256k1 exclusively. They generate keys, sign transactions, and operate entirely within the classical cryptographic model. If a CRQC becomes available, the private key behind any such wallet can be derived from its public key.

Lattice-based post-quantum wallets operate on fundamentally different mathematical hard problems. The two most relevant are:

• Learning With Errors (LWE): Security rests on the difficulty of solving systems of linear equations with small random errors added. No known quantum algorithm solves LWE efficiently.
• Module-LWE (MLWE): The modular variant used by CRYSTALS-Dilithium and CRYSTALS-Kyber, which underpins NIST's ML-DSA and ML-KEM standards.

A wallet built on lattice cryptography generates keys and signatures using these quantum-resistant primitives. Even if an attacker possesses a CRQC and a harvested public key, they cannot derive the corresponding private key because the underlying mathematical problem remains hard in the quantum model.

BMIC.ai is one example of a wallet project building on NIST PQC-aligned, lattice-based cryptography specifically to address Q-day exposure for crypto holders, including those holding assets on Ethereum-native protocols like Radworks.

The practical tradeoff is that lattice-based signatures are larger and key generation is slower than ECDSA. For a governance-active RAD holder making occasional on-chain votes, these costs are negligible. For high-frequency trading systems, they require more careful engineering.

---

What RAD Holders Should Do Right Now

Waiting for protocol-level fixes is a passive strategy with real risk. Here are concrete actions available today:

Reduce Public Key Exposure

• Use a fresh address for each governance interaction where possible, minimising the period during which a public key is exposed and the associated balance remains at risk.
• Move dormant holdings to a never-spent address. An address that has never sent a transaction has not yet revealed its public key on-chain. This does not eliminate quantum risk entirely (a sufficiently powerful quantum computer could eventually reverse Keccak-256 hashing, though this requires a different and likely larger quantum advantage than Shor's), but it substantially raises the attack cost.

Monitor Ethereum's PQC Developments

• Follow ethereum-magicians.org and Ethereum Improvement Proposals (EIPs) tagged with "account abstraction" and "post-quantum." EIP-7702 and related account abstraction work is the most likely vehicle for a future PQC migration.
• Watch NIST for any updates to the three 2024 PQC standards (ML-KEM, ML-DSA, SLH-DSA) and for additional standards in the pipeline, particularly for stateful hash-based signatures.

Evaluate Post-Quantum Custody Options

• Research wallets and custody solutions that are actively implementing NIST PQC standards rather than relying on future Ethereum-level fixes.
• Assess hardware wallet vendor roadmaps. Ledger and Trezor have not yet shipped PQC firmware; monitor their developer communications.

Participate in Governance

RAD token holders have voting power. There is no reason a community governance proposal could not push Radworks to formally publish a quantum threat assessment or fund research into a migration path. Protocols that engage early with PQC transitions will be better positioned when Ethereum itself moves.

---

Comparing Quantum Readiness Across the Stack

The table reveals that quantum vulnerability in the Radworks ecosystem is multi-layered. A fix at the Ethereum protocol level addresses the RAD token layer but does nothing for Radicle's peer network, and vice versa. A comprehensive quantum-safe Radworks would require coordinated upgrades across all four layers.

---

The Broader Context: Why This Matters Now

The cryptographic community's rule of thumb is that systems should be migrated to post-quantum standards at least ten years before a CRQC is expected to become operational, because migration of large-scale distributed systems takes years of planning, testing, standardisation, and deployment. If even the optimistic estimate of 2030 for a CRQC is correct, the migration window for Ethereum and its ecosystem is already narrow.

NIST's completion of its PQC standardisation in 2024 removed the primary blocker for migration work. The standards are final. The algorithms are published. The reference implementations exist. The remaining work is engineering, governance, and coordination, which is exactly the kind of work that Ethereum's developer community and protocols like Radworks are positioned to begin now.

The honest answer to "is Radworks quantum safe?" is no, not yet, and neither is the vast majority of the Ethereum ecosystem. The relevant question for any RAD holder is not whether to be concerned, but what proactive steps to take while the migration window remains open.