Analysis of Quantinuum Helios, a 98‑Qubit Trapped‑Ion Quantum Computer

Introduction

In November 2025, Quantinuum unveiled Helios, a new 98-qubit quantum processor that pushes the frontier of quantum computing with a novel trapped-ion architecture. It also published an accompanying paper on arXiv “Helios: A 98-qubit trapped-ion quantum computer.“

Helios is based on the quantum charge-coupled device (QCCD) design, meaning it physically moves ion qubits around on a chip like an information bus, rather than relying on fixed wiring. This approach enables all-to-all qubit interactions in a way analogous to routing data between CPU and memory in classical systems.

Helios introduces multiple innovations: it uses barium-137 ions for qubits (a first in quantum computing), separates qubit storage from logic operations on the chip, and features a new classical control stack capable of real-time dynamic compilation of quantum programs.

Helios Architecture: Qubits on the Move

At its core, Helios is a trapped-ion QCCD quantum computer: ions (charged atoms) are held in an electromagnetic trap on a chip and shuttled between regions for different operations. Helios’s trap is a 2D surface electrode chip about 15 mm in length. Qubits are individual ions of ¹³⁷Ba⁺ (barium), confined and manipulated by precise electrode voltages and laser beams. Unlike static architectures (e.g. superconducting qubits fixed on a circuit board), Helios can physically transport ions to wherever interactions are needed, much like a quantum bus. This mobility underpins Helios’s quantum charge-coupled device paradigm, allowing it to implement memory zones, data buses, and logic processors specialized for their roles.

Spatial Separation of Memory and Logic

Helios’s layout deliberately separates where qubits are stored from where gates (logic operations) are applied. Think of a classical CPU separating RAM from the ALU (arithmetic logic unit) – Helios similarly has dedicated memory regions for holding qubits and dedicated quantum logic regions for performing gates. Qubits in memory are parked in stable configurations with minimal control, while qubits in the logic zone are actively manipulated by laser pulses to execute gates.

This separation minimizes interference and allows each zone to be optimized: the logic zones have tight-focused lasers and low-noise electrodes for high-fidelity operations, whereas the memory zones can use simpler control since only storage (and occasional cooling) happens there.

QCCD Transport Network

To move qubits between memory and logic, Helios uses a network of electrode “tracks” on the chip. It features a four-way X-junction at the center – a crossroads that connects multiple trap branches. From the junction, two arms lead to the upper and lower quantum logic regions (where gate operations occur), and another path forms a ring-shaped storage loop that circles around, acting as a random-access memory for qubits. By adjusting electrode voltages, ions can be shuttled through this junction either into a logic region or kept circulating in the ring memory.

Memory, Cache, and Operation Zones

Helios organizes its 98 ions across different functional areas. Most ions reside in the large ring storage region – a loop that can rotate ions clockwise or counterclockwise to reposition any particular qubit to the junction on demand. This gives Helios random access to qubits, much like disk storage in a classical system where data can be brought to the processor when needed. When a set of qubits is needed for computation, they are moved from the ring into a smaller “cache” region near the junction. The cache acts as a buffer holding the next batch of qubits about to enter the logic area. From the cache, ions enter the two quantum logic legs (upper and lower in the device) where actual gate operations happen.

Within each logic leg are operation zones – specific trapping sites equipped with laser beams and detectors to perform qubit operations. Helios has 8 high-fidelity operation zones in total (4 per leg), each capable of single-qubit rotations, two-qubit entangling gates, qubit measurement, and even local ion cooling. Each zone can hold one ion pair at a time for two-qubit gates or a small ion crystal for multi-ion operations. Helios can process up to 16 qubits at once in a single “batch” – that is, all 8 zones engaged simultaneously with 2 qubits in each. This means, for example, it can execute 8 two-qubit gates in parallel across the device, a significant degree of concurrency for a quantum computer. (For two-qubit gates, Helios actually merges ions into four-ion crystals spanning adjacent zones and uses a clever two-step procedure to apply gates in 4 zones then the other 4, as explained later.) After operations, the ions can be shuttled back out to memory or on to the next stage.

Transport Mechanisms

