Starknet and the Question of an Independent L1: Who Decides When Security Upgrades Are Needed? Cryptography is not permanent. Standards become obsolete, new research emerges, and the foundational assumptions upon which a network is built may be challenged by unforeseen discoveries. @Starknet Therefore, the critical question is not whether a network can predict such moments, but whether it can respond in time when they arrive. Starknet currently settles on Ethereum, which offers several practical advantages. However, it also means that certain aspects of Starknet’s security are tied to Ethereum’s own roadmap. According to the StarkWare Quantum Hub, these dependencies primarily involve three areas: •Ethereum controls KZG, the commitment scheme used for blob data. •Starknet can utilize either blobs or, as a fallback, calldata. •Changes to bridging and messaging mechanisms are dependent on Ethereum’s own evolution. This brings us to the core issue: timing. When a critical security upgrade is required, who decides when it should take place? An independent L1 would place that decision-making authority closer to Starknet itself a direction Starknet is currently exploring. Regarding the level of readiness, the Hub provides a clear breakdown: •Already live on mainnet: BLAKE2s-based hashing for the OS program and configuration (introduced in Starknet v0.14.3). •Demonstrated on mainnet: OpenZeppelin accounts utilizing Falcon 512. •Roadmap-defined (not yet implemented): modifications to the contract trie and address generation methods. @Starknet •In the research phase: tools for migrating legacy Pedersen storage maps. It should be emphasized that this remains an exploration, not a finished product. Starknet is preparing for quantum threats; it does not claim to be quantum-secure, and nothing here predicts when such threats might emerge.