Learn how enterprise networks can prepare for post-quantum cryptography, manage migration risks, and strengthen blockchain security with ARMChain’s quantum-resistant architecture.
Roohan Adeel
Google has revealed its plan to complete its own migration to post-quantum cryptography by the end of 2029 (Dark Reading). NIST’s official draft IR 8547 deprecates RSA and elliptic-curve algorithms after 2030 and plans to disallow them after 2035 (CSA Summary).
Blockchains are on the same calendar; it doesn’t matter whether they admit it. Bitcoin and Ethereum authenticate every transaction with ECDSA, and Shor’s algorithm breaks ECDSA on a large enough quantum computer. So what should the quantum-safe blockchain platform an enterprise picks today look like? Is one already being made for it? It’s time to review what matters and where ARMchain stands.
Nobody knows the year when the first large-scale quantum computer will arrive, and the estimates keep shrinking. Craig Gidney’s 2025 paper put RSA-2048 within reach of under one million noisy qubits, down from the 20 million he and Martin Ekera estimated in 2019. For a blockchain, the damage lands in three places.
Accounts come first. An Ethereum address is a hash of the public key, but the key itself is revealed the first time the account signs anything. So every account that has ever sent a transaction can be drained once signatures can be forged. Consensus is next, because forged validator signatures let an attacker produce blocks at will. Then comes networking. A recorded peer-to-peer handshake with a classical key exchange can be decrypted later.
Simply put, a platform is quantum-safe only if nothing protecting funds or consensus depends on a problem Shor’s algorithm solves. Hashes and symmetric ciphers are different. Grover’s algorithm only halves their strength, so keccak-256 and AES-256 keep 128 bits of security, leaving three layers to replace.
Post-quantum keys are bigger. An ML-DSA-44 public key is 1,312 bytes, and its signature is 2,420 bytes. The whitepaper says verification takes 46 to 52 microseconds, close to secp256k1 sender recovery, but a signed transfer is about 32 times larger. The cost is shown in bytes.
ARMchain is an EVM-compatible Layer 1 blockchain protocol whose keys, signatures, and network handshakes are post-quantum from genesis. Enterprise teams are focused on these design choices.
ML-DSA-44 primitive is verified in three independent places: the consensus engine, the transaction signer, and through the 0x0100 precompile inside the EVM. That last one gives quantum-safe execution at the contract level. Moreover, smart contracts allow checking who is calling without falling back to ECDSA.
ARMchain runs Lachesis, a leaderless asynchronous BFT consensus inherited from Fantom Opera, with every validator signature replaced by ML-DSA-44. A block is complete once the protocol decides it. Safety holds while less than one third of the stake is faulty. For settling payments or anchoring records, a fixed answer beats a probable one.
Existing Solidity contracts deploy unchanged if they’re compiled for the London fork, which means no PUSH0. The JSON-RPC is the same, so indexers and backends connect the way they do today. Only applications that sign or parse transactions themselves need the ARMchain SDK.
Type-4 transactions use native account abstraction. Its own code decides whether a transaction is authorised, so each account picks its scheme: ML-DSA, SLH-DSA, a hybrid of ECDSA and ML-DSA that needs both signatures, a passkey, or a guardian set. Fees can be sponsored, and guardians can be a source to recover a lost key. Two of those options are classical. Passkeys use P-256, and the first guardian design signs with secp256k1.
The whitepaper limits itself to NIST standards ML-DSA-44, ML-KEM-768, and SLH-DSA. There’s no bespoke cryptography. Scheme choice sits at the account level, and handshakes are versioned, so according to the paper, the network can adopt or retire the algorithm without a complete redesign.
The label AI-native Layer 1 blockchain gets used loosely. ARMchain doesn’t host models or sell GPU time. They are the AI agents that pays, swaps, or calls contracts needs an account, and that account needs a signature a quantum computer can’t forge. Because the account’s own code authorises each transaction, a developer can build limits into it, such as a daily cap or a second approval above a set amount. The agent’s model and data still need protection elsewhere.
Call it a quantum-safe transformation platform or just a migration path. The test is the same: can an organisation reach post-quantum accounts without rebuilding everything? The whitepaper describes four steps.
Accounts that stay on types 0 to 2 are, in the whitepaper’s words, “exactly as exposed as on Ethereum.” Wallets should steer users to post-quantum accounts.
A next-generation blockchain establishes its authority by saying what’s missing. As of the October 2026 whitepaper, ARMchain runs on a devnet. A public testnet is targeted in the coming days, and the mainnet date is deliberately not revealed. Node transport uses ML-KEM-768 alone for now, with a hybrid X25519 plus ML-KEM-768 exchange planned as a mainnet blocker.
Buyers with Australian government obligations should also check ML-DSA-44 against the current ISM, because reports on its latest edition list only ML-DSA-65 and ML-DSA-87 as approved. For how ARMchain compares with other post-quantum chains, see our comparison guide.
Its account, validator, and network-handshake cryptography must use post-quantum algorithms such as ML-DSA and ML-KEM. Hashes like keccak-256 and AES-256 can stay, since Grover’s algorithm only halves their strength.
No. It runs on a devnet; a public testnet is expected in the next few days; however, the mainnet date isn’t set. An external audit is planned before mainnet.
Accounts on standard Ethereum types 0 to 2 use secp256k1 and are as exposed as on Ethereum. Passkey accounts use P-256, and the first guardian design signs with secp256k1. ML-DSA, SLH-DSA, and hybrid accounts are the post-quantum options.
Yes, if they’re compiled for the London fork. Applications that sign or parse transactions themselves need the ARMchain SDK.
No. ARMchain doesn’t host models or sell GPU time. It handles the transaction side: accounts, payments, and contract calls. Models and their data run elsewhere.