Roadmap

What is Starknet’s post-quantum roadmap?

Starknet is targeting full post-quantum security in 2027. This page sets out what is already live, what remains, and the research into whether Starknet should move to its own post-quantum L1. The work is preparation for the future: no quantum computer today can break the cryptography Starknet uses.

The 2027 target

What is the 2027 target?

Full post-quantum security in 2027 means every component Starknet relies on has moved off quantum-vulnerable cryptography. Starknet’s proving layer was designed this way from the start, and protocol changes are already live on mainnet. The remaining work covers accounts, existing contracts and dependencies Starknet currently shares with Ethereum.

ComponentStatusWhat remainsRecord
STARK provingLive in productionSecurity still depends on the chosen hashes, parameters and implementationProofs
OS program and configuration hashes (v0.14.3)Live on mainnetNoneProtocol
Contracts trie and contract-address derivationPublished roadmap directionNot yet live; storage-map key derivation and tooling are separate workProtocol
Post-quantum accountsDemonstrated on mainnetWallet support, key management, audits and adoptionAccounts
Migration tooling for existing contractsResearch announcedNo public specification or toolkit yetExisting deployments
Bridge, messaging and data availabilityExternal dependencyDepends on Ethereum’s migration while Starknet settles on Ethereum. A move to Starknet’s own L1, now under research, would put this under Starknet’s control. L1 research Ethereum-facing

Original roadmap (30 June 2026)

L1 research

Will Starknet move to its own L1?

Starknet is researching whether to move to its own post-quantum L1, which would put its remaining post-quantum upgrades under Starknet’s control rather than Ethereum’s timeline. In October’s non-binding governance poll, 93.52% of voting power backed the research. A joint research group from StarkWare and the Starknet Foundation is preparing a white paper as the next step. No decision has been made; any move to an L1 will go to a binding community vote.

Next steps

What happens next?

The joint research group’s white paper is the next step. Any move to an L1 would then go to a binding community vote. This page will be updated at each step.

For now

What does not change yet?

Starknet continues to run on Ethereum while the research proceeds, and its bridge, messaging and data availability still depend on Ethereum. Existing accounts do not change automatically: account owners choose when to adopt a post-quantum account, once wallets support it. The migration register tracks the current status of each component.

Migration register

Current status by migration surface

Post-quantum migration spans account authorization, proof-system assumptions, protocol cryptography, existing deployments and dependencies inherited from Ethereum. Live changes, demonstrations, roadmap work and external dependencies carry different labels.

Each component has its own status. The order does not show maturity or sequence.How do networks compare on cryptographic agility?

Five migration surfaces

Public-source register

Accounts

Structural propertyNative account abstraction

What is true today

Programmable account validation lets a new account implementation adopt a post-quantum signature verifier without a breaking protocol change.

What remains

Existing accounts do not change automatically. Wallet support, signing, key management, recovery, custody, audits and adoption remain separate work.

Who can change it

Account developers choose validation logic. Wallet and custody teams decide whether to integrate it.

Public evidence

Proofs

Structural propertySTARK proving assumptions

What is true today

The Starknet proving layer was designed for post-quantum security without relying on elliptic-curve hardness assumptions.

What remains

This advantage is limited to the proving layer. Security still depends on the chosen hashes, parameters and implementation.

Who can change it

StarkWare develops the proving system. Protocol-level changes adopted by Starknet are subject to governance.

Public evidence

No component-level evidence record is published for this surface yet.

Starknet protocol cryptography

What is true today

Starknet v0.14.3 replaced Pedersen with a BLAKE2s-256-based construction for the OS program and configuration hashes. The change is live on Mainnet.

What remains

The trie and contract-address changes are published direction, not live. Storage-map key derivation and tooling remain separate work.

Who can change it

StarkWare engineering develops these changes. Protocol activation is subject to Starknet governance.

Public evidence

Existing deployments and migration

What is true today

StarkWare's published roadmap says its team is researching migration tooling for existing contracts that use Pedersen-based storage maps.

What remains

There is no public specification, implementation, released toolkit or developer workflow yet.

Who can change it

StarkWare is researching the tooling. Contract teams would decide whether to use any resulting migration path.

Public evidence

Ethereum-facing dependencies

What is true today

Under normal conditions, Starknet publishes state diffs to Ethereum as EIP-4844 blobs. This path uses Ethereum's KZG scheme. Calldata remains available.

What remains

KZG is one inherited dependency. Bridge and messaging remain separate Ethereum-facing dependencies.

Who can change it

Ethereum controls KZG. Starknet can use blobs or its calldata fallback. Bridge and messaging changes depend on Ethereum's migration.

Public evidence

Last updated: 3 November 2026.

Accounts surface opened