Almost every blockchain secures its accounts with elliptic curve signatures. A large enough quantum computer running Shor's algorithm could break them. The open question has always been how soon quantum computers will arrive.
The answer keeps shrinking. In 2019, quantum researchers Craig Gidney and Martin Ekerå estimated that breaking RSA-2048 would take a quantum computer with 20 million noisy qubits. In 2025, Gidney cut that to under a million. In March 2026, Google Quantum AI estimated that the 256-bit elliptic curve problem behind most cryptocurrency signatures could fall to a machine with fewer than 500,000 physical qubits, in a matter of minutes.
No one has built that machine yet, and we don't think anyone can say exactly when someone will. We don't need an exact date. The direction is enough, and regulators agree. Executive Order 14412 requires US federal high-value systems to migrate key exchange by 2030 and signatures by 2031. The UK's NCSC expects organizations to finish migrating by 2035.
Blockchains carry an extra burden. A TLS session disappears when it ends. A blockchain keeps public keys and signed history visible forever, so we can't quietly rotate the past. We have to move before the threat arrives, not after.
We're building on newer ground
The cryptography we use today has been tested for about 40 years by the world's best minds trying to break it. It earned our trust the hard way. The new post-quantum schemes are much newer, and they came through a rigorous, years-long public review led by the National Institute of Standards and Technology (NIST). We can and should trust them, but they haven't had decades under pressure yet.
The pressure itself is changing, because AI has started doing serious mathematics. Last year, Google DeepMind's AI found a faster way to do a calculation that no one had improved since 1969. This year, OpenAI went much further. In September, it claimed its AI had solved one of the seven Millennium Prize Problems, a famous list of the hardest open questions in mathematics. Terence Tao, one of the world's leading mathematicians, called it "a remarkable achievement." A month later, OpenAI published more than 700 AI-written papers tackling long-standing unsolved problems. Experts are still checking the work, and some of it is disputed. However, it’s clear that AI is now exploring mathematics at a speed that has stunned mathematicians, and no one knows where it will lead. With standards that keep changing and quantum computing research coming on leaps and bounds, no cryptographic choice is permanent. We have to expect change and build for it.
Separate intent from execution
NIST's crypto agility guidance, CSWP 39, defines agility as the ability to replace and adapt cryptographic algorithms while preserving security and keeping operations running. We think one design idea does most of the work of getting there. Put a layer between what a system wants to do and how it does it.
Intent → policy → algorithm
An application expresses intent: "sign this transaction" or "establish a secure channel." A policy layer decides which scheme satisfies that intent today. The algorithm executes. The application never names Ed25519 or Falcon directly. Once that layer exists, changing algorithms becomes a policy decision rather than a code change across every product that touches a key. Without it, every new standard turns into a rewrite.
Agility first, then cryptography
Most teams start by picking a post-quantum algorithm. We think that's backwards. The order matters more than the choice.
- Build the agility first. Treat algorithms as injectable dependencies. Design key formats, data structures, and operational processes so they can accept schemes you haven't chosen yet.
- Move the cryptography. With the boundaries in place, adopting a new scheme becomes configuration. Hybrid schemes, which pair a classical algorithm with a post-quantum one, fit in here as a sensible transition tactic.
- Prove the boundaries work. Exercise the structure with real post-quantum schemes before you need to. If you've never swapped an algorithm in practice, you're not agile.
- Plan the exit as well as the entry. Adding a scheme is the easy half. Decide up front how you'll retire the old one and how users will move their keys.
How we built Algorand this way
We started early. Since 2022, Algorand has signed State Proofs with Falcon, a compact lattice-based signature scheme selected by NIST. We then put Falcon accounts on Mainnet using LogicSignatures, without a consensus upgrade. In 2026, we added native Falcon accounts as first-class citizens of the blockchain.
Our work so far makes agility a protocol feature. The network supports multiple signature schemes side by side. Our next roadmap steps will prove it, through the addition of more signing schemes, including hybrid accounts that combine Ed25519 with lattice-based keys. Adopting new schemes becomes a routine upgrade. Users keep their accounts and move on their own timeline.
Quantum-resilience is a property you maintain
It's tempting to treat "quantum-resilience" as a box to tick: pick the right algorithm, migrate, done. But today's quantum-resilience describes today's standards, today’s technology and today's mathematics, and all of them will keep moving. Quantum-resilience is a property you maintain. The systems that keep it will be the ones built to change. When the next standard lands, we want adopting it to feel routine, for us and for everyone building on Algorand products.
Disclaimer: The content provided in this blog is for informational and educational purposes only. The information is provided by the Algorand Foundation and while we strive to keep it accurate and current, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the blog or the information contained in it for any purpose. Nothing in this blog is legal, financial, tax, or investment advice, nor an endorsement, guarantee, or investment recommendation. Technical descriptions are provided as of the date of publication and may change. Any statements about future plans, features, integrations, protocol or consensus upgrades, fees, or timelines are forward-looking and subject to change, including subject to community adoption, and are not commitments. You should conduct your own research and consult a qualified professional before acting on any information here; any reliance you place on it is strictly at your own risk. All third-party names and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement.