Qblox and Riverlane close the real-time QEC loop: 6.886 µs on Surface-17, 11.886 µs on Surface-161, from syndrome detection to correction over LINQ and QECi.
Every stage of this demonstration ran on physical hardware, using emulated qubit measurement data rather than syndrome data. Round-trip latency is the time from syndrome extraction, reading out the error signals from the qubits, to conditional correction, the full detect-and-correct cycle, including readout integration time. It's the ceiling on how fast a quantum processor can run a QEC code. Qblox Cluster modules handled the readout and control, turning that raw measurement data into the syndrome word, the same task they'd perform on real qubit output. The Riverlane Deltaflow 2 QEC system then processed the resulting syndrome data across all four code distances tested.
Key takeaways
- Qblox and Riverlane have closed a full real-time quantum error correction (QEC) loop, , from syndrome extraction (reading out qubit errors) through to conditional correction (applying the fix). Demonstration used emulated qubit measurement data, not live qubit output.
- The integration connects the Qblox Cluster to the Riverlane Deltaflow 2 QEC system over QECi, the open control-to-decoder interface standard.
- Total round-trip latency scales from 6.886 µs on Surface-17 (code distance 3) to 11.886 µs on Surface-161 (code distance 9), with every measured configuration inside the 20 µs near-term total round-trip latency target. Read more here.
- Qblox's contribution to round-trip latency stays nearly flat as code distance increases, rising by only 106 ns (from 1.114 µs to 1.220 µs) as physical qubit count grows nearly tenfold, from Surface-17 to Surface-161. Decoder-side gains pass straight through to the full loop.
- The integration runs over QECi, the open control-to-decoder standard, and supports the full specification. Nothing in the implementation is tied to a single code, decoder configuration, or workflow.
What is real-time quantum error correction?
Real-time quantum error correction (QEC) detects and corrects errors on a quantum processor while a computation is still running. A processor running a QEC code produces a continuous stream of syndrome measurement data, and that stream must be decoded at a rate that matches the QEC cycle time. If decoding falls behind the cycle rate, the backlog of syndrome data grows exponentially and the logical computation slows exponentially with it.
Closing this loop takes two things working together: a decoder fast enough to keep pace with the hardware, and a control system that transports syndrome data to the decoder and returns corrections with deterministic, bounded latency.
Riverlane provides the QEC system, featuring a decoder. Qblox provides the control system.
How does the Qblox and Riverlane integration work?
The integration rests on QECi, the open standard developed by Riverlane that defines the data format, runtime states, and communication protocol between a quantum control system and an external decoder. Qblox control electronics are QECi compatible, which allows the Qblox Cluster to deliver real-time qubit measurement data for large numbers of qubits to any QECi-compliant decoder, while Qblox focuses on its core strengths: low-latency data orchestration and qubit control.
The complete feedback pathway runs from the qubit readout and control sequencers in Qblox modules, through deterministic syndrome transport across the Cluster via LINQ, to the Deltaflow 2 QEC system. Once the syndromes are decoded, the correction returns to the drive sequencers, which execute the conditional correction pulses.
Within a single Cluster, the Qblox contribution to the round-trip latency grows only marginally with the number of qubits controlled, and is bounded by a fixed per-Cluster maximum. This preserves the available latency budget for decoder processing as code distance increases, a behaviour confirmed up to code distance 9 (Surface-161) in this demonstration, and the architecture is designed to maintain this behaviour across multiple linked Clusters as well.
Inside the demonstration: Rotated planar surface code over LINQ
The rotated planar surface code served as the baseline benchmark, instantiated at code distance 3 as Surface-17 (9 data qubits and 8 auxiliary qubits). Qblox and Riverlane then ran the same workflow at code distances 3, 5, 7, and 9 (Surface-17, Surface-49, Surface-97, and Surface-161).
Running this workflow over LINQ engages three capabilities at once: multi-module all-to-all routing to aggregate syndrome bits from multiple QRM-RF, QRM and QRC modules, LINQ write-combine to construct the unified syndrome word, and the QECi decoder interface for the correction decision.
Each cycle proceeds in five steps:
1. All 8 auxiliary qubits (Surface-17, code distance 3) are read out simultaneously by their respective Qblox Cluster Q1 sequencers.
2. Readout results are written to the LINQ fabric in parallel and aggregated into an 8-bit syndrome word.
3. The syndrome word is wrapped in QECi packet format and forwarded to the Riverlane Deltaflow 2 QEC system over the QECi PHY.
Qblox and Riverlane ran this loop across 50,000 QEC cycles, with Deltaflow 2 decoding continuously as new syndrome words arrived. That volume matters: it demonstrates Deltaflow 2 keeping pace with the syndrome generation rate over a sustained run, not just a single successful pass. Only when a correction is actually needed do the final two steps complete the loop:
4. The decoder returns the correction outcome, which is routed to the appropriate data qubit drive sequencers.
5. Correction pulses are dispatched conditionally by the receiving Q1ASM programs, completing the cycle.
The throughput requirement is modest by design: 8 bits at a 1 µs cycle rate equals 8 Mb/s, more than two orders of magnitude below the Cluster's 2 Gb/s throughput ceiling. That headroom is exactly why Qblox builds for scale: even beyond the code distance 9 tested here, the same architecture has the throughput margin to absorb higher code distances, simultaneous active reset, and additional experimental overhead without ever hitting a data backlog. In this demonstration, that headroom means throughput isn't the binding constraint; the QECi decoder round trip is.
What do the real-time QEC latency results show?
Qblox and Riverlane measured total QEC round-trip latency, including readout integration time, across Surface-17, Surface-49, Surface-97, and Surface-161, then decomposed each result into the Qblox system contribution and the Deltaflow 2 QEC systemcontribution.
Real-Time QEC Latency vs Code Distance. Stacked bars show total round-trip latency at four code distances: 6.886 µs at Surface-17 (code distance 3), 7.816 µs at Surface-49 (code distance 5), 9.866 µs at Surface-97 (code distance 7), and 11.886 µs at Surface-161 (code distance 9). Each bar splits into Qblox system latency (bottom, teal) and Deltaflow 2 QEC system latency (top, dark green).
All four configurations sit within the 20 µs near-term total round-trip latency target, including the Surface-161 case (code distance 9). This reflects where real-time decoders realistically stand today. Read more here.
Two results stand out.
The Qblox system latency stays a small, stable fraction of the total budget at every code distance. Qblox system latency moves from 1.114 µs at Surface-17 (code distance 3) to just 1.220 µs at Surface-161 (code distance 9), an increase of only 106 ns as the qubit count grows from 17 to 161. Hardware overhead stays effectively flat at these system sizes, so the observed latency growth is attributable entirely to the decoder, as expected, since it processes a larger syndrome word at each successive code distance. The Qblox Cluster's distributed LINQ architecture keeps its own contribution deterministic as both code distance and physical qubit count increase. That stability reflects LINQ's cluster-wide feedback loop under 650 ns.
The Surface-17 result shows what that stability delivers in practice. The latest Deltaflow 2 update reduced round-trip latency from 8.308 µs to 6.886 µs, an improvement of roughly 17 %. That gain passed directly through to the total round-trip latency, because the control layer added no additional overhead. Decoder-side optimisation translates one-to-one into system-level gains.
Why does this matter for fault-tolerant quantum computing?
Real-time QEC is a defining engineering hurdle for the quantum computing industry. Scaling fault tolerance to millions of physical qubits has suffered from a latency and throughput bottleneck between error detection and correction. This demonstration, verified up to code distance 9 (161 qubits), shows that bottleneck can be addressed by integrating Qblox low-latency, high-throughput control electronics directly with the Deltaflow 2 QEC system.
Two design decisions underpin the result.
The first is decoupling. Separating hardware latency from decoder latency means gains on either side pass through to the full feedback loop without requiring changes on the other. Deterministic, low-latency syndrome transport is a necessary but not sufficient condition for scalable QEC, and this decoupling is the correct design response for systems operating at increasing code distance.
The second is flexibility. Nothing in the implementation is hardcoded. It supports the full QECi specification rather than a narrow subset, so the same setup works across different codes, decoders and workflows rather than being locked to one. The architecture can adapt as decoding strategies evolve.
Want to see real-time QEC running on your architecture?
Qblox works with partners across the quantum ecosystem to close the feedback loop between detection and correction. Get in contact with the Qblox team to discuss your QEC roadmap and explore Riverlane’s QECi standard.
Frequently asked questions
What is QECi? QECi is an open standard developed by Riverlane that defines the data format, runtime states, and communication protocol between a quantum control system and an external quantum error correction decoder. Any QECi compliant decoder can receive real-time measurement data from QECi-compatible control electronics such as the Qblox Cluster.
What round-trip latency did the integration achieve? At code distance 3 on the Surface-17 code, the total round-trip latency, measured from syndrome extraction to conditional correction and inclusive of readout integration time, was 6.886 µs with the latest Deltaflow 2 update. At Surface-161 (code distance 9), the round-trip latency completed in 11.886 µs. All measured configurations sit within the 20 µs near-term total round-trip latency target. Qblox's own contribution held nearly flat throughout, rising from 1.114 µs to 1.220 µs across the full range of code distances tested. Read more here.
Why is decoding speed the binding constraint rather than data throughput? Because the Cluster is built with throughput headroom rather than for one fast qubit alone: the syndrome data rate at Surface-17 (code distance 3) is 8 Mb/s, more than two orders of magnitude below the Cluster's 2 Gb/s throughput ceiling. That headroom is what prevents a data-congestion backlog as code distance increases. With throughput accounted for, the remaining constraint in this demonstration is the decoder round-trip latency: if decoding falls behind the QEC cycle rate, the volume of pending syndrome data grows exponentially and the logical computation fails.
Is the integration limited to the surface code? No. The Qblox implementation supports the full QECi specification and is not tied to a single error-correction code, decoder configuration, or workflow. The demonstrated workflow spanned Surface-17 through Surface-161 (code distances 3 through 9), but the same architecture can run multiple codes as decoding strategies evolve.
What roles do Qblox and Riverlane play in Project SKYTALE?Riverlane leads the project and provides the Deltaflow 2 QEC system, built around decoders capable of correcting millions of errors per second. Qblox is the control electronics partner, providing the Cluster that closes the loop: deterministic transport of syndromes to the decoder and conditional correction at the drive level.
About the collaboration: Project SKYTALE
Project SKYTALE is a Horizon Europe EIC Transition project led by Riverlane, supported by a £2.1 million grant funded through the Horizon Europe guarantee and backed by the UK Department for Science, Innovation and Technology. Riverlane was the only UK company selected for the European Innovation Council (EIC) Transition grant, one of 27 winners across Europe.
The project funds the next generation of Riverlane's quantum error correction decoder, with the goal of enabling real-time decoding of quantum operations. Within SKYTALE, Qblox is the control electronics partner, contributing deterministic, low-latency qubit control and data orchestration for large-scale quantum processors.
Qblox is accelerating the quantum revolution as the global leader in scalable quantum control. The company provides the control electronics that empowers researchers and engineers to build high-performance, robust, and scalable systems. Trusted by industrial and academic leaders worldwide, Qblox sets the standard for quantum control and delivers the backbone for a new era of computing.
Riverlane is the world leader in quantum error correction (QEC), the technology that unlocks quantum computing’s promise of a new age of human progress. The company partners with over 60% of the world’s quantum computer companies and leading high-performance computing (HPC) centres to solve the error problem blocking their path to ‘utility-scale’ systems that can transform multiple industries.