Moving ions around the chip is a delicate process: electrodes create moving potential wells that carry ions without disrupting their quantum states. Helios implements a variety of transport operations – shifting ions along a line, splitting or merging chains of ions, rotating the ring, and passing junctions. For example, to bring two qubits together for a gate, Helios might split two ions out of a chain, transport them through the junction into a logic zone, and then merge them into one trap region to perform a two-qubit gate. After the gate, they can be split apart and returned. All of this is orchestrated by precise control sequences. Crucially, Helios’s architecture allows many of these steps to happen in parallel. While one batch of qubits is undergoing gates in the logic zones, the system can simultaneously be sorting the next batch of qubits through the junction into the cache, and even cooling them in advance. This pipelining keeps the processor busy and improves throughput.

In essence, Helios functions like a miniature quantum data center on a chip: ions (qubits) flow from long-term storage (ring memory) into a cache and then into processing units (operation zones) for computation, then back out to memory. This design is a major evolution of trapped-ion technology, achieving scale (nearly 100 qubits) while preserving the hallmark all-to-all connectivity of ion traps – any qubit can eventually interact with any other by moving ions around.

Barium Qubits and Novel Laser Architecture

One of Helios’s most noteworthy choices is its use of ¹³⁷Ba⁺ (barium) ions as qubits, instead of the ytterbium or calcium ions more commonly seen in past ion-trap systems. In fact, Helios is the first quantum computer to utilize 137-Ba⁺ ions. Each barium ion encodes a qubit in two hyperfine levels of its ground electronic state (specifically, the |F=1, m_F=0⟩ and |F=2, m_F=0⟩ states). These two states form an excellent qubit: they are a “clock transition” immune to first-order magnetic field fluctuations, which makes them very stable (minimizing dephasing errors).

Why the switch to barium? Barium offers several practical advantages that improve performance and scalability:

• Higher Fidelity Operations: Helios achieved lower error rates in part because of the barium qubit’s properties. The team reports that using barium helped reach improved gate fidelities compared to the ytterbium ions used in earlier Quantinuum machines. Barium ions have optical transitions at accessible wavelengths (green and red light) which facilitate high-precision lasers. In Helios, a combination of 493 nm, 614 nm, 650 nm, and 1762 nm laser light is used to manipulate and read out the qubits. These wavelengths are in the visible/IR range – easier to produce and control with high precision (narrow linewidth) than the deep ultraviolet 369 nm needed for Yb⁺ qubits. The 1762 nm infrared laser, for example, is used for optical pumping of the barium qubit and is locked to a high-quality cavity for stability. The net result is extremely low error rates in state preparation and single-qubit rotations, as we’ll see in the performance section.
• More Scalable Laser Delivery: Barium’s convenient transition wavelengths mean the optical setup can be more scalable. Earlier ion systems with ytterbium often require multiple high-power UV lasers, which are challenging to distribute to many zones. Helios instead uses a shared laser architecture – the same laser beams are time-multiplexed across multiple operation zones. For example, one set of Raman beams for two-qubit gates can be steered to different zones in sequence. The use of Ba⁺ and carefully angled beams (tilted ~1° to only hit one zone at a time) allowed Quantinuum to supply 8 zones with the needed laser pulses without building 8 entirely separate laser systems. This shared laser multi-zone design is more feasible with barium’s wavelengths and was key to scaling Helios’s parallelism.
• Sympathetic Cooling with Ytterbium: Interestingly, Helios still takes advantage of ytterbium ions – but not as qubits. It co-traps ¹⁷¹Yb⁺ ions as “refrigerants” for sympathetic cooling. After intensive operations, ions heat up (their vibrational modes gain energy), which can reduce gate fidelity. Helios periodically cools the qubits mid-circuit by pairing each ¹³⁷Ba⁺ qubit ion with one or two ¹⁷¹Yb⁺ ions and laser-cooling the Yb (which in turn cools the Ba via Coulomb coupling). Yb⁺ is ideal for this because it has a convenient cooling transition at 369.4 nm and a similar mass to Ba⁺ (ensuring efficient energy transfer). Using Yb ions for cooling allows Helios to keep the Ba qubits in their stable clock states during cooling cycles, avoiding decoherence. This two-species approach is a known technique in ion traps, but Helios demonstrates it at scale with automated, parallel cooling in multiple zones. The result is that even with nearly 100 qubits, Helios can maintain them near the motional ground state as needed, without human intervention, by interleaving cooling operations between gates.

