ADI Post-Quantum Migration: Roadmap, Risks, and Options for Holders

ADI post-quantum migration is becoming an increasingly relevant question as quantum computing advances push the entire blockchain sector toward a cryptographic reckoning. ADI (Accumulate Digital Identifier), the Layer-1 protocol built around human-readable identities, relies on the same elliptic-curve cryptography (ECDSA/Ed25519) used by Bitcoin and Ethereum. This article examines what a genuine post-quantum migration would require for ADI, what the project has publicly communicated about its cryptographic roadmap, and the practical steps holders can take right now to reduce quantum-era exposure.

What Quantum Computing Actually Threatens in ADI

To evaluate ADI's post-quantum posture, it helps to be precise about the threat model rather than treating "quantum" as a vague bogeyman.

The Two Relevant Quantum Algorithms

Shor's Algorithm targets asymmetric cryptography. Given a sufficiently large, error-corrected quantum computer, Shor's can derive a private key from a public key in polynomial time. This breaks ECDSA (used in most EVM-compatible chains), Ed25519 (used by many Layer-1s including Accumulate's signing layer), and RSA. Any wallet whose public key has been exposed on-chain becomes vulnerable.

Grover's Algorithm targets symmetric cryptography and hash functions. It provides a quadratic speedup, effectively halving the security bit-length of SHA-256, Blake3, and similar primitives. The practical mitigation is straightforward: double the output length (e.g., move from SHA-256 to SHA-512). This is a far less urgent problem than Shor's.

For ADI specifically, the Shor's threat is the one that matters. Accumulate's architecture assigns every identity (ADI) its own key hierarchy, with key books and key pages controlling signing authority. Those keys are ECDSA or Ed25519 by default — standard curves that a cryptographically relevant quantum computer (CRQC) could attack.

When Does the Threat Materialise?

Estimates from the National Institute of Standards and Technology (NIST) and leading quantum research labs suggest a CRQC capable of breaking 256-bit elliptic curves remains at least a decade away under most scenarios, though aggressive timelines from some labs put meaningful capability closer to the early 2030s. The practical danger is not simultaneous — an attacker who harvests encrypted or signed data today can decrypt it later once the hardware matures. This "harvest now, decrypt later" (HNDL) attack pattern makes pre-emptive migration prudent even when the threat remains theoretical.

---

Does ADI Have a Public Post-Quantum Migration Plan?

As of the time of writing, Accumulate (ADI) has no publicly documented post-quantum migration roadmap. The project's GitHub repositories, official documentation site, and blog posts do not contain a published plan for transitioning to NIST-approved post-quantum cryptographic (PQC) algorithms. There is no community governance proposal, no forum discussion thread, and no engineering RFC that addresses algorithm agility or lattice-based key replacement.

This is not unusual. The majority of Layer-1 projects, including Ethereum, have acknowledged the long-term quantum threat without publishing concrete migration timelines. Ethereum's core developers have discussed account abstraction as a route to algorithm-agnostic signing, but that work is still in progress. Accumulate's silence on the topic is a data point worth noting, not necessarily a condemnation.

What Accumulate does have, architecturally, is a key management model that is more migration-friendly than many chains.

ADI's Key Hierarchy: A Structural Advantage

ADI's design separates identity (the human-readable name) from the underlying key material. Key books contain key pages, which in turn list signing keys with configurable thresholds. This means that, in principle, swapping out the cryptographic algorithm used for signing keys does not require changing the identity layer itself. The ADI — `alice.acme`, for example — could persist while the keys it references are rotated to a post-quantum scheme.

This is architecturally cleaner than Bitcoin's UTXO model, where quantum-safe migration requires spending all existing UTXOs into new quantum-resistant addresses before a CRQC appears. It is also cleaner than naive EVM account models where the account address is derived directly from the ECDSA public key.

The architectural headroom is real. However, headroom is not a plan. Realising this advantage requires explicit protocol changes, updated signing libraries, and coordinated network upgrades.

---

What a Real ADI Post-Quantum Migration Would Involve

Assuming Accumulate's development team were to pursue a full PQC migration, the work would span several distinct layers.

1. Algorithm Selection

NIST finalised its first set of post-quantum standards in 2024:

For a blockchain signing layer, ML-DSA (Dilithium) and FN-DSA (FALCON) are the primary candidates. FALCON produces smaller signatures but has more complex implementation requirements. Dilithium is simpler and considered safer to implement correctly. The size increase over ECDSA is the most immediate on-chain engineering challenge.

2. Consensus and Validator Upgrades

Accumulate uses Tendermint-based BFT consensus. Validator nodes sign blocks and votes with their own key material. Any PQC migration must address validator signing keys alongside user-facing ADI keys. A phased approach would likely introduce a new key type at the protocol level, allow validators to register PQC keys alongside existing ECDSA keys, then coordinate a hard fork or flag day to deprecate the legacy algorithm.

3. Key Page Updates for ADI Holders

End users holding ADIs would need to rotate their key pages. In Accumulate's architecture this means:

1. Generating a new ML-DSA or FALCON key pair locally.
2. Submitting an `UpdateKeyPage` transaction signed by the current (ECDSA) key, adding the new PQC public key.
3. Optionally removing the ECDSA key once the migration deadline passes.
4. Updating any hardware wallets or signing integrations that interface with the ADI.

Step 3 is the critical window. Until the old key is removed, the account remains dual-signed and partially vulnerable if the ECDSA public key has been exposed on-chain.

4. Wallet and Tooling Support

The Accumulate wallet ecosystem — the browser extension, the Accumulate mobile wallet, and third-party integrations — would all need to implement PQC key generation, storage, and signing. This is non-trivial. FALCON in particular has strict requirements around signature nonce randomness; implementation errors can leak private keys. Standardised, audited libraries (libpqcrystals, liboqs from the Open Quantum Safe project) would need to be integrated.

5. Storage and Throughput Costs

PQC signatures are substantially larger than ECDSA signatures. A Dilithium3 signature is approximately 3,293 bytes versus 64 bytes for an Ed25519 signature. At scale, this increases per-transaction storage requirements and may affect block propagation times. Protocol-level compression or signature aggregation schemes (similar to BLS in Ethereum's beacon chain) would help, but these represent additional engineering work.

---

Interim Risk Reduction Options for ADI Holders

While waiting for any protocol-level PQC migration, holders can take concrete steps to reduce their exposure.

Minimise Public Key Exposure

The quantum threat to ECDSA is specifically against exposed public keys. In Accumulate's model, a key's public key appears on-chain when it signs a transaction. Keys that have never signed a transaction have their public key unexposed (assuming secure key generation). Best practice:

• Use signing keys that have transacted as infrequently as possible for high-value ADIs.
• Rotate key pages regularly so that exposed keys control fewer assets over time.
• Use the threshold and multi-key features of Accumulate's key book system to require multiple signatures, reducing the impact of any single key being compromised.

Multi-Signature Key Books

Accumulate's key book system allows M-of-N signing configurations. Requiring, say, 3-of-5 keys to authorise a transaction means an attacker would need to compromise multiple keys simultaneously, a substantially harder task even with quantum resources. This is not quantum-resistant, but it raises the cost and complexity of an attack.

Diversify Custody

For holders with significant ADI-denominated value, diversifying custody across multiple independent key sets and custody solutions reduces single-point-of-failure risk. Projects like BMIC.ai are building quantum-resistant wallets using lattice-based cryptography aligned with NIST's PQC standards, which illustrates the direction the broader custody industry is moving — holders who want post-quantum assurance today may need to look at purpose-built solutions rather than waiting for legacy chains to migrate.

Monitor the Accumulate Protocol Roadmap

The most actionable step is simply to stay informed. Subscribe to the Accumulate GitHub repository (`accumulatenetwork/accumulate`), follow the official Discord, and monitor the Accumulate Forum for any engineering discussions around algorithm agility or PQC. When a migration proposal does appear, early adopters who understand the key rotation process will be better positioned to act before any deadline.

---

How ADI's Migration Challenge Compares to Other Layer-1s

ADI is not alone in having no public PQC migration plan. The table below reflects the state of public documentation across several major Layer-1 projects as of mid-2025.

Algorand is the notable outlier at scale: its state proof system already incorporates FALCON-512 signatures for cross-chain verification, making it the furthest along among established Layer-1s. ADI's key architecture gives it a cleaner migration path than Bitcoin, but without published engineering intent, that advantage remains theoretical.

---

What to Watch: Signals That ADI Is Moving on PQC

If Accumulate's development team begins addressing post-quantum migration, expect to see these signals in roughly this order:

1. An RFC or governance discussion on the Accumulate Forum or GitHub Discussions about algorithm agility and PQC primitives.
2. A devnet or testnet branch experimenting with Dilithium or FALCON key types in the signing layer.
3. An updated key type enum in the Accumulate protocol specification (the `KeySpecType` definition in the core codebase).
4. Integration into liboqs or libpqcrystals within the Accumulate Go SDK.
5. A formal network upgrade proposal with a transition timeline and key rotation guide for ADI holders.

None of these signals are visible as of this writing. The absence is a risk factor any serious ADI holder should weigh, particularly those with long time horizons.