We recently announced our roadmap for Libra: 256 logical qubits on more than 10,000 physical qubits, a megaquop system planned for 2028, with a gigaquop system following in 2028/29.

Three orders of magnitude inside about a year deserves a word of explanation. A gigaquop machine runs a thousand times more reliable operations than a megaquop one, but it is not a thousand times the machine: the next-generation system is 1,000+ logical qubits on more than 20,000 physical qubits, roughly four times the logical width. The rest of the factor comes from logical fidelity, 99.9999% to 99.9999999%. Once a machine is fault-tolerant, buying three more orders of magnitude in logical error rate is a matter of QEC code and architecture design, and those are an architecture and software problem as much as a hardware one.

A fault-tolerant neutral-atom computer is not a bigger version of the machine we run today. It is a distributed, real-time system in which quantum operations, atom movement, measurement, decoding, loss handling, and classical decisions all happen at once and all depend on each other. If the hardware is going to be useful the day it arrives, the software has to be ready for it before then.

That is what we are turning Bloqade into: one stack to program, compile, emulate, verify, and operate a fault-tolerant neutral-atom computer. This post is how we see the challenges and how we envision the stack we want to build.

What changes at fault-tolerant scale?

We recently laid out our roadmap for Libra: 256 logical qubits on more than 10,000 physical qubits, a megaquop-scale, fault-tolerant system planned for 2028, with a gigaquop machine to follow in 2028/29. Getting the hardware there is only half the challenge. The other half, the one that decides whether that hardware is actually usable the day it arrives, is software.

A fault-tolerant neutral-atom computer isn't just a bigger version of the systems we run today. It's a real-time, distributed system in which quantum operations, atom movement, measurement, error decoding, and classical decision-making all happen at once, all depending on each other. Our engineering and research teams have written a deep, technical post on Bloqade, our open-source SDK, about exactly what that means for the software stack we're building, and why. Here's what you need to know.

Atom movement becomes part of the program, not just a routing trick. One of the biggest advantages of neutral atoms is that we can physically move them during a computation to create connections wherever we need them. At fault-tolerant scale, some of those movement decisions can only be made in real time, based on measurements happening as the program runs. That means movement can no longer be hidden away inside a compiler; it has to become something the software actively reasons about while the machine is running.

The machine becomes asynchronous. Loading fresh atoms, decoding errors, detecting atom loss, and producing the special "magic states" used for certain quantum operations all run on their own independent timelines, each able to succeed, fail, wait, or be consumed by another part of the computation. Anyone who has written concurrent classical software knows how quickly that kind of complexity can spiral. The fix is the same one classical engineers have always relied on: build the ability to reason about events, timing, and failure directly into the languages, compilers, and runtime.

More is different. Libra will run more than 10,000 physical qubits carrying 256 logical qubits, a scale at which no fault-tolerant quantum software stack, ours included, has yet operated. At that size, quantum programs stop looking like simple static circuits. They get wider, run longer, and expose far more parallelism, which means compiling and verifying them takes real co-design with the underlying hardware architecture.

The stack we're building

Our answer is to turn Bloqade into one continuous stack, covering everything from writing applications, down to compiling, emulating, verifying, and ultimately operating a fault-tolerant neutral-atom machine. Two pieces of that effort stand out:

• A digital twin at every level of abstraction. Faithfully emulating this kind of machine takes more than a circuit simulator: it means modeling the quantum operations, the control system, the optics, and the decoding runtime as one integrated system, because that's what they are on real hardware. Our recent release, the Pauli Propagation Virtual Machine (PPVM), is the first concrete step toward that circuit-level digital twin.
• Compiler and architecture co-design. For our Gemini-class testbed, we introduced a "lane architecture," where atom movement is planned together with the error-correcting code layout from the very start, much like designing a chip. It's a deliberate trade-off: a smaller, pre-calibrated set of atom moves in exchange for higher reliability per move. Our early data suggests that trade pays off more often than not, and we're continuing to test where the line falls.

Building in the open

None of these problems belong to one company. That's why we're co-organizing the first Workshop on Compilation, Emulation and Verification of Neutral Atom Computing (CEVNAC 2026), alongside IEEE Quantum Week in Toronto, bringing together hardware researchers, compiler and language developers, verification experts, and application scientists to work through these challenges together.

The bigger picture

Fault-tolerant neutral-atom computers will be dynamic, living systems: atoms in motion, resources produced and consumed on the fly, errors decoded continuously, and classical logic steering the computation as it happens. Building the software that can keep all of that manageable is exactly what will determine how quickly Libra, and the machines beyond it, turn into something people can actually use.

Want the full technical picture, including how we're modeling atom movement trade-offs, what our digital twin architecture looks like layer by layer, and the early data behind our lane architecture? Read the complete deep dive on the Bloqade blog: Building the Software Stack for Fault-Tolerant Neutral Atom Computers.