Post-Quantum Blockchains Need More Than New Ciphers: How Accounts Actually Make the Move

Quantum resistance is back at the center of crypto conversations. Ethereum has placed post-quantum transition front and center in its recent roadmap narrative, and a nervous piece of advice has started circulating on social media: if your wallet address has ever sent even a single outgoing transaction, your public key is exposed on-chain, so you should immediately sweep all your funds into a brand-new wallet.

When people ask where we stand on this, my short answer comes first: Don't panic.

Adding a post-quantum signature verifier to a cryptography library is the straightforward part. For a live blockchain, the hard engineering problem is never just "how to verify a new cipher," but how to move millions of existing accounts to new keys without breaking every saved receiving address, getting front-run the moment an exposed key tries to rotate, or blowing past transaction byte limits.

That is why, when we designed the very first version of the ArcBlock blockchain in 2018, we did not bet the protocol on an immature post-quantum candidate. Instead, we built two foundational primitives into the base layer: a self-describing did:abt: identifier that decouples account identity from any single signature curve, and native protocol-level Account Migration. We filed the patent for that account migration mechanism in October 2019, and the USPTO granted it in July 2022 (US11388010B2) [1].

Still, resting on a design from seven or eight years ago is not enough. While preparing our upcoming ArcBlock Chain upgrade and running a full-stack adversarial security audit across our transaction protocols, we stress-tested our own assumption. We asked a blunt question: if quantum threats became practical tomorrow, would version-1 account_migrate alone be enough?

The honest answer was no. Naive migration leaves concrete gaps around already-exposed public keys, front-running during key rotation, and the massive byte footprint of post-quantum signatures. Here is what quantum computing actually threatens on a blockchain, why Bitcoin, Ethereum, and Solana face very different structural hurdles, what we tightened in our latest upgrade, and what everyday wallet users should do right now.

