Welcome everyone. I'm Kingsley Crane, technology analyst here at Canaccord Genuity, covering quantum computing, infrastructure software, and AI. Timing of today's event is striking on a few fronts. First, the science. The last 18 months have produced genuine breakthroughs in quantum error correction. We've seen a move from theory to engineering on these more efficient error-correcting codes, and a shortened estimate of what it takes to reach cryptographically relevant computation. Second, capital. This morning, the U.S. Department of Commerce announced that it's awarding $2 billion to nine quantum companies, including direct equity stakes in a few companies that we'll be speaking with today. This is on top of DARPA's Quantum Benchmarking Initiative, Canada's Project OPTIMISM, and similar European programs. Technology's clearly maturing faster than expected, and sovereign capital's flowing in at scale. Arguably for the first time, the public quantum universe is large and credible enough for real portfolio construction, and so we're exploring all that today. With me this session, I have Horizon Quantum. They completed their merger with dMY Squared in March. They've been trading on the Nasdaq under HQ since March 20th. They're more of a pure software play. They're building a hardware-agnostic quantum development environment called Triple Alpha, with the goal of becoming the default software layer for quantum computing across modalities, with a particular interest in converting classical code to solve classical problems with quantum computers. Joining us today is Dr. Joseph Fitzsimons, Chairman and CEO. He founded the company in 2018 in Singapore. Delighted to have you, Joe. Thanks very much for having me. Maybe just to start off, most of today's quantum companies build hardware, and you do not. You're building a software development environment, a compiler stack that lets developers program any quantum computer. You've drawn analogies to Windows for PCs or iOS for mobile, CUDA for GPUs. Can you just tell us a little bit more about what that actually means for both customers and investors, and just a bit more on your vision? Yeah, absolutely. I think one of the important things to understand is that quantum computers are, in some sense, like other computers, in that they need software in order to actually do meaningful work. It's not enough to simply have a number of well-controlled qubits. You actually need to decide what you want to do with them to turn that to solve a particular problem. What we have been working on is basically trying to figure out how can we get to applications that create real value for the end users of that software running on quantum computers. What we have been trying to do is to build a path to automatic acceleration of code written for conventional computers. The reason we want to do this is essentially because if you look at the domains in which quantum computing stands to be a real unlock, the domain experts in those fields are not experts in quantum computing, and the people who are experts in quantum computing are not domain experts in those fields, whether that be in finance or in pharma or in machine learning, in the energy sector, in aerospace and defense, and a whole range of different industries. The reality is these people are already writing code. They're familiar with programming. They're already utilizing HPC to tackle many of these problems. Quantum computing's different, right? Quantum computers are computers with an extra trick, at least at their best. That trick is the ability to exploit quantum interference. Basically what we need to do is figure out how are we going to harness quantum interference to solve problems more efficiently on quantum computers than we can with conventional computers. If we're not making use of that extra trick, we may as well be running on conventional computers. The big problem you have here is that quantum interference is not something that humans have a natural intuition for. You have to figure out, how are we going to build these applications? What we have been doing is to try to automate that process, try to build the capabilities to automatically construct quantum algorithms from code written for conventional computers. In order to do that, you pretty rapidly realize that, okay, if you can do the algorithm construction, you're still left with a program that is much more sophisticated than anything that has ever been run on a quantum computer. You have to think about how do we actually do that. Can we run that on today's quantum computers? The answer is no, because although I say the promise of quantum computers is to be better computers, they are currently worse computers. They can't do loops. They can't do general control flow for the most part. They definitely don't have operating systems, so things like dynamic memory allocation and other things your computer takes for granted are not present in these systems. What we have had to do, at least in my view, is try to speed run the history of computer science. We have tried to build up starting with kind of 1950s assembly languages and build up to modern software programming. That has meant building our own portable assembly language, building our own compilation stack, building higher and higher levels of abstraction to try to get to this place when we can go from programs written for conventional computers to accelerated implementations on quantum computers. Mm-hmm. Do you feel that software has been under prioritized in this space, and in this space, at least from an investment perspective? Yes, absolutely. I think it's relatively easy to see why. The hardware side of quantum computing is very physics-centric. You need special systems that do not exist. You cannot run a quantum computation on a conventional computer natively. You can simulate one, but only up to a relatively small size, only up to 40 or 50 qubits. Once you go beyond that, and certainly today, we have systems that have well more than that number of qubits, you cannot simulate it with a conventional computer. It's easy to think that all of the hardness of quantum computing is in that hardware side in terms of building the hardware that can actually implement this extra trick that quantum computers have. It really is hard to build that hardware. You also need to take into account the need to solve this algorithms bottleneck. How are we going to actually harness these systems? That means we have to build up much of the software infrastructure that you have for conventional computers today that we have built up over 80 years. We're trying to speed run that, right? We have to do 80 years of work in eight years. There's a lot of work to be done on the software side. It's highly technical. If you look at my team, our science team is twice as big as our engineering team, so we have way more physicists than we have people coming from software engineering backgrounds. That's just reflective of the state of the art. There's a lot of hard research problems to be solved, not just on the hardware side, but also on the software side. Mm-hmm. When we talk about software, there's the full stack of software you could think of, like firmware that's more dedicated to a specific type of hardware, and then, an application development platform. Eventually, much longer term, we'll have potentially dedicated applications that are commercialized on Quantum. Can you help us understand where you sit in this stack, how expansive you'd like to be within that? Then just, what can a developer do on Triple Alpha that they fundamentally cannot do in Qiskit or even Cirq today? What I would say is our stack tends to be broader, in terms of the swathe of the stack it is spanning than existing systems. We're very much focused on getting the most out of quantum computing hardware, and that means something different to us, I think, than it does to many others. The way we approach programming quantum computers is a little bit different than most efforts up to now. Most programming frameworks, you mentioned Qiskit, but there are a number of others. Basically, they've kind of evolved coming from the perspective of gradually exposing capabilities of hardware as it emerges. You can think of this as a kind of bottom-up approach, where as the hardware advances and gains new capabilities, those capabilities then get exposed through the programming frameworks, but could not have been expressed in earlier versions of those frameworks. We're going the other way. We're saying, how does a perfect quantum computer work? How do we program that ideal system? How do we get that code to run on today's computers? That means we need to bridge a lot of the deficits and the capabilities of today's systems. There's a lot we need to do there in the runtime area, not just in terms of programming languages and compilation, but in terms of how we execute the code. Some of the things that we're able to do that are not capable on many current generation systems are things like general control flow, the ability to have indefinite loops, like while loops, the ability to have branching programs that have indefinite runtime, the ability to do mid-circuit measurement and classical computation based on that mid-circuit measurement across any of the hardware platforms we run on, the ability to do IO with external systems mid-computation. Reading in or out through, in our case, a web API is how we interface with many systems. There's a reason others don't do that. One of the reasons is that current gen technology does not support that. Qubits decohere in that time window. Part of the trickery that we have to do behind the scenes is stitch together multiple runs on hardware to give the effect of a single run on a much more capable system, so that we are able to add all of these execution capabilities. We've also had to build up the system software side. We have capabilities in terms of dynamic memory management and other OS-type capabilities that would normally be provided by system software. You mentioned multiple runs on a hardware. Would that require some sort of parallelism or multiple systems, or what kind of operational challenges might that introduce? Yeah. Generally, the way you do this is you execute once, you get back results for part of your computation that informs your choice of construction of a larger circuit to evaluate, and you send that to the hardware. You get that back, and you have to then check, is that consistent with your first run? If it's not, you have to throw it out and try again. Going through execution in this manner means that you're calling those hardware systems significantly more times than you would otherwise have to. Usually, it's not parallelism. Usually, there's only one system at the end of it, and that's being called sequentially multiple times, and then it's being stitched together by a classical program. There's a cost to it. It means more runs on hardware. The advantage is that hardware then gains capabilities that are effectively the same as a much, much more mature quantum computer. There's advantages to it. Right. To compare it to some of the other more resource-hungry AI systems, it's nowhere near that kind of resource consumption. Sure. It just depends how many different points of which you make use of these features. What we have been working hard on is to integrate closely with control electronics. I think we're certainly the first software company in this space to start operating the hardware. We have a superconducting system here in Singapore that we've pieced together from components. We have a Rigetti processor in it at the moment with a Quantum Machines controller. We've been integrating tightly with the control electronics so that we are able to start to do these more advanced features in real time with a single run, rather than having to pay that overhead of stitching together multiple calls. That's what we're pushing towards. If we can do that, it really shortens the path to a real advantage. Mm-hmm. I think everything that you're doing at Horizon is incredibly impressive. We've talked about this a number of times, but one of the more interesting things is just the idea of classical to quantum compiler, that a developer could write conventional code, and then you could help them generate a quantum accelerated version. Also, this idea that there's a lot of debate about what the total market is or what the total addressable opportunity is for quantum computing, and I think you're of the belief that it could be larger. We could be addressing a much larger swath of problems with quantum computing than somewhat estimate. Would just love to hear more about the vision for that classical to quantum compiler, and then just your thoughts on how quantum computing can address a more broad set of problems. Yeah. What I would say is we started out from this direction. Initially, as we started as a company, we were working towards automatic acceleration of classical algorithms on quantum computers. We had to build all of the software infrastructure we have now to start to try to realize that because it really shines a light on the gaps that exist in the current hardware and software stack because you wind up with these much more complex programs or much more sophisticated programs than have ever been dreamt up for quantum computers in the past. That's really informative, I would say, in terms of how we think about building software infrastructure. The way we approach this is pretty straightforward. We try to break apart the things that cause programs to be slow. It's almost never the length of the program, it's the fact that you are reusing code again and again and again because of loops or because of recursive function calls. What we try to do is break apart the control flow of the program and break apart loops, fission them into smaller and smaller pieces. Similarly, try to unentangle recursive calls to functions to break them into simpler and simpler elements. We may have very many of these, but they become simple enough that we can start to recognize what each one does and replace it automatically with a more efficient means of doing the same thing that may or may not exploit quantum processing. That allows us to construct a quantum algorithm for the same task that is provably no worse than the existing code, but that is potentially much, much faster than the code you started with. Of course, that requires a mature quantum computer to run on, and that's why we've been pushing hard on the infrastructure side and with the test bed side as well on the hardware. In terms of broadening the TAM, you're absolutely right. The way I view this is that all computation you can think of, like every kind of calculation you would ever do on a computer, you can think of it as being constructed of two parts. You have control flow that is linking together essentially blocks of pieces of logic circuit. It turns out you can come up with quantum algorithms to accelerate the evaluation of both. There are quantum algorithms that allow you to evaluate Boolean circuits more efficiently than you could on a conventional computer, and it turns out there are quantum algorithms that allow you to accelerate control flow. If you take the two of those together, it makes it essentially much more widely applicable than if we are looking at specific algorithms and saying, "Okay, well, I have an algorithm for Monte Carlo methods. I have an algorithm for search. I have an algorithm for this." I think a lot of the way the industry still thinks about quantum computing is as that library of algorithms. Quantum kernels or something that you're going to just call these functionalities as kind of pre-built programs to solve particular tasks for you, rather than constructing more complex programs that are based on sometimes simpler primitives. As a result, I think, potentially a lot of the analysis we see, if you look at the BCG reports and so on, you'll see kind of several different categories, quantum speed up for simulation, quantum speed up for optimization, also ML, also cryptography. I think that's missing a lot. It's missing all of the applications you have in the energy sector. It's missing a huge number of different applications that are not simulation or optimization that come from accelerating linear algebra, for example, which is just widely used. This is what GPUs do, right? They do matrix calculations, and matrix calculations can be very fast on quantum computers. Mm-hmm. I think this flows well into talking about Beryllium. When you're talking about speed running, the development of software for quantum computing over 80 years and pressing that down into this timeline you view from Hydrogen to Helium to Beryllium, which is this object-oriented programming sort of step in your vision. Could you just talk a little bit more about that and then just what does Beryllium let a developer do that they couldn't do before? We showed off a preview of Beryllium in December. This is a big unlock for us, I would say. Hydrogen was our portable assembly language. Helium is a kind of imperative language. You can think of Hydrogen as being 1950s technology, Helium as being 1960s technology. With Beryllium, we're getting to the late '70s, early '80s in terms of technology. I know that's a long way from the present day, but if most of quantum computing is still stuck in the 1940s, I think that's a good step forward. What it allows for is, it's an object-oriented programming language. The real advantage of this is that it allows you to mix classical and quantum data to represent different kinds of information. You can specify how you represent that information as a mixture of classical and quantum states, but also how you manipulate it, in terms of quantum algorithms and so on. The net result of this is that a developer building in Beryllium can build a library to represent a new kind of data that Beryllium doesn't natively represent. For example, a matrix or a tensor, or something like this. Another developer can import their library that they've built, if the original developer is willing to share. Imagine they open source it. The next developer can import that library, and now when they start programming, they can use matrices right from the start. They can say matrix A equals whatever. They don't need to think about the underlying quantum mechanics of how that matrix is represented, how it's processed. We can start to allow developers to build up abstraction layers that abstract away entirely the quantum mechanics. The quantum mechanics is there for developers that want to delve into it, and certainly experts in quantum computing will want access to that. It allows to build these higher levels of abstraction where quantum mechanics is no longer necessary. You are just thinking about how you manipulate different kinds of data. That really starts to make it much more accessible to developers who are not experts in quantum computing because they can start to use tools built by people who are. The other advantage with this, which is very much tied to that, and I should say is a business advantage for us as a company, is that because it allows this kind of code reuse, it means that every time a developer builds a new library and makes it available, the whole system becomes more powerful because a new developer can import that library and can do more with less code. There's a pretty strong network effect that this unlocks as well. As each library is added, the overall ecosystem becomes much more powerful. You see that with Python, that's why Python is so prevalent in software engineering today. It has this incredibly strong library ecosystem that becomes self-reinforcing. Well, it's encouraging to see where the initial state of the library and excited to see how that develops over time and those network effects continue. Want to touch on just two more things, one being just your relationship with hardware. Last month you did purchase one of IonQ's 256 qubit systems for your multimodality test bed. Just curious what acquiring the system opens up for you, just how you're thinking about that portfolio of systems over time? Sure. For us, a real focus is on getting to a real advantage as soon as possible. There's two things this system ticks off for us. We had thought when we initially decided to invest in hardware, set up the first test bed system, it was part of kind of a three system plan for me. I was expecting the second system to be an AMO system, and by that I mean atoms and optics. Trapped ion system ticks that box for me with this new IonQ system. The reason we wanted that is to have exposure so that we learn how to operate systems of both of the two kind of broad categories you have. Stuff that needs to be cold and needs microwave control, stuff that needs high vacuum and optical stability. You have those two categories. Their operational requirements are very different, their control requirements are very different, and so on. Having a system of each kind allows us to gain exposure to both kinds, to learn the lessons of both kinds, that are essentially enough for us to know how to operate almost any system kind, how to be able to control almost any system kind. The other thing it ticks off for us is what we would've expected from a third system, which is to be at the range of possibly allowing a real quantum advantage. At hundreds of qubits, if the error rates can be pushed into the three nines, something like that, at that point, there are chemistry applications that are potentially useful. Will this system hit that? We don't know for sure. We're very interested to see where we can go with this and whether it's possible to achieve a real advantage for us. We really believe tight integration with the hardware is the key to unlocking that advantage. You can't do it at just the software or hardware layer alone. Yeah. We are running up on time. The ticker for Horizon is HQ. Software, despite being under prioritized, is such a critical component for us to reach a commercialization of quantum. Is there anything else you'd like to leave the audience with, Joseph Fitzsimons? As you say, we're a software company. That also means that our economics just look totally different. Our cash burn is completely different than the hardware companies. Where we sit in the stack, we get to insulate developers from technology risk. They don't need to pick which hardware system is going to win. Instead, they can write code in one language, run on basically any machine. We do it in a way, as I say, that has software economics, not hardware economics. Which I think makes us a pretty interesting company in this space. Absolutely. Yeah, we do love software companies over here. Thanks again, Joe. Thanks so much for the time and participating in this event. Thanks very much.