Starknet

Post-quantum consensus signatures: a perspective from validation

7 min readAug 13, 2026

Press enter or click to view image in full size

A few weeks ago, a wallet on Starknet made a real transfer signed with Falcon-512, a signature scheme that no quantum computer, nor one much more powerful than those that exist today, can forge. It cost about six cents, the account is experimental and unaudited, and the transaction was recorded on the public mainnet.

Why it matters: The cryptography that protects virtually all wallets today (Bitcoin, Ethereum, most L2s) is based on elliptic curves, and elliptic curves are exactly what a sufficiently powerful quantum computer can break. This transfer is proof that an alternative, one that doesn’t rely on this cryptography, already exists in production. But it’s just the most visible piece of a longer story: why Starknet was able to do this without a fork or forced migration, how well the rest of the roadmap is actually resolved, and what remains to be built in the least visible piece of all, the consensus that underpins the network.

Quantum risk is already active, even though the hardware doesn’t yet exist.

The quantum vulnerability of a blockchain doesn’t begin the day a quantum computer capable of breaking elliptic curves exists. It begins earlier, under the model known as “ harvest now, decrypt later”: an attacker can archive encrypted on-chain data today and decrypt it as soon as the hardware is available. The relevant question isn’t when that hardware will arrive, but how much migration work a network will have to do before then.

Every blockchain has two independent exposure layers. The account layer: the signature that authorizes each transaction. And the verification layer: the proof system that ensures the chain’s state is valid. Bitcoin and Ethereum have elliptic curves hardwired into both. Most zk-rollups do too, because they build their SNARKs on elliptic curves. Solving only one of the two layers doesn’t solve the problem.

Why Starknet starts from a different point

At the verification layer, Starknet runs on STARKs : tests based on hash functions, not elliptic curves. There is no known quantum attack against a hash function; the best available, Grover’s algorithm, only speeds up brute force, and this is offset by increasing the hash size. This is a structural property of the testing system, present since the original design, years before it was a topic of discussion in the industry.

At the account layer, each account in Starknet is a smart contract: no signature scheme is fixed in the protocol; each account decides what it accepts based on its own logic. This is what made the transfer possible without a hard fork, without coordinated migration, and without a change of address.

The story no one has told: the true cost of Falcon-512

Here’s something that didn’t make the headlines, but it’s worth mentioning. Verifying a signature within a Starknet contract isn’t free: every transaction has a cost on the network, and the more complex the signature, the more expensive it is to verify. With Falcon-512, that cost was, until relatively recently, a real and unresolved problem.

In July 2025, almost a year before the official roadmap, a community developer suggested a way to reduce that cost on the Starknet public forum. A StarkWare researcher responded honestly: it wasn’t enough. One of the internal operations required by Falcon-512 was still too resource-intensive, so close to the limit of what a contract could support that it wasn’t even clear if it was practically feasible. It was an open technical discussion, with no guarantee that it would work.

A year later, it works. The Falcon-512 implementation running on the mainnet today solved that problem: verifying a signature costs significantly less than other comparable alternatives already used by many wallets, and it fits comfortably within the limits of a Starknet contract. It’s the same signature that made the six-cent transfer possible, the one we mentioned at the beginning of this article. The important thing isn’t just that it works today, but that the entire process, from the initial doubt to the solution, happened publicly, on the Starknet forum, long before anyone mentioned it in the media.

The roadmap and its actual state, surface by surface.

StarkWare’s post-quantum roadmap, published on June 30, outlines three phases: securing new activity, providing migration tools for existing contracts, and finally resolving shared dependencies with Ethereum. Starknet maintains a public progress log (quantum.starkware.co) with the actual status of each surface, which should be cited precisely rather than assuming everything is resolved.

Already up and running on the mainnet. Starknet changed one of the internal mathematical functions it uses to seal the network state to a quantum-resistant version (in technical jargon: it replaced Pedersen with BLAKE2s-256 in the system configuration hashes).

Get Cumulo’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Announced, but not yet active. The same type of change applies to the structure that stores data for each contract and to how account addresses are calculated. We know what will be done and how, but it’s not yet deployed in production.

Currently under investigation, with no date or publicly available tool yet. The challenge lies in how to migrate existing contracts that store their information using the old method. This is the most delicate part, as it affects what is already deployed and in use, and StarkWare has not yet published a concrete plan for how to do it without breaking anything.

Outside of Starknet’s direct control. Some of the network’s data is published on Ethereum, and that data still uses a cryptography that Ethereum hasn’t yet updated (the mechanism is called KZG). The same applies to the bridge between the two networks. Here, Starknet relies on Ethereum’s timeline, not just its own.

The piece that almost no one is connecting: decentralized consensus and validation

Almost all the public discussion surrounding this roadmap has focused on the Falcon-512 account. But there’s a detail that’s rarely mentioned alongside the announcement: Starknet’s official decentralization roadmap places post-quantum cryptography in the same phase, Phase 4, currently underway, as Staking v3 (decentralized block validation) and Staking v4 (fully decentralized consensus and network operation). This isn’t a coincidence: StarkWare has explicitly indicated post-quantum consensus signatures, with Falcon-512 as a candidate, intended for the moment when validation will no longer depend on StarkWare and will instead be handled by a set of independent validators.

That’s the part that directly concerns us as validators, and where the problem shifts from “Does my wallet accept another signature?” to “Which signature will the node software that each validator operates have to support, how far in advance will there be a public specification, and will there be a real testnet window before it becomes mandatory on the mainnet?” These are infrastructure questions, not UX questions, and we prefer to raise them now, in the research phase, just as the cost of Falcon-512 was raised and resolved in the forum a year ago, and not when decentralized validation is already in production.

From Cumulo

We have been operating non-custodial validation infrastructure on various networks, including Starknet, for over five years, using our own open-source tools for monitoring and deployment. This is precisely the type of protocol decision we prefer to pursue from the public research phase, with concrete data, not from the announcement stage. As soon as a consensus signature scheme is available on the testnet, we offer to test it, openly document the process, and share the findings with the community, as we always do.

In blockchain, validators are the engine that makes it possible, and the community is the fuel that keeps that engine running.

Sources:

StarkWare, “The Architecture Advantage: Starknet’s Quantum Readiness Roadmap” (June 30, 2026), the official roadmap announcement, with the three phases and their estimated timelines: https://starkware.co/blog/the-architecture-advantage-starknets-quantum-readiness-roadmap/
StarkWare, “Quantum security for everyone: the StarkWare Quantum Hub is now live” (July 30, 2026), hub launch and link to the transaction on X: https://starkware.co/blog/quantum-hub/
StarkWare Post-Quantum Migration Tracking Dashboard: https://quantum.starkware.co/
Starknet’s Decentralization Roadmap (last updated March 22, 2026) places post-quantum cryptography in Phase 4, alongside Staking v3 and v4: https://www.starknet.io/roadmap/
SNIP-32 thread in the Starknet forum, “Expose Keccak-f[1600] Permutation Syscall” (July 2025): https://community.starknet.io/t/snip-32-expose-keccak-f-1600-permutation-syscall/115770
s2morrow, demo and deployment of the Falcon-512 in Cairo, with gas and compression figures: https://www.s2morrow.xyz/ and https://github.com/feltroidprime/s2morrow
StarkWare, “Starknet’s Quantum Edge: STARKs and Native Account Abstraction” (20 de julio de 2026): https://starkware.co/blog/starknets-quantum-edge-starks-and-native-account-abstraction/