Who Controls Your Quantum Timeline?

Starknet is forcing an unusually useful question into the quantum-readiness conversation: Who actually controls your cryptographic migration timeline?

The Starknet community recently voted with 93.52% of voting power in favor of researching a possible transition from its current Ethereum Layer 2 architecture toward an independent post-quantum Layer 1. The vote does not authorize the move. It authorizes the research. A separate governance decision would be required before any transition could occur.

But the reason behind the proposal is more important than the vote itself.

Starknet already has several characteristics that make cryptographic migration easier. Its STARK proofs are hash-based, and its programmable accounts can adopt new signature-verification mechanisms without requiring a protocol-wide upgrade. Experimental work has even demonstrated an existing testnet account moving to hybrid ECDSA + Falcon-512 authorization while keeping the same address and funds.

Yet Starknet still depends on Ethereum for critical functions including bridging and data availability. That means Starknet can potentially make parts of itself post-quantum faster than the infrastructure underneath it can move. And that exposes the real issue: You are not quantum ready if someone else controls the clock.

Starknet is the clearest technical signal because it is moving the crypto-agility discussion from algorithms to architecture. Its account model allows cryptographic verification to be changed at the account level. That creates the possibility of replacing a signature mechanism without requiring users to abandon an address, move assets, or wait for a network-wide fork. Starknet describes this as one of the advantages of native account abstraction, although important areas including bridges, settlement, guardians, hardware signers, and other dependencies remain unresolved.

This is not evidence that Starknet is already fully quantum resistant. It is evidence of something arguably more important: the architecture was designed so that cryptography can change.

The second signal comes from an entirely different market.

Yesterday, the Hong Kong Monetary Authority and Hong Kong University of Science and Technology launched a Post-Quantum Cryptography Toolkit for banks. The toolkit calls for governance and accountability, assessment of cryptographic exposure, identification of transition needs, supplier engagement, prioritization, and practical migration timelines.

Hong Kong's starting point is revealing. Its Quantum Preparedness Index, launched earlier this year, gave the banking sector an initial score of only 2.3 out of 10. The stated objective is to move the sector toward full quantum readiness by 2030.

Notice what the HKMA is not doing.

It is not simply telling banks which post-quantum algorithms to use.

• It is asking them to understand dependencies.
• Who supplies the cryptography?
• Where is it embedded?
• What needs to change?
• Which suppliers can support the transition?
• Who owns the work?
• What is the timetable?

Those are governance questions, and they are remarkably similar to the architectural problem Starknet is confronting.

The third signal remains harvest-now, decrypt-later.

The danger does not begin on the day a cryptographically relevant quantum computer appears. Information requiring long confidentiality periods can be collected today. Public keys can remain exposed indefinitely. Legacy systems can survive for years. Vendors can become bottlenecks.

That means migration time matters more than prediction precision. An organization does not need to know exactly when Q-Day arrives. It needs to know whether it can move before its dependencies prevent it from doing so.

We should probably add a new phrase to the quantum-readiness vocabulary:

cryptographic sovereignty.

Cryptographic sovereignty is not about owning your own algorithms. It is the ability to change the cryptographic mechanisms protecting critical systems on a timetable determined by your risk, rather than by the slowest platform, vendor, supplier, protocol, or piece of infrastructure you depend upon.

That distinction matters enormously.

Imagine an organization has completed its cryptographic inventory.

• It knows where RSA and ECC are used.
• It has approved a PQC roadmap.
• Its security team is ready.

Then it discovers that:

• a critical SaaS provider cannot support the new cryptography,
• an identity provider will not migrate for three years,
• a hardware platform cannot accept updated certificates,
• a payment processor has no published roadmap,
• or an embedded system cannot be upgraded at all.

The organization may be internally ready. But it is not operationally sovereign.

Someone else owns the migration clock. That is exactly what makes the Starknet discussion relevant outside blockchain. Starknet's problem is unusually visible because Ethereum is an explicit architectural dependency.

Enterprise dependencies are often less obvious.

They hide inside cloud platforms.

Software libraries.

Certificate authorities.

APIs.

Identity systems.

Managed services.

Payment networks.

Devices.

Suppliers.

And suppliers of suppliers.

This is why QCI-QS1 v2.3 places such emphasis on cryptographic inventory, third-party readiness, migration planning, evidence, and crypto-agility. A quantum-readiness assessment should not simply determine whether an organization knows what needs to change.

It should determine whether the organization actually has the authority and technical ability to change it.

That leads to today's boardroom question:  “Which critical dependency has the power to delay our quantum transition?”

That may be far more revealing than asking whether the organization has selected ML-KEM or ML-DSA. Because the biggest quantum-readiness risk may not be outdated cryptography. It may be discovering that the cryptography cannot be changed until somebody else is ready.

Think Earlier. Trust Must Survive.