Most discussions about quantum security in crypto seem to focus on wallets and signatures. But I've been reading through @Starknet's migration roadmap, and there's another problem that I hadn't really considered before. What happens to the cryptography already being used inside a blockchain's infrastructure? Changing how users sign transactions is only one part of preparing for future quantum threats. The network itself also relies on cryptographic functions to organize data, identify contracts and verify information. And replacing those functions isn't always straightforward. > Starknet has already changed part of its cryptography In July 2026, Starknet v0.14.3 replaced the Pedersen hash function with a BLAKE2s-256-based construction for its OS program and configuration hashes. This wasn't a testnet experiment or something planned for a future release. The change is already live on mainnet. Pedersen relies on elliptic-curve cryptography, while BLAKE2s is a conventional hash function that doesn't depend on the same mathematical assumptions threatened by Shor's algorithm. I think this is an important example of what preparing for quantum threats actually involves. Not every improvement needs to be visible to someone using a wallet. Some of the most important changes happen in the infrastructure people rarely think about. > But existing smart contracts create another challenge @Starknet still uses Pedersen-based structures in other parts of the network. The roadmap includes changes to contract storage structures and address derivation, but those upgrades aren't live yet. There's also the question of what happens to contracts that already use Pedersen-based storage maps. You can't simply change how data is organized and assume every existing application will continue working exactly as before. StarkWare is researching migration tools for those contracts, but there's no publicly released toolkit or complete developer workflow yet. That's the part I'd like to see progress on. Developers shouldn't have to risk breaking existing applications just because the network needs stronger cryptography. > And there's still the Ethereum dependency Starknet's hash-based STARK proofs already avoid the elliptic-curve assumptions threatened by Shor's algorithm. Its programmable accounts also allow new signature verification methods without requiring a network-wide upgrade. But Starknet remains an Ethereum L2. Its data availability, bridging and messaging still have dependencies on Ethereum's cryptography and migration timeline. That's one reason the team is researching whether an independent L1 could give Starknet more control over future security upgrades. No decision to make that transition has been finalized. For me, preparing for quantum threats is about more than choosing stronger cryptography. It's also about making sure the applications and people already using the network have a safe way to move forward when something needs to change. @Starknet isn't fully quantum-safe today, and there's still work left across different parts of its infrastructure. But seeing an actual protocol change already running on mainnet makes the broader migration roadmap easier to take seriously. I'll be following the remaining storage and contract migration work, especially how developers will be able to make those changes without disrupting existing applications. StarkWare Quantum Hub: https://t.co/veMp2WwDeT #Starknet #PostQuantum #Cryptography #STARK