In summary, the choice of barium qubits (with a little help from ytterbium helpers) is a major reason Helios achieves record-setting fidelities. It represents a more advanced ion species for quantum computing – offering long qubit coherence, fast optical transitions for gates, and easier integration of multi-zone laser setups. For CISOs, this technical detail translates to a more stable and controllable quantum system, reducing errors that could otherwise slow the march toward larger, reliable quantum computers.

What’s New in Helios: Advances over H1 and H2

Helios is the latest in a line of trapped-ion machines from Quantinuum (formerly Honeywell’s quantum division). To appreciate its significance, it’s useful to compare Helios with its predecessors, known as H1 and H2. In just a few years, Quantinuum’s QCCD prototypes have grown from a handful of qubits to nearly 100, with leaps in design efficiency. Helios introduces several major architectural advances over the H1/H2 systems:

• New Ion Species: Earlier Quantinuum systems (H1, H2) used ytterbium-171 ion qubits. Helios uses barium-137 ions, which leads to better gate and measurement error rates and a “more scalable laser architecture” than Yb-based QPUs. This switch improved the fidelity of operations and simplified scaling up the number of zones (thanks to the shared laser scheme discussed). It’s an uncommon choice that paid off in performance.
• X-Junction and Enhanced Connectivity: Helios incorporates a four-way “X” junction in the trap, enabling efficient routing of ions between multiple memory and logic zones. The previous generation H2 device (described in 2023 as a “race-track” architecture) had a more linear loop for shuttling ions. Helios’s X-junction connects to a rotating ring memory, effectively providing all-to-all connectivity among 98 qubits without requiring more control signals or complex fabrication than H2. In other words, Helios scaled up connectivity architecturally rather than by brute force. Qubits can be sent to either of two processor legs or kept in memory as needed, giving the scheduler tremendous flexibility.
• Parallel Operations and More Zones: The H1 machine (c. 2020) demonstrated the basic QCCD concept with 6–10 qubits, but only a couple of gating zones. H2 improved on this with more zones, but Helios goes further – it has 8 operation zones and can process 16 qubits at once in a batch. By using shared lasers and time-multiplexing, Helios scaled to 8 zones without eight times the optics. This parallelization is novel and required careful mitigation of crosstalk (Helios’s design ensures that laser light in one zone doesn’t inadvertently affect neighboring zones). The team reports no evidence of correlated errors between different zones’ qubits during simultaneous operations, indicating that the isolation is effective and truly parallel gates are achieved.
• Improved Control Efficiency: Even as the hardware grew in complexity, Helios actually uses fewer control signals per qubit than prior generations. Helios’s trap has many more electrodes (1228, to shape complex potentials for moving ions) but these are driven by a relatively small number of independent voltages (273) by repeating patterns. The result is only ~2.8 control signals per qubit, versus ~4.8 in H2 and ~9.9 in H1. This is a remarkable reduction in per-qubit overhead, indicating a more integrated and scalable engineering approach. Fewer control channels means simpler wiring and control electronics as the system scales up.
• Helios Runtime (Real-Time Control): Perhaps the most groundbreaking change is in the classical control system – Helios is orchestrated by a new runtime that can make real-time decisions during circuit execution. In H1/H2, like most quantum computers, all qubit operations and moves were pre-compiled and scheduled in advance. By contrast, Helios’s controller can map qubits to hardware on the fly, dynamically route ions, and even adjust the sequence based on intermediate measurement outcomes. This real-time control is what allows “dynamic circuits” and feed-forward operations on Helios (we discuss this more in the next section). It’s a significant step toward more complex, interactive quantum algorithms that earlier static systems could not execute natively.

In summary, Helios is not just a bigger copy of H2 – it’s a fundamentally refined machine. The combination of a different qubit type, a new trap design with an X-junction and ring memory, more parallel gate zones, and a smarter control system makes Helios a leap forward in Quantinuum’s QCCD roadmap. The impact of these choices is evident in the performance metrics: Helios sets a new state-of-the-art in error rates and capabilities at ~100 qubits, whereas maintaining all-to-all connectivity which many other platforms sacrifice at scale. It’s worth noting that Helios’s achievements were recognized as establishing “a new frontier of fidelity and complexity for quantum computers” by operating beyond the reach of classical simulation.

