Starknet Upgrades Blockchain Cryptography Against Quantum Threats
ENJ
-2.97%
HBD
+31.31%
NMR
-0.53%
AMP
-0.56%
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. The upgrade is live on mainnet, not a testnet experiment.

The swap itself is small. What it shows is not: preparing a blockchain for quantum threats means rewriting its cryptographic foundation layer by layer, and Starknet is only partway through.

Most quantum risk discussion centers on wallets and signatures. Shor’s algorithm threatens the elliptic curve cryptography (ECC) widely used in blockchain for authorizing transactions through schemes such as ECDSA and Schnorr/EdDSA. But a network also relies on cryptography internally, to organize data, identify contracts, and verify information. Pedersen is built on elliptic curves. BLAKE2s is a conventional hash function that does not rest on the mathematical assumptions Shor’s algorithm breaks. The OS layer Starknet just patched has nothing to do with signing. It is infrastructure.

Contracts Built on Pedersen Storage Maps

Pedersen-based structures still exist elsewhere in the network, and that includes existing contracts whose storage maps depend on it. Developers cannot simply flip a switch and expect every application to keep working.

StarkWare’s published roadmap says the team is researching migration tooling for those contracts, but no toolkit has been released. The tension is plain: upgrade the network’s cryptography, or risk breaking apps already running on it. Starknet is targeting full post-quantum security by 2027, and hitting that date requires a migration path that does not strand existing users.

Ethereum Brings Its Own Exposure

Starknet’s hash-based STARK proofs already avoid the elliptic-curve assumptions Shor’s algorithm threatens. As an Ethereum L2, though, it still has to deal with KZG commitments for blob data availability, plus Ethereum dependencies such as bridging and messaging. These remain exploratory areas with no defined migration timeline.

That is one reason the team is researching whether an independent L1 would give Starknet more control over future security upgrades. StarkWare floated the idea on October 8, 2026. A non-binding vote closed on October 22, and 93.52% of voting power backed researching it. No binding decision has been made.

Native account abstraction lets a new account implementation use programmable validation, but existing accounts, wallets, custody, keys, and user adoption each need their own migration work.

Hashlytics Take

Starknet is not quantum-safe today, and it does not claim to be. Its advantage is that the work is visible and shipping, while most chains have not started. Some researchers warn cryptographically relevant quantum machines could arrive before 2030, which makes that head start worth something.

The hash swap was the tractable part, because StarkWare controls the OS program. The 2027 target hinges on the parts it does not fully control: thousands of deployed contracts with no migration tooling yet, and Ethereum dependencies with no timeline. The L1 vote shows the team knows this. The date will be decided by whether developers get a safe upgrade path, not by how much code StarkWare ships.

Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates

ⓘ Disclaimer: Content displayed above are for informational purposes only and do not constitute financial, investment, or trading advice.