Starknet’s Quantum Test Includes the Accounts That Never Move

Analysis | October 16, 2026.

A network can show a rising upgrade count while its hardest ownership questions remain unanswered. For Starknet, a useful quantum-readiness test would ask how much consequential authority remains outside the transition, including accounts whose owners never return. That is a proposed way to judge progress, not a claim that the network has already measured or solved the problem.

Count exposure, not upgrades

Starknet accounts use programmable validation. OpenZeppelin’s repository distinguishes STARK proofs from quantum-vulnerable ECDSA account signatures.

We would therefore evaluate migration with several denominators. Count participating owners, value under the new controls, and consequential permissions covered. Keep those figures separate. A thousand upgraded accounts could be commercially encouraging yet tell little about a remaining account empowered to change a major application. Conversely, one inactive account with a negligible balance should not erase progress elsewhere.

This approach also avoids treating yesterday’s activity as a complete map of tomorrow’s exposure. A quiet account can still matter because of what it is allowed to do.

Dormancy creates a governance choice

Consider a hypothetical owner who misses every migration notice. Leaving the account accessible under its old rules protects continuity. Restricting those rules could reduce a future attack surface but also obstruct the rightful owner. Introducing an exceptional recovery route creates a third burden: deciding which evidence establishes ownership when the old credential is no longer sufficient.

These are different distributions of risk, not interchangeable technical fixes. A credible proposal should specify who may authorize an exception, whether decisions can be appealed, and who bears a mistaken decision’s cost. Silence should not automatically be interpreted as consent, abandonment or successful migration.

For this reason, we would publish dormant-account policy before setting a completion deadline. A deadline without a policy merely moves the unresolved ownership dispute to a more stressful date.

A standard is not a cutover plan

NIST finalized the ML-DSA and SLH-DSA signature standards in August 2024. OpenZeppelin labels its Falcon-512 account work experimental and unaudited.

Our procurement question is what an operator must demonstrate before broad deployment. We would require a rehearsal with ordinary users, a failed-upgrade scenario, a funded support process and a record of unresolved exceptions. Success should include the user understanding the new arrangement, rather than merely completing a transaction once.

Cost reporting should likewise distinguish the expense of a single cryptographic operation from the cost of moving a population. Outreach, repeated attempts and exception handling may determine the latter. Subsidizing early adopters alone could make the headline adoption rate look better while leaving the most expensive cases behind.

Budget for open commitments

StarkWare’s October 13 review labels legacy-storage tooling as research and identifies an Ethereum data-availability dependency.

For an infrastructure decision, we would ask for a costed transition plan with named decision owners. The plan should identify the people, operating budget and evidence needed to deliver the promised outcome. In our proposed scorecard, work without an owner or funding would remain an open commitment, rather than count as completed migration.

The useful endpoint is therefore a bounded statement: which assets and authorities are covered, which exceptions remain, and what can still fail. A migration can make genuine progress without declaring every account safe. The accounts that never move deserve their own policy, their own cost estimate and an honest place in that statement.