The Post-Quantum Migration Gap: Adding a New Key Doesn’t Retire the Old One
The Post-Quantum Migration Gap: Adding a New Key Doesn’t Retire the Old One
What building Residual for NEAR HACKATHON 2026 taught us about measuring cryptographic transitions.
A network can introduce post-quantum signatures without making every existing account post-quantum secure.
That distinction is nuanced. It becomes surprisingly easy to lose when security upgrades are announced, new cryptographic algorithms are supported, and adoption starts being measured.
The problem is that introducing a new capability and retiring an old dependency are different operations.
NEAR’s introduction of ML-DSA-65 transaction signatures provides a concrete example.
A post-quantum key can coexist with a classical key
NEP-645 adds ML-DSA-65 as an additional transaction-signature scheme alongside Ed25519 and secp256k1.
For existing accounts, adopting a post-quantum access key does not automatically remove their classical access keys. Both may remain available to authorize transactions.
Consider an account with one Ed25519 full-access key.
The account holder adds an ML-DSA-65 full-access key. The account can now authorize transactions using a quantum-resistant signature scheme.
But if the Ed25519 key remains active, the older authorization path also remains available.
The account has adopted post-quantum cryptography. It has not retired its classical full-access authority.
This matters because the security properties of an authorization system depend on all available authorization paths, not merely its strongest supported algorithm.
The difference between adoption and migration
Suppose a dashboard reports that an account has adopted post-quantum keys.
What does that actually tell us?
It establishes that a post-quantum key is present. It does not establish that classical full-access keys are absent.
To measure this distinction, we need at least two separate indicators:
Post-quantum adoption: Is an ML-DSA-65 access key present?
Observed full-access-key transition: Does the account have a post-quantum full-access key without retaining a classical full-access key at the observed block?
The second measure is narrower, but substantially more informative about which authorization paths remain available.
Even then, it is not a complete quantum-security assessment. Smart contracts, recovery arrangements, external signers, validator infrastructure and other dependencies may have their own security assumptions.
The objective is not to reduce everything to one reassuring number. It is to measure precisely what the available evidence can establish.
Introducing Residual
I built Residual, an open-source, read-only post-quantum migration observatory, for NEAR HACKATHON 2026.
Residual examines NEAR account access keys at a pinned finalized block and separates five observed conditions:
- Classical full-access authority only.
- Mixed post-quantum and classical full-access authority.
- Post-quantum full-access authority with no observed classical full-access key.
- Post-quantum function-call authority without full-access keys.
- Undetermined configurations or observations.
The fifth state is important.
An unavailable RPC response, an unsupported key type or an account with only classical function-call keys should not be quietly interpreted as successful migration.
Residual keeps such observations visible and reports why they could not be classified into a definitive full-access migration state.
Measuring NEAR directly
Residual uses NEAR JSON-RPC to retrieve account-access-key information. It pins observations to one finalized block, identifies key types and permissions, and generates account-level classifications.
Get Arifa Khan’s stories in your inbox
Join Medium for free to get updates from this writer.
NEAR represents ML-DSA-65 access keys through compact hash handles in access-key listings. Residual recognizes this representation separately from classical Ed25519 and secp256k1 keys.
The project includes a Python scanner, an interactive browser application, deterministic signer-window sampling, JSON reports and a static dashboard.
I also developed a Lean 4 model describing the classifier’s central rules, alongside a 128-case truth table used for implementation checks.
The formal model verifies properties of the classification logic. It does not prove that an RPC provider is truthful or that the entire account is quantum-secure.
What we observed on mainnet
One recorded NEAR mainnet scan examined five accounts selected from 14 distinct transaction signers observed across three blocks.
The scan was pinned to block 224577581.
All five account-access-key reads succeeded. All five sampled accounts retained classical full-access authority, and none had an ML-DSA-65 key observed.
These results are useful as a working demonstration of evidence collection and classification. They are not evidence that post-quantum adoption across NEAR is zero.
Five recently active signers are not representative of every account on the network. The sample is too small for broad conclusions.
That distinction is part of the product’s design: every reported result should carry its denominator, sampling method, block provenance and unresolved observations.
Why incomplete evidence matters
During development, I encountered another practical issue: public RPC endpoints sometimes returned rate-limit errors.
An early scan returned all accounts as undetermined because their access-key queries failed.
A less careful monitoring system could have shown zero post-quantum keys and allowed a reader to mistake that for zero adoption.
Residual instead preserves the failed observations, reports the error and refuses to interpret a completely unresolved sample as a valid adoption measurement.
The browser implementation was subsequently improved with request pacing and alternative RPC providers.
This illustrates a general rule for security analytics: missing evidence must not be mistaken for evidence of absence.
From prototype to infrastructure
Residual is intentionally read-only. It does not request wallet access, hold private keys, sign transactions or change account permissions.
Its immediate use cases include account holders checking their observed access-key state, wallet teams making cryptographic migration more understandable, custodians monitoring account inventories, and researchers studying the rollout of new signature schemes.
A longer-term product could offer periodic migration assessments for defined account populations, historical change tracking and alerts when classical full-access authority remains present.
For institutional users, the commercially valuable feature may be less about counting post-quantum keys and more about producing clear evidence of what has and has not transitioned.
A broader lesson for cryptographic upgrades
The distinction extends beyond NEAR.
During a cryptographic transition, it is possible to deploy a stronger algorithm while retaining older keys, protocols, administrative paths or recovery mechanisms.
An upgrade may improve available capabilities before it changes the weakest remaining authorization path.
This suggests a more useful question for measuring migration:
Not simply “Is the new cryptography supported?” but “Which old authorization paths are still usable?”
Residual is an early, narrowly scoped attempt to answer that question using observable NEAR account-access-key state.
It does not solve every aspect of post-quantum migration. It makes one important part of the transition measurable, reproducible and open to scrutiny.
Try Residual: https://agentzeta.github.io/residual-near/
Source code: https://github.com/agentzeta/residual-near
Technical reference: NEP-645 — ML-DSA-65 Post-Quantum Transaction Signatures, https://github.com/near/NEPs/blob/master/neps/nep-0645.md
Residual was developed for NEAR HACKATHON 2026 with AI-assisted coding and independent review of the underlying product concept, classification model and implementation decisions.
Post-Quantum Cryptography, Blockchain, Cybersecurity, NEAR Protocol, Open Source
