Quantum Error Correction (QEC) is the key to unlocking “utility scale” quantum computing – the point at which quantum computers can perform trillions of reliable quantum operations to execute a range of new applications. 

To correct these errors, we need real-time QEC systems that process and correct terabytes of quantum data with high accuracy, low resource utilisation and low latency.

Key takeaways / highlights:
  • Real-time QEC is the bottleneck to utility-scale quantum computing and achieving ultra-low, system-level latency is critical to unlocking trillions of reliable quantum operations.
  • Deltaflow 2 demonstrates leading real-world performance, achieving 16.32µs mean latency on real QPU data, beating Riverlane’s 20µs target and approaching the ~10µs threshold needed for utility scale.
  • This is a major step toward fault-tolerant quantum computing, delivering up to 10× faster sub-shot latency and ~4× lower mean latency than published results, validating real-time QEC on continuous data and accelerating the path to utility-scale systems.

In this post, we’re focusing on low latency and how we achieved this for the second generation of our real-time QEC system, Deltaflow. Low latency is critical for real-time QEC to ensure that Deltaflow can process error data quickly and allow the fast execution of logical circuits.

Using data from Google’s 2024 Nature paper, Quantum error correction below the surface code threshold, Deltaflow 2 demonstrated a mean latency of just 16.32µs during a distance 5 rotated surface code quantum memory experiment. Such latency positions us close to the projected target of 10µs necessary for utility-scale applications [1, 2, 3].

At Riverlane, we set a near-term target of 20µs as we progress toward this 10µs goal. Our experimental results already fall well below that benchmark, demonstrating strong progress even with today’s hardware. Plus, it’s four times lower than Google’s reported latency of 63µs.

We also compared our sub-shot latencies – how long it takes to process and decode a single window (chunk) of an experiment. Our maximum sub-shot latency is over 10x better than Google’s, and we show good stability of sub-shot latencies for all one million rounds across all 10 shots.

Using Deltaflow to outperform Google’s published latency by a wide margin is an exciting result and big step towards fault tolerance at utility scale. However, because latency was not the primary target of Google’s work, the comparison should not be interpreted as strictly like-for-like.

One thing is clear: the latency improvements we achieved are critical for the next step needed to reach utility-scale quantum computing: implementing low latency real-time QEC on a real QPU running real applications.

To fully understand the impact of this result and how it was achieved, let’s first take a deep dive into how we measure latency and why it’s an important metric to track.

The experiment: Testing Deltaflow 2 with real-world data

We used data from Google’s 2024 Willow experiment where they executed ten shots (repetitions) of a quantum memory experiment using the distance 5 (d5) rotated surface code, for one million QEC rounds.

The aim was to show that they can keep a single logical qubit alive for a long time by continuously decoding and tracking the errors in it. We took this raw readout data (the qubit measurements for every round in a d5 quantum memory experiment) and passed it to Deltaflow.

To achieve this, we used our QPU and control system emulator, which allows us to send any readout data to Deltaflow, via QECi, without needing to have an actual control system or QPU connected. We formatted all the readout data according to the QECi Specification, sent it to Deltaflow, processed it, decoded it, sent back the result and measured the latency. We also measured sub-shot latency to compare with Google.

The results: real QPU data over one million rounds

We define the following:

  1. Latency: the time it takes for a QEC system to issue an error-corrected result after being sent all relevant measurements.
  2. Mean latency: the mean latency across all shots (i.e. across the 10 shots for the Google dataset).
  1. Sub-shot latency: the time it takes for a QEC system to complete processing a chunk of data (window) after being sent all relevant measurements for that window.

First, let’s look at the subshot latency. Our results demonstrate that Deltaflow 2’s subshot latency variance remains stable over a long period of time, with the peaks in the chart well below 100µs. The moving average over 250 windows hovers around 16µs.

The peaks in the chart occur when noise on the QPU in a given round is harder to decode. Therefore, sub-shot latency spikes; this behavior is normal and expected.

Note: the graph below is for a single shot, hence it doesn’t mask any peaks in the subshot latency by taking an average.

Also, our maximum sub-shot latency is over 10 x better than Google’s, demonstrating remarkable stability across one million rounds. This stability is paramount for reliable, continuous quantum operations.

Now, let’s plot these results as latency versus experiment duration (number of rounds).

The dark green points are the subshot latency at that point in time, and the purple points are the final latency for each one of the 10 shots. The distribution of all cumulative subshot latencies up to that point in time is shown in orange. The distribution of the 10 sampled subshot latencies at that point in time is shown in green.

Deltaflow 2 achieved an impressive 16.32µs mean latency, with a standard deviation of 8.28µs. Google’s reported net average over varying number of QEC rounds was 63µs ± 17µs. This means our mean latency is nearly four times lower.

How does Deltaflow 2 achieve this?