Performance Metrics: Fidelity, Speed, and Scale

Helios’s performance has been rigorously benchmarked, and the numbers are impressively high. For security professionals, it’s important to translate these technical metrics into plain language: higher fidelities mean more reliable qubit operations, which in turn means larger quantum computations can be run before errors dominate. Here are Helios’s key performance metrics, as reported in the arXiv technical paper:

• Single-Qubit Gate Fidelity: ≈99.9975% (error rate ~2.5×10^-5). Helios’s single-qubit rotations (the basic flips and phase rotations) are extremely clean – only on the order of 2 in 100,000 operations fail. Such high fidelity approaches some of the best isolated lab qubits and is remarkable for a fully integrated 98-qubit device. This is achieved through the low-noise lasers and stable barium clock states.
• Two-Qubit Gate Fidelity: ≈99.92% (error rate ~7.9×10^-4). The entangling gate (a Mølmer–Sørensen type RZZ(π/2) gate in this case) has an error well below 0.1%. For comparison, this exceeds the fidelity of typical two-qubit gates in superconducting processors (which are often 99% or a bit above on the best pairs), and even other ion systems – for instance, IonQ’s 32-qubit Forte system was recently reported with ~99.65% 2Q fidelity (0.35% error). Helios is an order of magnitude better in error rate than that, which translates to significantly deeper circuits can be run before errors accumulate.
• State Preparation and Measurement (SPAM) Fidelity: ≈99.95% (error rate ~4.8×10^-4). This measures how well the system can initialize qubits (into |0⟩ say) and read out their values at the end. Helios’s SPAM errors are around 0.05%, meaning 1 in 2000 preparations/measurements might be wrong. Such high fidelity readout is achieved by techniques like high photon collection efficiency and separating readout ions from others to avoid light pollution. Notably, the error here includes any population that leaked out of the qubit states (to other ion levels) – Helios’s leakage during measurement is extremely low.

These numbers are averages across all qubits and zones in the system. Importantly, none of these error rates appear to be at a fundamental limit – the authors note that there are known technical improvements possible to reduce them further. For instance, 7.9×10^-4 two-qubit error is already excellent, but might be improved with better laser beam shaping or calibration, since no physics principle forbids reaching 1×10^-4 in the future.

Helios’s performance was validated not just at the component level but also at the system level. Researchers ran randomized benchmarking and complex random circuits across many qubits to see how errors compound. The system-level tests aligned well with what you’d predict from individual gate errors, meaning Helios behaves as expected when scaling up circuits. In fact, Helios executed random circuit sampling (RCS) on 98 qubits at a depth beyond what classical supercomputers can simulate, entering a regime of quantum advantage. This is similar in spirit to Google’s 2019 “supremacy” experiment, but with far higher fidelity; Helios’s RCS circuits had enough fidelity that their outputs couldn’t be efficiently faked or predicted by classical means.

In practical terms, Helios can generate entangled states that are too large and too complex for any existing classical computer to track, a testament to both its qubit count and its low error rates.

Transport and Crosstalk Errors

A critical aspect of Helios’s QCCD approach is that moving ions around does not introduce prohibitive errors. The team carefully measured memory errors – the slight decoherence qubits experience while waiting or being shuttled – and crosstalk errors – unwanted effects of operations on neighboring qubits. These were found to be very small. For example, an idle qubit sitting in the storage ring sees only on the order of 1×10^–5 error per transport operation due to magnetic field inhomogeneities. Crosstalk was measured by doing simultaneous operations; Helios showed no significant correlated errors between qubits being operated in parallel in different zones. The careful design (laser beam angles, shielding, and temporal scheduling) paid off so that parallel operations behave almost as if they were alone.

This means the 8-zone parallelism is truly effective – doubling the number of zones did not suddenly double the error per gate or anything like that.

Speed and Throughput

