A Starknet governance poll closed on October 22, 2026, with 93.52% of participating voting power supporting research into an independent, post-quantum layer-1 network. The Foundation’s result announcement stresses that the vote does not approve a transition.
TL;DR: StarkWare and the Starknet Foundation will study the proposal. The percentage measures voting power. A network move would need further approval.
What independence would be intended to address
The initial October 15 proposal frames independence as a way to pursue quantum-resistant security without relying entirely on Ethereum’s migration timetable. It identifies Ethereum-facing connections, including the bridge and data availability, as dependencies in the current layer-2 design.
The proposed direction would retain STRK as the token and preserve bridges to Ethereum. Those are stated intentions for the path being explored, rather than details of an already approved implementation.
The distinction between a research vote and an implementation vote is consequential. Research can test whether the desired security benefit is achievable, identify costs that are not yet understood and compare independence with alternatives. Agreeing to investigate does not establish that one architecture will ultimately be preferable.
For users and developers, continuity questions extend beyond whether a token keeps its name. They include how applications would recognize the new network, how assets would move, which systems would provide settlement assurances and how existing integrations would be maintained.
Quantum readiness involves several separate systems
StarkWare’s migration register, last updated August 19, separates account authorization, proofs, protocol cryptography, existing deployments and Ethereum dependencies. Its assessment shows why quantum readiness cannot be reduced to a single feature.
Programmable accounts can adopt new signature-verification logic, but existing accounts do not automatically change. Wallet support, custody, recovery procedures and adoption remain separate tasks. Likewise, the proving layer’s hash-based design does not remove the need to assess its parameters and implementation.
The register also distinguishes live changes from work still under research. It describes migration tooling for older contract storage as a research effort without a released toolkit, and treats Ethereum bridge and messaging dependencies separately from the proving system.
A complete migration would therefore require coordination across software that users touch directly and infrastructure they rarely see. A technically available signature scheme is only one component; people must also be able to create, store and recover the keys needed to use it.
The joint working group will publish findings for community discussion. Detailed proposals and additional votes would follow if the research supports proceeding. The most useful outcome of this stage is a testable account of the benefits, remaining dependencies and migration work, before a binding architectural choice is made.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply