DQEC: the big roadblock

3rd of September 2026

For the past few months I've been looking at the main theoretical and software bottlenecks for deploying Distributed Quantum Computing. Distributed Quantum Error Correction (or DQEC) is one of the big ones. Let's dive into the state of the art by the end of the summer of 2026.

← Back to all posts

Why DQEC is different

Error correction is THE problem to solve for quantum computing. Every other subfield (compilers, cost reduction, algorithms) is downstream of whether we can keep a logical qubit alive long enough to trust its output. I touched on EC briefly as one of the "cost reduction strategies" in this post, but now I want to discuss it in a bit more depth.

The main differentiator between plain old (monolithic) EC and DQEC is the presence of communication channels (the network that interconnects the different devices). Each time these channels are used, for instance to enable a non-local gate (a gate performed across multiple QPUs, consuming entanglement), we introduce new errors that emerge from the network hardware. As if dealing with noisy computers wasn't enough we now have to also deal with noisy networks...

Monolithic EC is designed to withstand a level of stable noise (think of it as max X% of errors). It enables this through error correction codes that work by setting out a series of "checks" during the computation that monitor whether things are going according to plan. If one of the checks fails, the computation is corrected. But if too many fail then the error might fall through the cracks and become a "logical error", meaning it was not error corrected. Meaning new large injections of errors codes are not built to deal with are going to be problematic.

There are quite a few different error correction codes one can implement. Some popular ones include:

Surface codes: arrange qubits on a 2D grid and check parity through nearest-neighbour plaquettes. They are very local & tileable, which is why they're the current darling of the field.

Quantum LDPC codes: give up that strict locality for sparse, longer-range connections between qubits, which leads to better ratios of logical to physical qubits, at the cost of a much harder connectivity in hardware.

Colour codes: sit on a three-colourable lattice and get transversal Clifford gates for "free" (at the price of higher-weight checks).

Floquet codes: don't hold a fixed set of stabilizers. The logical qubits are generated dynamically, by cycling through a repeating schedule of very small measurements. Floquet codes were the most popular ones in DQC for a little while, in no small part due to Nu Quantum's research on them (see Sutcliffe et al.). They were/are popular because they enable small cross-plaquette checks meaning low required communication, and thus reduced load on the distributed architecture, aka less network noise injections.

There are many questions we can ask ourselves when thinking of DQEC:

Do you spread a single code across your entire network of devices, or does each device carry its own local code?

In the second setup, how do you turn a non-local gate, one that spans two QPUs, into a logical gate on top of a code that was never designed with a network link in mind?

This is basically the global-vs-local question I wrote about here, applied to error correction instead of circuit optimisation or mitigation.

Also where does the decoder live?

In a monolithic device, syndrome extraction is a tight fast local loop. You measure your stabilizers, ship the syndrome to a classical decoder sitting right next to the fridge, and get a correction back before the errors compound. But when you distribute, the syndrome bits for a check may have to physically travel through a larger network before anyone can decode them. We encounter network latency! The classical network stops being free... and suddenly times can start mattering.

Global QPU 1 QPU 2 QPU 3 one code, indifferent to device lines Local QPU 1 QPU 2 QPU 3 ? ? own code per device — non-local gates?
Fig. 1 — the global-vs-local question: one code stretched over the whole network with no regard for QPU boundaries, versus every device running its own code and the open question of what a gate crossing the gap even means.

A narrow literature

Interest in DQEC has grown a lot over the past eighteen months, to the point that it feels like something of a race between certain groups (at DQC's modest scale ofc). Trying to sort what's out there, it falls into roughly three piles.

1) Smear an existing code across QPUs and measure the damage

The distributed colour code paper takes the (6.6.6) colour code, splits it into patches living on different QPUs, and models the qubits along the boundary between patches (the "seam") as noisier than the ones in the bulk. Then it goes looking for the threshold under that asymmetry, with a tensor-network decoder and a concatenated MWPM one.

On the qLDPC side, Chandra, Kaur, Nejabati and Seshadreesan distribute a [[144,12,12]] bivariate bicycle code across 4, 6 and 12 processors wired in a star topology through shared Bell pairs, and report pseudo-threshold behaviour under circuit-level noise with BP+OSD. Worth noting that two of those authors are at Cisco, which lines up neatly with the IBM & Cisco announcement I gossiped about last year.

2) Cost out the logical operation itself

Stack, Wang and Mueller run circuit-level simulations of two distributed primitives, a transversal non-local CNOT and logical teleportation, on both surface and bivariate bicycle codes. Their headline is that distributed qLDPC transversal operations can beat surface code lattice surgery. The non-local CNOT gets up to an order of magnitude lower logical error rate than teleportation at the same code distance and noise level, while burning fewer Bell pairs. If that holds, it's a fairly big deal for anyone building a compiler: the primitive you pick for your non-local gate is not a wash.

3) Design codes that actually want to be distributed