These results are a testament to Riverlane’s focus on realising real-time QEC. Deltaflow 2, our real-time QEC system, incorporates several innovative features:

  • Local Clustering Decoder (LCD): This proprietary hardware solution, implemented on FPGAs, is engineered for both high accuracy and high speed. It can reduce the number of physical qubits required for a logical qubit by a factor of four under a leakage-dominated noise model, while decoding in under 1µs per round.
  • Proprietary windowing scheme: Deltaflow 2 utilizes a technique where we can efficiently split up the decoding graph and decode it continuously (in a streaming fashion) rather than waiting for the entire computation to finish. This allows continuous error correction and helps prevent a data backlog.
  • Data routing and processing logic: Our system is designed to process incoming data from any QPU and any control system, regardless of how data is aggregated and how the qubits are read out (via a camera, multiplexed readout lines, etc.) Even with such flexibility, our data processing and readout pipeline ensures that all data reaches the decoder in the right format at the right time to guarantee continuous low-latency QEC.

Compared to Google we decoded using an FPGA, which we expect to be faster than Google’s software decoder. Our definitions of latency appear to be different as well where we consider the latency of the entire QEC system.

These results demonstrate that Deltaflow performs exceptionally on a continuous stream of real QEC data, delivering a low latency, validating our hardware-first architecture and reassuring current and prospective partners.

This proves Deltaflow 2 can support real QEC loops at low latency on real hardware, making this a meaningful step toward utility-scale quantum computing.

Why does low latency matter?

QEC uses many noisy qubits to encode a smaller number of high-fidelity logical qubits. Real-time QEC systems, like Deltaflow, need to continuously process a stream of qubit measurements when conducting long running experiments. By ‘long running’ we mean around 100,000 to one million rounds of the QEC cycle to run a quantum memory experiment (where, essentially, we are trying to keep the qubit alive forever).

The QEC system derives syndromes (data indicating the presence of error events) from the qubit readout data and inputs this into the decoder. This allows the QEC system to track the logical errors and issue corrections, if necessary. This is a massive data management issue where we need to keep the QEC cycle running with high accuracy and low latency. 

So, why do we care about low latency?

Let’s look at an example. Below, we’re doing a magic state teleportation experiment, where we entangle two logical qubits by performing an operation between them, then we measure one of them. Based on the error-corrected measurement of this logical qubit (the bottom one in the diagram), we either perform or do not perform a logical gate (marked S in the diagram). This measurement outcome depends on a correction from a QEC system, and thus how long this correction takes to be issued (marked τ in the diagram) determines the logical clock speed of the system.

This is an example of a crucial operation for utility-scale quantum computing: which cannot be performed on a classical computer. It also demonstrates why we need low latency – because the faster we can issue this result back to perform the S gate (the lower τ is), the faster we can complete this logical operation and hence the more operations per unit of time the quantum computer can execute.

Low latency is crucial for:

  • Fast logical clock rates: The faster the QEC system responds, the faster logical operations can be executed. This directly impacts the overall speed of quantum algorithms. For example, researchers have shown that factoring 2048-bit RSA integers could take 8 hours with a 10µs decoding response time, but a 100µs response time would slow it down by more than sixfold.
  • Enabling complex operations: Non-Clifford gates are essential for universal (and useful) quantum computing, and they cannot be executed unless we have low latency. If our latency is too long, we cannot execute many non-Clifford gates and, hence, you can do less computation with your quantum computer.
  • Efficient resource utilization: Faster processing means less time spent on computation, leading to lower power consumption and operational costs for the system.

So, what does latency mean for a QEC system? Here’s an overview of Deltaflow 2, Riverlane’s real-time FPGA-based QEC system.

Beyond decoding syndromes, this system needs to route and process all incoming data at the rate at which it is generated. This is a huge data processing requirement. The system also needs to issue real-time feedback to a control system so that any corrections can be acted upon accordingly. 

We define a standard, external latency measure to compare how different experiments and QEC systems affect performance in scalable, quantum computers. 

Given a way of sending measurements to a QEC system and receiving decoding results, latency (or response time) is defined as the time elapsed from when the last chunk of data is sent to a QEC system to the control system receiving an error-corrected result from the QEC system.  

This captures all overheads associated with connecting a control system to a QEC system, including those introduced by the communication protocol (e.g. our Quantum Error Correction interface (QECi)) and any processing of data done outside running the actual decoding algorithm. 

Looking ahead: Deltaflow 3 and beyond on the Riverlane QEC Technology Roadmap

These Deltaflow 2 results are a foundational achievement, marking a successful completion of the “Quantum Memory” phase (Phase 1) of our QEC Technology Roadmap. This phase established robust quantum memory and enabled initial logical operations.

The journey continues later this year when Deltaflow 3 will be launched. Building on Deltaflow 2’s capabilities, Deltaflow 3 will focus on:

  • Fast logic by lattice surgery: Performing error-corrected logical gates efficiently.
  • Higher error suppression rates: Further improving the reliability of quantum operations.

Ultimately, our roadmap aims to reach TeraQuOp utility scale by 2033+, where quantum computers can perform a trillion reliable operations. These latest results underscore that Riverlane is not only making consistent progress but also accelerating the timeline towards this transformative future.

Click here to download Riverlane’s roadmap and whitepaper to learn how we’ll get there, helping to accelerate quantum computing’s path to utility scale by 3-5 years.

  1. https://arxiv.org/abs/2505.15917
  2. https://arxiv.org/abs/1905.09749
  3. https://arxiv.org/pdf/2602.11457
  4. https://arxiv.org/pdf/2209.08552