What Quantum Computers Actually Threaten (and What They Don't)

Public discussions about quantum computing and crypto often blur two very different cryptographic building blocks: cryptographic hashes and public-key digital signatures.

Blockchains rely on hash functions (SHA-256, SHA3-256, Keccak-256) to link blocks, build Merkle proofs, and derive address digests from public keys. Grover's quantum algorithm only gives a quadratic speedup for preimage and second-preimage search. For a 256-bit hash, reversing an address digest or forging a block link still requires roughly 2^128 operations, which remains physically out of reach. Hash chains and unexposed hash-derived address digests are not broken by quantum computers.

Elliptic-curve digital signatures (secp256k1 on Bitcoin and Ethereum, Ed25519 on Solana and ArcBlock, P-256 in hardware Passkeys) are a different story. Their security rests on the elliptic-curve discrete logarithm problem. Computing a public key from a private key is trivial, while reversing the process is intractable on classical hardware.

If a large-scale, fault-tolerant Cryptographically Relevant Quantum Computer (CRQC) is eventually built, Shor's algorithm could reverse that one-way math and recover a private key from an exposed public key.

That distinction explains why security researchers draw a line between two states of an account:

Recognizing that difference is good cryptographic literacy. Why, then, do I still tell users not to rush into manual wallet transfers today? Looking at how major blockchains bind addresses to keys makes the trade-offs clear.

Why Older Chains Face Structural Friction

Bitcoin, Ethereum, and Solana made deliberate architectural choices in their early days to optimize for simplicity, EVM execution, or raw packet throughput. Those choices now shape how hard it is for each network to swap out elliptic curves.

Take Bitcoin first. Early coinbase and P2PK outputs placed raw secp256k1 public keys directly on-chain. Later P2PKH and SegWit (P2WPKH) addresses hid the public key behind a hash until the first spend, though reusing an address after spending immediately leaves the key exposed. More recently, Taproot (BIP-341) chose to encode a 32-byte tweaked public key directly in the output script to save witness bytes [4]. And because Bitcoin has no stateful account object, changing algorithms requires every holder to manually broadcast an on-chain transaction sweeping their UTXOs to a new address.

Ethereum faces a different bottleneck. A standard Externally Owned Account (EOA) derives its 0x address from keccak256(secp256k1_pubkey), and the base protocol provides no native transaction to swap the underlying keypair while keeping the account intact. Once an EOA sends a single transaction, its secp256k1 public key is recoverable forever. That is a major reason Ethereum has spent years pushing Account Abstraction (ERC-4337 and EIP-7702) to retrofit programmable signature verification onto legacy EOAs [4].

Solana optimized for speed by making a user's wallet address the raw 32-byte Ed25519 public key itself. Because there is no hash indirection, the public key is public the moment you give someone your receiving address. On top of that, Solana's classic transaction wire format was designed to fit inside a single 1,232-byte network MTU packet, whereas standard post-quantum signatures measure several kilobytes each.

When you compare these designs side by side, the lesson is straightforward: the hardest part of post-quantum readiness is not writing a new signature verifier. It is giving existing accounts a safe, non-disruptive way to change keys.

What We Built on Day One: Self-Describing DIDs and Patented Account Migration

When we designed ArcBlock's decentralized identifier (did:abt:) and OCAP state machine in 2018, we made two architectural decisions that kept us out of that corner.

First, every did:abt: identifier starts with a 16-bit self-describing binary header before the 20-byte public-key hash and 4-byte checksum: 6-bit RoleType | 5-bit KeyType | 5-bit HashType.

Because KeyType and HashType are explicit metadata inside the identifier protocol rather than hardcoded assumptions, our chain never assumed that the world would use a single signature algorithm forever. When we needed Ed25519 and secp256k1 side by side, both worked natively. When we added hardware-backed Passkey (P-256 WebAuthn) accounts in v1.19.x, we registered the new key type without disturbing existing accounts. Supporting a NIST post-quantum signature scheme follows the exact same extension path in @ocap/mcrypto.

Second, we built protocol-level account migration (AccountMigrateTx / account_migrate) into the state machine from version 1, covered by our granted US patent US11388010B2 [1]. As we explained in our earlier walkthrough of the SDK and execution rules, account_migrate solves the continuity problem after a key change:

For years, our thesis was simple: use compact, battle-tested classical curves for everyday transactions today, and rely on AccountMigrateTx to move accounts onto post-quantum keys when quantum hardware starts becoming a realistic concern.

Why "Just Migrate Later" Was Only Half the Answer: Three Upgrades from Our Recent Audit

During the architecture and security review for our upcoming chain upgrade, we challenged our own thesis. Suppose an account has already sent transactions, meaning its current public key PK1 is visible on-chain. What actually happens when that account tries to run account_migrate under adversarial conditions or with post-quantum key sizes?

That review exposed three concrete gaps in the original version-1 assumption, and we fixed all three in the upgrade.

1. Exposed Public Keys and Migration Hijacking: Adding KERI Pre-Rotation and Mandatory Dual Signatures

Think about an account whose active public key PK1 is already exposed on-chain. If an attacker compromises PK1 (whether through a classical key leak today or a quantum attack in the future), the attacker can sign an AccountMigrateTx just as easily as the legitimate owner can, racing to redirect the account to an attacker-controlled address.

Even worse, our audit of the legacy migrate.ts implementation found that version 1 only verified the signature of the outgoing from wallet (VerifyMultiSig(0)), without requiring cryptographic proof that the caller actually held the private key of the destination to account. A typo in the target public key could permanently brick an account into a blackhole address, and an unverified target opened the door to front-running squatting or delegated migration abuse.

We closed this from both ends in the upgrade:

First, we integrated KERI-style Key Pre-Rotation (nextKeyCommitment) into our DID and account_migrate pipeline [3]. While your account is completely safe, you can generate your next rotation keypair PK2 (which can be kept offline or generated with a post-quantum algorithm) and commit only its hash digest (nextKeyCommitment = Hash(PK2)) into your on-chain account state, without revealing PK2 itself.

Notice what this changes: even though your active key PK1 is exposed on-chain every time you sign a transaction, your next key PK2 stays hidden behind a quantum-resilient hash. If PK1 is ever compromised, the attacker still cannot hijack your account via account_migrate, because the protocol rejects any migration whose target public key does not match the pre-committed nextKeyCommitment (INVALID_PRE_ROTATION_KEY). We also hardened the state transition so each consumed commitment is atomically rotated and recorded, preventing replay across multi-hop migrations.

Second, we replaced single-signature migration with mandatory from + to dual-signature verification (VerifyMultiSigV2). Every account_migrate transaction must now carry valid signatures from both the retiring key and the new target key, proving possession of the new private key on-chain before the state transition commits. In addition, the protocol now explicitly blocks any proxy delegator from initiating or co-signing a migration, and automatically clears all legacy outgoing delegations (delegatedTo) when an account migrates.

2. The 50× Signature Size Bloat: Wire Headroom and Single-Pass Encoding

The second blind spot in "just switch algorithms later" is physical byte size.

Classical elliptic-curve signatures are tiny: an Ed25519 public key is 32 bytes and its signature is 64 bytes (96 bytes combined). Compare that with the post-quantum digital signature standards finalized by NIST in August 2024 [2]:

Even with NIST's primary general-purpose standard, ML-DSA-65 (Dilithium3), a single public key plus signature takes more than 5 KB, over 50 times larger than Ed25519. Put three or four post-quantum signatures into a multi-signature or multi-input transaction, and the signature payload alone reaches 15 KB to 20 KB.

A pipeline hardcoded for 4 KB transactions, or one that re-serializes the entire transaction inside an O(N²) loop for every co-signer, would choke the moment post-quantum keys were enabled.

In our latest upgrade, we cleared those pipeline bottlenecks in advance:

3. Long-Lived Verifiable Credentials and Hash-Based Selective Disclosure

On-chain accounts can rotate keys, but off-chain Verifiable Credentials (VCs), such as identity attestations, licenses, or long-lived permissions, often need to remain verifiable for years. Meanwhile, many schemes marketed as "ZK" in the blockchain industry only use succinct validity proofs for computation compression rather than true zero-knowledge privacy, while introducing heavy pairing-friendly elliptic curves that are equally vulnerable to Shor's algorithm.

To keep credential privacy lightweight and quantum-resilient, our upgrade introduces native Selective Disclosure VCs (SD-VC / SD-JWT) in @arcblock/vc built directly on SHA3-256 salted hash commitments. Holders can selectively reveal individual credential fields by presenting the salted preimage against the SHA3-256 digest without relying on pairing circuits, while ledger checkpoint anchoring preserves a clear timestamp boundary for historical issuer signatures.

To be clear about current production scope: everyday transactions in our wallets and on our chain today still use compact Ed25519, secp256k1, and hardware-backed P-256 Passkey signatures. We have not switched daily user wallets to multi-kilobyte ML-DSA keys today, because browser WebAuthn standards and mobile Secure Enclaves do not yet natively sign with them, and paying a 50× bandwidth multiplier prematurely would degrade everyday user experience for no immediate security gain. What matters is that the identity header, patented migration links, pre-rotation hash commitments, and wire headroom are already in place in the protocol.

Practical Advice for Users Today: Why You Shouldn't Rush to Move Your Wallet

Let's come back to the viral warning telling crypto users: "If your address has ever sent a transaction, its public key is exposed, so move all your assets to a fresh wallet right now!"

That warning starts from a real cryptographic fact (outgoing transactions expose public keys on-chain) and turns it into bad operational advice. You should not panic, and you should not rush to manually move your funds across freshly created wallets today.

Here is why: a quantum computer capable of running Shor's algorithm against 256-bit elliptic curves does not exist today, whereas users losing funds from rushed, manual wallet migrations happens every single day.

Whenever waves of panic push users to hurriedly generate new wallets and sweep balances by hand, the same self-inflicted failures spike immediately: seed phrases written down wrong or lost on a temporary device, assets sent to clipboard-hijacked or lookalike addresses, broken authorization links across dApps, and, worst of all, users falling for fake "Quantum-Safe Wallet Upgrade" phishing sites that drain their accounts on the spot.

Trading a 0% near-term quantum loss probability for a very real human-error and phishing risk today is the wrong trade.

If you want practical security hygiene right now, focus on three things:

When we designed did:abt: with a multi-algorithm header and filed the US11388010B2 account migration patent back in 2019, our goal was to make sure cryptographic evolution would never require tearing up user identities. With KERI pre-rotation commitments (nextKeyCommitment), mandatory from + to dual signatures, and expanded wire headroom now built into our upcoming chain upgrade, that migration path is locked down before the industry needs to walk across it.

When the day actually comes to switch everyday accounts to post-quantum keys, you won't need to notify everyone who holds your address or nervously sweep funds by hand at midnight. You will authorize a protocol-verified account migration in your wallet, and the chain will take care of the rest.

References

[1] Tian Chen, Zhihong Mao (ArcBlock, Inc.): US11388010B2 - Blockchain account migration, filed October 18, 2019, granted by the USPTO on July 12, 2022. See also our publication record Blockchain account migration and engineering walkthrough New keys, old address: where does the next transfer go?.

[2] National Institute of Standards and Technology (NIST): FIPS 204 - Module-Lattice-Based Digital Signature Standard (ML-DSA) and FIPS 205 - Stateless Hash-Based Digital Signature Standard (SLH-DSA), August 2024, specifying post-quantum public key and signature byte sizes.

[3] Samuel M. Smith: Key Event Receipt Infrastructure (KERI), introducing pre-rotation key hash commitments (nextKeyCommitment) to prevent active-key compromise from hijacking rotation authority.

[4] Bitcoin BIP-341: Taproot: SegWit version 1 spending rules (specifying 32-byte tweaked public keys in P2TR outputs) and Ethereum EIP-7702: Set EOA account code (retrofitting programmable validation onto Externally Owned Accounts).