Trapped-ion gates are generally slower than superconducting gates, but Helios mitigates this with parallelism and pipelining. Each two-qubit gate on Helios takes about 70 µs of laser pulse time, and single-qubit gates are on the order of a few µs. Additionally, moving and cooling operations add a few milliseconds per layer (ground-state cooling of an ion crystal takes ~3 ms in the current system). However, because multiple pairs are gated at once and the next batch is prepared during cooling, Helios can achieve a fairly high effective throughput. The team defined a “depth-1 layer time” (the time to do a round of parallel 2-qubit gates across all qubits) and measured it for various densities of gates. For fully dense circuits (all qubits entangled in each layer), the layer took on the order of a few milliseconds. This is a big improvement over earlier ion traps that had to gate qubits sequentially or with fewer zones.

In short, Helios won’t win a race on absolute gate speed, but it maximizes work done per unit time by doing many things concurrently. From a security perspective, faster quantum operations mean higher-risk capabilities sooner. Helios’s throughput suggests that even at <100 qubits, it can perform algorithms that require hundreds or thousands of gates in a reasonable wall-clock time.

Comparison to Other Platforms

Helios’s metrics place it at the cutting edge among current quantum hardware:

• Compared to superconducting qubit processors (like those from IBM or Google), Helios has much higher connectivity and fidelity per operation. IBM’s 127-qubit Eagle processor, for example, connects qubits in a fixed 2D nearest-neighbor grid and typically has two-qubit gate errors in the 1–2% range. Helios has all-to-all connectivity (any qubit can interact with any other via transport) and sub-0.1% two-qubit errors. This means algorithms that would require complex swapping networks on a superconducting chip (introducing many opportunities for error) can be executed more directly on Helios. The flipside is that superconducting qubits operate at GHz speeds, whereas ion qubits are kHz, but for many quantum algorithms the limiting factor is error depth, not individual gate speed. Helios’s ultra-high fidelity effectively gives it a larger quantum volume or algorithmic qubit count than a naive qubit-number comparison suggests. Indeed, IonQ’s quantum volume-style benchmark (#AQ) for their 32-qubit system is 29, whereas Helios with 98 qubits and higher fidelities would be expected to have an even higher effective quantum volume (though a formal number isn’t published yet). That indicates Helios can utilize a large fraction of its qubits coherently in computation, something many platforms can’t yet do at similar scale.
• Compared to other trapped-ion systems: The closest peer might be IonQ’s devices (IonQ is another leader in trapped ions). IonQ’s latest machines use a linear chain of Yb⁺ ions with all-to-all gating achieved by global laser modes, and have demonstrated up to 30–32 qubits in a chain. IonQ reported average two-qubit gate errors of ~0.35% and one-qubit errors of ~0.03% on their Forte system. Helios substantially outperforms those with 0.079% two-qubit and 0.0025% one-qubit error rates. Moreover, Helios’s QCCD approach with a junction and separate zones is more scalable in principle than a single chain: IonQ’s single chain becomes harder to control as qubit number grows (crosstalk and mode crowding increase), whereas Helios can in the future add more zones or another junction to grow the number of qubits without a single chain of 100+ ions. Helios already shows nearly 100 qubits fully connected, which is unprecedented for any qubit technology. It’s worth noting IonQ recently announced a record 99.99% two-qubit fidelity in a specialized 2-qubit demonstrator with microwave-driven gates. While impressive, that was not yet in a large-scale device. Helios’s fidelities are achieved in a functioning 98-qubit computer running actual circuits, which is a significant practical milestone.
• Compared to neutral-atom arrays: Companies like Pasqal and QuEra are developing quantum processors with neutral atoms in optical tweezers, which have the advantage of easily scaling atom counts into the hundreds. However, their two-qubit gate mechanism (typically via Rydberg blockade) currently has lower fidelity (~99% or less) and only local connectivity (usually nearest-neighbor in a 2D array). Helios’s 98 qubits all interacting with high fidelity is arguably a more powerful platform today for arbitrary algorithms than, say, 256 neutral atoms with 10% error rates restricted to local interactions. Neutral atom tech may catch up in fidelity, but Helios has set a high bar for error rates across many qubits.

In summary, Helios offers an exceptional combination of quantity and quality of qubits: nearly 100 qubits with errors far below 1% across the board. It demonstrates that trapped-ion systems can scale in qubit number while improving (or at least maintaining) per-qubit performance. For CISOs, this underscores that quantum hardware is steadily progressing on both metrics needed for breaking cryptography – the number of qubits and the error rate. Helios has not broken any crypto by itself, but it is a clear step towards the kind of machines that potentially could.

Real-Time Execution and Helios Runtime

One of Helios’s most groundbreaking features is less visible than the trap hardware but just as important: its classical control software, nicknamed the Helios runtime. This is the layer that translates quantum algorithms into actual operations and schedules them on the device in real time. Helios’s runtime is a departure from the norm in quantum computing, enabling a level of flexibility more akin to classical computer architectures. Here’s why it matters:

Dynamic, On-the-Fly Compilation

In most quantum processors, you must compile a quantum circuit offline – i.e. determine a fixed sequence of gate operations and routings ahead of time – and then run that static sequence on the hardware. Helios changes this model by performing much of the compilation and routing logic on the fly, in real time as the program executes. The Helios runtime receives a high-level description of the quantum program (with abstract qubit labels and gates) and does the following dynamically during execution:

• It maps virtual qubits to physical ions in the trap, choosing which ion will represent each logical qubit of the algorithm. If a program asks for 50 qubits, the runtime picks 50 specific ions out of the 98 and can adjust this mapping on the fly (for example, if some qubits are measured and freed, those ions can be reallocated).
• It schedules gates in parallel as much as possible, grouping operations into “slices” that can be executed concurrently given the 8-zone constraint. Essentially, it looks at the quantum circuit and decides which operations can happen simultaneously on disjoint sets of qubits, up to 16 qubits (8 two-qubit gates) at a time. This is done in real time, which means even if the circuit’s exact shape depends on previous results, Helios can handle it.
• It determines ion movement: The runtime figures out which qubits (ions) need to be brought together for each two-qubit gate slice, and then computes an efficient routing plan to fetch them from memory to the logic zones. This involves choosing, for each pair of qubits to be entangled, whether to route them to the top or bottom arm, which direction to rotate the ring, etc. The algorithm tries to minimize travel – e.g., it will rotate the ring the shortest distance such that the needed ions come to the cache, and assign pairs to upper/lower legs to balance load. The outcome is a sequence of transport primitives (shifts, splits, etc.) that the runtime then issues to the hardware control.
• It handles conditional operations and feedforward: Since the runtime is running synchronous with the experiment, it can react to measurement outcomes. For instance, if the quantum program says “measure qubit 5, and if the result is 1, apply a gate to qubit 7,” Helios does not need two separate runs for the two cases. It can measure qubit 5, send the result to the classical controller, which in the same experiment will decide whether or not to apply the gate on 7. This capability is often called mid-circuit measurement and feed-forward, and Helios can do it with microsecond latency decisions. The paper mentions an example where part of a program performed a call out to an external classical server for computation and then continued the quantum circuit based on that result – something made possible by the runtime’s interactive nature.

In essence, the Helios runtime acts like a quantum operating system scheduler, managing qubit resources and operations in real time. This is a significant architectural breakthrough because it enables truly arbitrary quantum programs to run natively on the hardware, not just static circuits. Arbitrary programs include those with loops, conditionals, and adaptive execution which are important for algorithms like quantum error correction, variational algorithms with feedback, and more complex cryptographic protocols.

For example, from a security angle, running Shor’s algorithm for factoring requires mid-circuit measurements and classically processing those results to determine subsequent quantum gates. A machine without dynamic control would have to break such an algorithm into many separate circuits or rely on heavy classical post-processing between runs, incurring huge time penalties. Helios can in principle perform such algorithms in one coordinated execution – measure a qubit, use the Helios runtime to compute the next angle or gate, and apply it immediately, all within one session. This real-time adaptiveness is a stepping stone toward implementing quantum error correction as well, where measurement of error syndromes must be immediately processed to decide feedforward corrections.

To highlight, the Helios runtime has four core responsibilities:

1. Qubit Allocation: managing the mapping of logical qubits to physical ions.
2. Gate Scheduling: grouping gates that act on distinct qubits into parallel sets (slices).
3. Physical Mapping of Gates: converting a set of logical operations into specific physical operations in the zones (including breaking multi-qubit gates into sequential zone operations if needed).
4. Transport Orchestration (“Sort”): generating the sequence of ion moves to bring required qubits into the zones for each slice.

Each of these occurs on-the-fly. The runtime constantly updates a model of where each qubit is (in memory or in a zone, etc.) and what operations are coming next, then makes scheduling decisions. This is analogous to a CPU pipeline or an OS scheduling threads – but much more complex because it must respect quantum constraints (like not measuring a qubit before its last gate, etc.).

From the user’s perspective, Helios’s dynamic compilation means writing quantum programs with classical control flow is easier. One could, for instance, program a loop that keeps applying certain gates until a condition is met, and Helios can execute it without unrolling the loop into a giant static circuit.

Why it Matters

The Helios runtime indicates quantum computers are becoming more programmable and versatile. Early quantum computers ran somewhat rigid circuits (which is fine for tasks like random circuit sampling or certain algorithms), but real-world applications often require adaptivity (think of searching for a specific key, where you stop when found, or error correction which constantly adapts to errors). Helios shows that the control systems are catching up to allow these practical quantum algorithms to be run efficiently. In terms of threat, an adaptive quantum algorithm might solve certain problems faster or with fewer qubits than a non-adaptive one. For example, Grover’s algorithm (quantum search) benefits from adaptive phase rotations to optimize success probability. A machine like Helios could execute such adaptive improvements in-line, potentially reducing the resources needed to crack something.

Overall, the Helios runtime is a strong step towards treating the quantum processor more like a general-purpose co-processor that can interact with classical logic in real time. This will be crucial for scaling up to error-corrected logical qubits (which demand constant measurement and feedback cycles). Quantinuum’s achievement here suggests that when larger hardware arrives, the control architecture won’t be a bottleneck – they are already mastering real-time quantum control now.

Implications for Cryptography and Q-Day

With its 98 qubits and record fidelities, Helios invites the question: How much closer are we to quantum computers that can break cryptography? In the post-quantum security community, the hypothetical moment when a quantum computer can crack RSA or ECC is often dubbed “Q-Day.” While Helios itself is not going to crack RSA-2048 tomorrow, it represents meaningful progress toward the kind of machine that eventually could. Let’s break down the considerations:

• Scale of Qubits vs. Requirement for CRQC: The consensus is that breaking modern public-key crypto (RSA-2048, ECC 256-bit, etc.) with Shor’s algorithm will require a fault-tolerant quantum computer with thousands of logical qubits. A logical qubit in turn will consist of many physical qubits (through error-correcting codes) – likely on the order of millions of physical qubits in total. Recent research by Google and others suggests that factoring a 2048-bit RSA number would require on the order of 10⁶ noisy physical qubits running for a few hours to a week. Less aggressive estimates still put it at millions of qubits for a single computation if we want a high success probability in a reasonable time. Helios’s 98 qubits are several orders of magnitude away from this regime. Even though those 98 are high quality, we would need to see a leap to something like 1000 qubits, then 10,000, and so on, with error correction, before classical cryptography is in immediate danger. In short, Helios does not bring us to Q-Day yet, and its creators are not claiming any cryptographic demonstrations like breaking large keys.
• Error Correction Path: Helios’s low error rates are at or near the threshold for certain quantum error correction codes. Fault tolerance requires not just many qubits but also error rates below a certain threshold so that logical errors can be suppressed exponentially. With two-qubit error ~7.9×10^–4 and measurement ~5×10^-4, Helios is very close to thresholds for popular codes (often quoted around 10^-3 for the surface code, for example). This means that if one were to dedicate a portion of Helios’s qubits to an error-correcting code, it could in principle start to demonstrate a logical qubit with longer coherence than the physical ones. Indeed, previous Honeywell/Quantinuum devices have already shown small quantum error correction feats (like a fault-tolerant logical entangling gate on a 5-qubit code). Helios’s architecture – with mid-circuit measurements, all-to-all gates, and parallel zones – is well suited to error correction experiments. It could run, say, the Steane code or small surface code patches and do the necessary cyclic syndrome measurements with its real-time controller. While Helios’s 98 qubits could maybe support on the order of 1–2 logical qubits with a certain code, it’s still far from the thousands needed for breaking encryption. However, it’s a crucial engineering demonstration that could inform how the next generation (say, 1000 physical qubits) might integrate error correction. For PQ security pros, this indicates the field is entering the era of integrating error correction – an essential stepping stone to the big cryptanalytic machines.
• Timeline Considerations: One might ask, if we went from 6 qubits in 2020 to 98 in 2025 at Quantinuum, will we have 1000 by 2028 and 1 million by 2035? It’s not a linear trend, of course, and there will be challenges in manufacturing, cryogenics (for other platforms), or in this case vacuum ion traps and laser systems as we scale. But Helios shows a scaling trajectory that is quite promising: roughly an order of magnitude increase in qubits in ~5 years, with improving fidelity. If this trend continues (or accelerates with modularity or networked ions), a system with a few hundred physical qubits and basic error correction might emerge in the next 5–7 years. Such a system could factor, say, small RSA (maybe RSA-512 or RSA-1024) as a proof of concept. In fact, with ~1000 physical qubits and error correction, a demonstration on cryptographic primitives is conceivable. However, breaking RSA-2048 reliably is a much taller order. Whether that is 10 years away or 20+ is still debated, but it is certainly closer than it was a decade ago. As one data point, researchers have optimized Shor’s algorithm such that <1 million qubits could factor 2048-bit RSA in under a week in theory. That is a huge number of qubits, but not astronomically huge – especially given companies are already talking about modular and networked quantum data centers to reach millions of qubits in the coming decades.
• Need for Post-Quantum Cryptography: For CISOs, the takeaway is that Q-Day is not here yet, but the progress is relentless. Helios confirms that quantum hardware is improving on a double exponential curve (qubits increasing, error rates decreasing). The prudent strategy is to assume that within our planning horizon (say the next 10–15 years), quantum computers capable of challenging RSA/ECC could exist. Data that needs to remain confidential for decades (like healthcare records, state secrets, or critical IP) could be vulnerable if harvested now and decrypted later when quantum tech catches up. Helios’s success is a signal to accelerate migration to post-quantum cryptographic algorithms (PQC). The good news is that PQC standards (like those chosen by NIST) are becoming available, and organizations should begin implementing them well before large-scale quantum computers are online. The achievements of Helios and others also reinforce the importance of quantum-safe solutions like quantum key distribution (QKD) for certain high-security contexts, as a defense-in-depth.

In conclusion, Helios is a major step forward scientifically, but from a security standpoint it should be seen as proof of progress rather than proof of threat. It shows that many of the ingredients for a cryptographically relevant quantum computer – high qubit counts, low errors, dynamic circuit capabilities – are coming together. Yet, assembling those at the scale needed for breaking strong encryption will require further breakthroughs and engineering of many more qubits. We are still years away from Q-Day for RSA-2048 under optimistic projections. However, the conservative approach for security leaders is not to wait. Helios’s architecture may well be the blueprint for early fault-tolerant machines, and its existence today affirms that now is the time to implement quantum-resistant encryption for future-proof security.

Conclusion

Quantinuum’s Helios quantum computer showcases the cutting edge of quantum architecture in 2025. By marrying a novel trapped-ion layout (with a rotatable memory ring and dual processing regions) to an advanced control system, Helios achieves performance and flexibility unprecedented in a 98-qubit device. For CISOs and technology strategists, Helios is a glimpse into the near future: quantum hardware scaling up while maintaining the precision needed for meaningful algorithms. Its innovations – barium ion qubits, all-to-all ion transport, parallel gate execution, and real-time compilation – collectively push the field closer to the era of useful quantum computing.

From a security perspective, Helios does not suddenly break encryption, but it erodes the technological barriers that have kept quantum computers too small and error-prone to threaten cryptography. It underscores that progress is rapid and multidimensional. Planning for post-quantum security is no longer theoretical; it’s a necessary timeline consideration. The world’s leading quantum engineers are solving problems and scaling systems at an impressive pace.

In summary, Helios should be appreciated as a tour de force of quantum engineering that brings us one step closer to quantum practicality.