Sutcliffe, Jonnadula, Le Gall, Moylett and Westoby presented hyperbolic Floquet codes. Hyperbolic structure buys you a high logical qubit density, and weight-two measurements mean one Bell state per check. The non-planar connectivity these codes want, which a monolithic chip hates, is something a quantum network hands you for free.

Elsewhere in the same pile, permutation-invariant approximate codes are being pitched for cutting down interconnect utilisation and handling correlated errors better. There's also work on fault-tolerant memories over a 2×L array of modules, which treats the modular layout as the starting assumption rather than the damage.

My view

The good news is that the "one QPU equals one qubit" framing is losing popularity, and more and more code families are being seriously explored for DQC.

BUT, like I said: every single one of these results rests on a noise model that somebody chose. Noisy injections into an unprotected computation are straightforwardly detrimental, and they more often than not are not directly considered. In the long term we'll need either:

  1. A) Confirmation that EC codes built for monolithic devices can stand up to communication noise, or
  2. B) If they can't, codes designed to.

A: EC will work just fine

The single most encouraging result I know of here is Ramette, Sinclair, Breuckmann and Vuletić. They connected two surface code patches across a deliberately awful interface and find that the system tolerates 14 times higher noise at the interface than in the bulk, with only a small effect on threshold and sub-threshold behaviour: roughly 1% bulk errors against 10% interface errors. They concluded that fault-tolerant scaling of modular devices is within reach with existing technology! Which is awesome!

But, my dear reader, we're still talking about one interface, between two patches, with the surface code, under a chosen noise model. A real network is many interfaces, heterogeneous ones, with EPR pairs that arrive late and degraded rather than simply "noisy", and with the decoder latency problem I mentioned above sitting on top. One thing is sending down a photon from an excited state decaying naturally. Another is translating superconducting qubits into photonic ones through an interconnect.

B: DQEC codes must be purpose built

I am no EC expert, but I do think there's real hope in B. Mainly due to biased codes:

Bias-tailored codes are codes restructured to exploit the fact that real hardware doesn't produce X and Z errors in equal measure. The XZZX surface code is the famous one: under infinitely biased noise its threshold goes to roughly 50%, against 10.9% for the standard surface code. The same trick has been generalised to other codes.

Communication noise is structured noise. A link that loses photons, or a transducer that fails in a characteristic direction, does not hand us a lopsided channel. Meaning, it hands us a bias-tailoring we can exploit! Whether the specific asymmetry a network link produces is one that existing bias-tailored families can be pointed at is an open question. But it's one the community is looking at: Abouamer, Gundersen, Rasmussen and Popovski punch holes in the code itself, using punctured QEC variants that adapt on the fly to whatever entanglement quality purification actually delivers.

And, as always: testbeds!

Both A and B are stuck. You cannot validate a threshold against a noise model nobody has measured. I'll spare you my usual cry and inform you of a potentially cool new development:

The EPB Quantum Center in Chattanooga is putting an IonQ Forte Enterprise inside the footprint of the EPB Quantum Network. As far as I can tell that makes it the first commercial facility in the US offering access to both a quantum computer and a quantum network in the same place! One machine on one network is not yet the two-computationally-relevant-nodes setup that would let us calibrate DQEC noise models, and I'd love to be told I'm wrong about that. But it's a door opening, one that perhaps will lead to experimental DQEC soon!

Until then, resource-estimating the alternative, the world where B turns out to be unnecessary and A holds up fine, remains a healthy and growing cottage industry.

Ripple effects

Now, reality is, these codes are going to reshape instruction sets. Which can work to our advantage. Heuristics love structure, and what is DQC infrastructure today but a set of heuristics bolted onto one another?

Right now a partitioner is handed a hypergraph and told to find a cheap cut (see my overview on hypergraph partitioning for DQC). But if the computation is going to be encoded in, say, a structured code laid out across a known network topology, then you may already know which cuts are not worth checking. The code may dictate which groups of physical qubits must be together, and where the seams are allowed to fall. A cut that slices through the middle of a code block may be deemed "illegal". Thus collapsing the partitioner's search space from "all edges". The objective for partitioning may stop being raw cut size and become something like seam-weight: how much syndrome traffic does this partition force across the link, and can the decoder keep up with it. Partitioners could then be biased toward a specific code family, trained on the cut patterns that code actually admits. I think that could cut down partitioning time and improve resource allocation quite substantially.

Any edge is fair game cost = every edge it happens to cross The code decides the seams ✕ seam illegal — slices a code block cost = only seam edges count
Fig. 2 — the partitioner's search space before and after the code has a say. On the left, any edge is a candidate and the cut just slices wherever it lands. On the right, the code has already grouped qubits into blocks: the seam edges (green) are the only legal cut, and a cut through the middle of a block is illegal, not just expensive.

The decoder side has already started moving too. There's work on parallel QEC decoding for distributed settings, which is the natural response to the latency problem: if the syndrome has to travel anyway, decode what you can locally and reconcile. Which, delightfully, is just distributed systems. We've been here before, we have literature, we know how this goes.

References

AI warning

The figures in this blog post were made with AI to help with visualisation.