Good day. Thank you for standing by. Welcome to the Horizon Quantum second quarter 2026 report conference call. At this time, all participants are in a listen only mode. After the speaker's presentation, there'll be a question and answer session. To ask a question during the session, you'll need to press star one one on your telephone. You will then hear an automated message advising your hand is raised. To withdraw your question, please press star one one again. Please be advised today's conference is being recorded. I would now like to turn the conference over to Katherine Bailon. Please go ahead. Thank you, Lisa. Good morning. Thank you for joining us on Horizon Quantum's second quarter fiscal 2026 earnings call. My name is Katherine Bailon. I am Vice President of Investor Relations at Horizon Quantum. Joining me on today's call are Dr. Joe Fitzsimons, our Founder and CEO, and Greg Gould, our Chief Financial Officer. Before the market opened today, Horizon Quantum issued a press release with results for its second quarter ended June 30th, 2026. You can access a copy of the release in the investor relations section of our website at horizonquantum.com. Today's call is being broadcast live over the web and can also be accessed through the investor relations section of the Horizon Quantum website. Before we get started, I'd like to caution you that any non-historic statements that I or the management team make during this call will constitute forward-looking statements within the meaning of U.S. Federal securities laws, including the Private Securities Litigation Reform Act of 1995. You are cautioned that these statements involve material risks and uncertainties, including the risks Horizon Quantum has identified in its most recent annual report, Form 20-F, and other filings with the SEC in our press releases, that could cause actual results or events to materially differ from those anticipated. Except as required by law, Horizon Quantum expressly disclaims any intention or obligation to update or revise any forward-looking statements made on this call, whether because of new information, future events, or otherwise. Any forward-looking statements made on this conference call contain time-sensitive information and are accurate to the best of Horizon Quantum's knowledge only as of the date they are made today, August 4th, 2026. This discussion includes non-GAAP financial measures. These measures are calculated by management and do not have any standardized meaning under U.S. GAAP. These non-GAAP measures supplement GAAP measures but should not be viewed as substitutes for GAAP measures. We have included a reconciliation of GAAP measures to non-GAAP measures as a table at the end of our earnings press release issued this morning. With that, I'll now turn it over to Horizon Quantum Founder and CEO, Dr. Joe Fitzsimons. Thank you, Katherine. Thanks, everyone for joining us on the call today. We've made quite a bit of progress this quarter. I look forward to running through it with you. Just to reiterate our mission, which we've been laser-focused on. Our focus is really on building tools to unlock broad quantum advantage, building the infrastructure to allow developers to harness quantum computers to do real work and to create real value in the real world. As many of you know, we're taking a software first approach on this. We're essentially building up programming languages at increasing levels of abstraction with the ultimate goal of allowing developers that are not experts in quantum computing to be able to harness quantum computers to tackle hard computational problems. I'm going to focus first on the R&D and operational highlights, in particular on Beryllium. Beryllium, which is our object-oriented quantum programming language, our highest level of abstraction that's currently available, is now available in early access to the group that early access have. This brings familiar constructs from the world of classical software development, such as classes, structs, scoped functions, so on, into the world of quantum computing. This will really be a catalyst, at least in my view, in enabling developers to really harness quantum computers to do much more serious work, to be able to construct much more complex programs than is otherwise practical. We've also made a lot of progress in developing libraries for Beryllium. One of the main advantages we have in building an object-oriented programming language is that it's very natural to have libraries to enable code reuse so that one developer can build classes, can build functions, can build components that another developer can then use. That's really important, first of all, in building up a rich developer ecosystem, also in enabling the abstractions that we seek, in enabling developers that are experts in quantum computing to build up components that can then be used by experts in the various fields that stand to be disrupted by quantum computing, who are perhaps not experts in quantum computing themselves, to harness quantum computers to tackle problems they care about. We've had really significant progress in building up a standard set of libraries there, including standard algorithmic building blocks, things like quantum Monte Carlo algorithm, so on. Turning to our superconducting testbed, our Ember-1 system has now been opened up to first users. This is a superconducting quantum computer that we operate out of Singapore based on a chip from Rigetti. One of the advantages we have in operating this hardware ourselves in integrating Triple Alpha, our software directly with its control systems, is that we are able to start enabling real-time execution of Hydrogen programs, which is our kind of portable assembly language, without having to rely on post-selection. This means we're able to do the full set of operations you would expect from a mature quantum computer. These are things like loops and recursive function calls, as well as concurrent classical function evaluation, without having to turn this into some kind of hybrid program where we're going back and forth between a classical computer and a quantum computer. We can start to enable this in real time. This goes far beyond the limitations of quantum circuits, which is where many of the existing quantum programming frameworks focus. Turning to hardware collaborations, we have announced a new collaboration with Quantum Machines, that is aimed specifically at developing embedded calibration, both for use in our Ember-1 testbed system here in Singapore, and also potentially in other systems. The goal really here is to develop a set of calibration routines that can run regularly as the system is operating, rather than having to do a giant batched calibration run at fixed intervals. We're essentially aiming to maintain the system at its highest level of calibration continuously throughout its availability. We have also announced that our second testbed system, that's a 256 qubit IonQ system that will be coming in 2027, will be installed in Dublin. We have operations both in Singapore and Dublin, and with this announcement, we will have systems operating in both locations. I also wanted to turn to recent progress in AI, this is something that I wanted to flag. At the moment, the quantum computing community is coming to terms with the fact that recent frontier models, in particular FABLE and Solve, have started to yield real results in quantum information. In some sense, in the academic community, there's a bit of an existential crisis going on at the moment, trying to think through where the role of researchers sits relative to these AI systems. In particular, we have seen an announcement from OpenAI of a strong parallel repetition theorem, which is extremely important in the context of quantum information theory. As a company, we've been early to invest in AI systems and a dedicated team back in 2023, we've been building up our own capabilities in agentic systems within the company to accelerate our R&D since then. With the availability of these new frontier models, it is starting to become increasingly clear that autonomous scientific discovery is becoming a possibility. That means that it's becoming possible to harness these systems to make scientific progress without substantial human intervention. That's really interesting for us. It really potentially allows us to accelerate our roadmap. In particular, in the last few weeks since these models have been released, we've seen our own agentic systems produce hundreds of research notes on open problems in quantum computing. Turning to applications, one of the defining questions, one of the most important questions for the quantum computing community is how quickly quantum computing will be adopted by industry. How quickly will we see quantum computing move from proof of concept to actual production deployment? Will particular industries be fast or slow to adopt quantum computing? I think that's essentially existentially important for the industry. What we have done is we've taken our first steps to really not leave this to chance, but rather turn it into an opportunity. What we have done is taken the step of establishing a quantum applications team that is focused on three specific high-value problems in each of three industries. The reason we're doing that is to ensure that progress is being driven on industry-relevant problems, and to ensure that we can drive adoption as it becomes possible to solve hard problems with quantum computers, but also to ensure that we stand to capture some of the value of that opportunity. We are not focused on doing proof of concept application with industry, but rather doing the entire end-to-end development within Horizon. You can perhaps think about this as creating a full chain from application through our software infrastructure with Triple Alpha and our compilers, through our runtime environment, down to execution on our testbed systems. This will allow the internal team to really make a sustained effort towards achieving real quantum advantage on problems that stand to deliver real value. The existing AI team that we have that have been working on agentic workflows is going to be rolled into that applications team to accelerate progress. Turning to the financial side, our cash position has strengthened significantly. We have in Q2, $27.5 million in gross proceeds from the exercise of warrants, which is significantly strengthening our balance sheet. The total cash and cash equivalents have reached $113.3 million, significantly fortifying our balance sheet and financial runway, and allowing us to support increased investment in R&D. I'm going to hand over to Greg for more details on this. Before that, I want to address the net loss. This quarter will show a large net loss of $115.2 million, and this is driven primarily by $108.3 million non-cash charge that's related to the remeasurement of warrant-related derivative liabilities. This does not affect our runway in any way. In terms of operating expenses, there's increased operating expenses in R&D and G&A. This is primarily related to the transition to a public company and scaling of the research and development team to meet the demand from collaborations. With that, I'd just like to summarize that we've made substantial technical progress with Beryllium and the testbed. We're tracking well against the milestones we set forth in the F-4, and we've increased our runway due to the proceeds from the exercise of warrants. With that, I'll hand it over to Greg. Thanks, Joe, and good morning, everyone. I'd like to start off by reviewing our financial results in a bit more detail. Before I do, I'd like to mention that all financial results discussed here are in US dollars. We are pleased to receive the cash infusion. As of August 3rd, Horizon has received notices from public warrant holders to exercise approximately $2.5 million common stock warrants, and that represents about 79% of the public warrants outstanding. The exercise of these warrants has generated gross proceeds to the company of approximately $28.7 million to date. This infusion of cash has further extended our operational runway. For the second quarter ended June 2026, a total of, as Joe mentioned, $2.4 million public warrants were exercised, and that generated $2.7 million in gross proceeds, and combined with existing cash, resulted in cash at the end of the June quarter of $113.3 million. This cash level is a net increase of $16.7 million from the $96.6 million as of the end of the March quarter 2026. Total operating expenses for the second quarter of 2026 were approximately $7.2 million, and that compares to $2.8 million for the second quarter of 2025. This increase in operating expense was largely the result of hiring, primarily on our science and engineering teams. R&D expenses consist primarily of personnel-related costs for scientists, software engineers, and technical staff engaged in the design, development, and testing of our software and hardware systems. To a smaller extent, it also includes software and other cloud services and costs associated with the operation of our hardware testbed. For the second quarter of 2026, R&D expenses increased by approximately $1.4 million or 117% to approximately $2.6 million, and that compares to $1.2 million in the second quarter of 2025. Excluding share-based comp and non-recurring comp adjustments, the period-over-period R&D increase was 100%, and that's attributable to increases in headcount and to a much lesser extent, hardware testbed set up costs. For the second quarter of 2026, sales and marketing expenses increased by approximately $0.13 million or 51% to approximately $0.38 million, and that compares to $0.25 million in the prior year period. Excluding share-based comp, sales and marketing expense rose 63% year-over-year, and that's due to increased trade show activity and industry engagement. G&A expenses for the second quarter of 2026 totaled approximately $3.8 million, increasing $2.7 million or 236% from $1.1 million in the second quarter of 2025. Excluding share-based compensation, non-recurring comp adjustments and one-time business combination expenses of about $1.5 million and $0.3 million from the second quarter of 2026 and the second quarter of 2025, respectively, G&A increased 191% period-over-period. This increase was primarily due to increases in headcount and other operating expenses, largely associated with our transition to a public company. For the second quarter of 2026, our loss from operations totaled approximately $7.2 million, an increase of $4.5 million or 267% from a $2.7 million loss in the second quarter of 2025. This increase was primarily due to hiring of staff across the company, including scientists, engineers, as well as staff supporting public company operations. The company reported a net loss of approximately $115.2 million, or $2.20 per ordinary share for the second quarter of 2026, and that compares with a loss of $2.9 million or $0.07 per ordinary share in the second quarter of 2025. As Joe mentioned, the second quarter result included a $108 million non-cash loss from the remeasurement of warrant-related derivative liabilities. The increase in the company's share price during the quarter increased the fair value of these liabilities, resulting in the accounting charge. Importantly, this charge did not affect the company's cash balance. In fact, by contrast, the voluntary exercise of warrants during the quarter generated significant cash proceeds and increased share capital. I'd like to point out that all of the public and private warrants of Horizon Quantum that remain outstanding will continue to be remeasured at fair value each fiscal quarter. Accordingly, future movements in the trading price of Horizon Quantum's Class A ordinary shares could result in additional non-cash gains or losses. Because these fair value adjustments can create substantial volatility in reported earnings without affecting underlying operating performance or cash flow, management also evaluates results on an adjusted EBITDA basis, a non-GAAP measure. Adjusted EBITDA excludes changes in fair value of derivative liabilities as well as share-based compensation, non-recurring expenses associated with the business combination. On this basis, the company reported an adjusted EBITDA loss of approximately $5.5 million for Q2 2026, that's compared to an adjusted EBITDA loss of $2.1 million in Q2 2025. In terms of employees, we ended the second quarter of 2026 at 57 full-time employees, that's versus 34 at the end of the second quarter a year ago, reflecting a 68% increase period-over-period and a 10% increase sequentially from the quarter ended March 2026. Historically, scientists, engineers, and other technical staff have represented 60%-80% of the total headcount, and we remained within this range as of the June quarter 2026. Going forward, we expect this mix to remain consistent. In terms of cash flow, net cash in operating activities for the second quarter of 2026 used was approximately $5.1 million, that compares with the cash usage of $2.0 million in the second quarter of 2025 and a usage of $4.2 million in the first quarter of 2026. The bulk of the period-over-period increase in cash usage was due to growth in headcount. For the six months ended June 30, 2026, net cash used in operating activities totaled approximately $9.3 million versus $3.7 million for the first six months of 2025. We are pleased with our financial and operational performance. As has been the case throughout the company's history, we continue to believe that the best strategy to realizing Triple Alpha's technical potential is for our science and engineering teams to remain focused on the execution roadmap. As a result, we do not pursue proof-of-concept services work, which while potentially generating nominal revenue, we believe would serve as a distraction for our team and slow progress on our roadmap. We plan to engage in revenue generation when the larger quantum industry is reaching quantum advantage. That's the moment when quantum computing can finally solve the hard computational problems that classical computers cannot. That would be when we expect to transition today's early access users to paying users on a cost-per-use model, either on the cloud or on-premise. Finally, I'd like to share our thoughts on our cash balance, which stood at $113.3 million at the end of June. Since we are a software company, our model is a capital-light one. We believe our current cash balance provides us with significant runway as it is our intention to proceed during this pre-revenue period with fiscal discipline and rigor. With that, I'll turn it back over to Joe. I'd like to leave you all with three thoughts. With the availability of Beryllium to our early access users and the opening of Ember-1 to the first external users, we continue to execute as planned against our roadmap. With the establishment of our applications team, we're positioning the company to push towards quantum advantage for three high-value problems. Finally, the exercise of the warrants in Q2 has fortified our balance sheet and extended our runway, giving us the resources to aggressively pursue our plan. With that, we're happy to take your questions. Thank you. As a reminder, if you would like to ask a question, please press star one one on your telephone. You'll hear an automated message advising your hand is raised. If you would like to remove yourself from the queue, please press star one one again. We also ask that you please wait for your name and company to be announced before proceeding with your question. One moment while we compile the Q&A roster. Our first question today will be coming from the line of Quinn Bolton of Needham & Company. Please go ahead. Hey, guys. Thanks for letting me take the question, congratulations on the progress in the second quarter. I guess, Joe, wanted to start off with the early access on Beryllium, hoping you can provide some thoughts on what kind of interest you're seeing from early access users, what kind of feedback you're receiving, but just initial thoughts on how that Beryllium rollout is progressing with your lead customers. Hi, Quinn. Thanks very much for the question. Early access is still a relatively small group at the moment. It's mostly hardware partners. We're just at the early stages of rolling that out. Similarly with the testbed access, we've only recently granted access to that system, we're still only seeing initial feedback. We're still debugging some of the system and making sure that we have it up to scratch. However, we've seen quite a lot of interest in Beryllium itself. It obviously extends the capabilities of what you can do on a quantum computer at quite far beyond what is easily possible in other ways. At least from that perspective, we've seen quite a lot of interest in using it. We've also had an active intern program here in the offices over the course of the summer, where the interns have been using this even before it was rolled out to early access users. We've seen some really interesting things built with Beryllium, where the object-oriented nature of it has essentially allowed much more sophisticated programs than I have seen in any other programming framework to date. I guess I was going to ask a follow-on question, but you just somewhat touched on it, but you had mentioned in the script and in response to this question, just how is the progression on the libraries going? Is most of that work today being done by Horizon? Are you starting to see initial Beryllium customers beginning to contribute to those sort of open source libraries to help build that ecosystem? What I would say is at the moment, it is primarily internal to Horizon. We've only recently opened up the early access. It was towards the end of the quarter, so we're only just seeing first use by external users. In terms of building up the library's ecosystem, at the moment, that is done by re-uploading code. It's obviously something we're looking at internally to make that process as smooth as possible, to be able to really build up a community where developers can not only build libraries for their own use, but make them easily available to other Triple Alpha users. Got it. Then last question on the three applications you're developing. Can you give us some sense of what's the timeline for development of those applications? My guess is it may be sort of a rolling process, but just when would you expect to complete some of the initial work on those applications to be able to start to engage customers on those three specific use cases? What I would say on this is that this is a long-term effort. It is not aimed at having an application to sell to users directly in the short term. It is intended to give us a pathway to capture value in the company from those applications and to drive the adoption of quantum computing with quantum advantage into those industries. We are focused on three specific industries. We are not going to go into details of the specific problems we are focused on because obviously we do not want to create a lot of competition for ourselves on those problems. The purpose of pursuing these problems is not to build an application to sell. It is to achieve a real quantum advantage internally on high-value problems. That you would then sort of partner with customers to sort of deploy. It is more developing these applications that then use your software infrastructure, and long-term, that is how you would monetize it rather than sort of selling algorithms. The way we have chosen these problems is essentially to choose problems that are essentially directly monetizable in and of themselves. Our purpose in this is not to build applications to sell. It is to build applications to drive adoption of quantum computing in industries. Understood. Thank you. Sure. Thanks. Thank you. One moment for the next question, please. Our next question is coming from the line of Tanu Chauhan of Rosenblatt Securities. Please go ahead. That's actually John. Tanu is my associate, but good to listen to you guys. Joe, Greg, Katherine, congrats on your second quarter as a public company and the progress. I have a few questions. You can hear me okay? Yeah. All right, great. Calibration I know is burdensome. You have an agreement with Quantum Machines. I think that makes a lot of sense. Could you elaborate a bit on how that will work, and is there some potentially revenue generation there from an IP standpoint, or how should I think about that? Essentially, we're working with Quantum Machines to develop embedded calibration, starting with our testbed system here, Ember-1. The purpose of this is to overcome the fact that you tend to need to take systems down for a significant period of time, or rather, make them unavailable to users for a significant period of time in order to calibrate them, to calibrate the frequencies, to calibrate the shapes of the individual pulses that get sent into the processor to control quantum operation. That drifts over time. It's not a one-off process. This can drift as temperatures in your fridge shift or as there is changes in the lab environment. All sorts of changes can lead to a slightly different environment in the processor that changes the behavior of the qubits. You end up needing to recalibrate the system. What we're trying to do is avoid having to take the system offline, or at least to make it unavailable to users to recalibrate at regular intervals. Instead, what we're looking at doing is embedding that calibration so it's essentially running all the time in the background so that the system is maintaining its highest calibration. Are there opportunities to potentially derive revenue from this in the future with the network with Quantum Machines? Potentially there is, but at the moment, we're focused on getting this working with our own system first. Okay. It sounds very useful. I know people complain about that process quite a bit. You got to take the thing to a higher temperature, and then you got to cool it back down, the whole thing. Then, relative to the 256 delivery in Dublin, you've chosen the location, I think. Could you elaborate a little bit on that and when that might get delivered? Sure. The system itself is coming next year. We expect installation to start next year. We're currently selecting the location to place it, but it will be in Dublin. We're building up a new premises there. As things currently stand, we're kind of exceeding the space availability in our current office there, so we're in the process of selecting a new office location in Dublin. Of course, with that, we'll have to build out the lab facilities. Great. If you could give me one more on error correction. Sure. What are you guys doing there? I think we've talked about how some software developers are optimizing some of the machine time access to improve the level of error correction as they write their algorithms. I'm curious what you guys are doing at Horizon relative to error correction. Yeah. Error correction is one of the most important topics in quantum computing. Ultimately, these systems are very susceptible to error, we need to squeeze those errors out faster than they can accumulate. It may sound like a hardware problem, but actually a lot of it is a software problem. We've been tackling this in a couple of different ways. One of the things that we have done with opening up access to the Ember-1 system, first of all, what we have done is to start enabling real-time execution of branching programs based on measurement results, as well as the real-time evaluation of simple classical functions. That gives us many of the ingredients that you need to start to do real-time error correction rather than in post-selection. A lot of error correction experiments you see are post-selected, meaning that the error correction is not done in real-time. Instead, the encoding is done, it's run many times on a system, and then a subset of the results are picked out that have particular measurement outcomes that match the correction. In practice, you need to be able to do this in real-time. By building up that real-time execution engine to be able to run directly on our control systems, that's really starting to enable us to write these programs that can express full error correction in real-time and execute them through the control systems. The other side of this, in terms of what we're doing, one of the things we've put quite a lot of effort in that we haven't talked about so much to date has been in the development of what we call custom compilers. The intention with our custom compilers is to enable developers and to enable hardware collaborators to build their own compilation workflow using our tools. We are building towards enabling error correction through that, being able to include an error correction library for different codes and to be able to compile down into error correction codes into fault-tolerant encodings that can then be executed on hardware. Of course, where the whole industry sits with respect to error correction, it's still a very nascent technology, so it's not at the point where you have very large numbers of error-corrected qubits that can be easily harnessed, but we're pushing forward on that front. Great. Look forward to hearing more about that. Thanks, Joe and team. Thanks, John. Thank you. One moment for the next question, please. Our next question is coming from the line of Tyler Anderson of Craig-Hallum Capital Group. Please go ahead. Hi, Joe and Greg. Richard Shannon here from Craig-Hallum. Thanks for letting me ask a few questions. I guess the first one for you, Joe, is we'd love to understand the decision-making progress or process for the quantum computing hardware makers here in terms of what they need to see before deciding to work with you holistically here. Do they need to see stability and generalized abstraction from Beryllium, or do they also need to see Carbon, and/or to what degree do you need more relationships and collaborations like what you announced with Quantum Machines here? Just give us the general sense of what they're looking for. Oh, yeah. This is a great question. Thanks, Richard, and good to hear from you. What I would say is that we certainly have seen interest from hardware manufacturers well below the Carbon layer. It's not like that is the catalyst for engagement with hardware companies. Actually, we've spoken about this before, but for us at the moment, we have found ourselves more limited by the capacity of our science and engineering teams rather than demand from the hardware companies to work with us. That's very encouraging, at least from my perspective. Now, apologies. Sorry, could you repeat the second part of that question? Just not only about Beryllium and potentially Carbon, which I think you've answered here, but also the relationships with hardware makers like Quantum Machines that you announced or you talked about today. Yeah. We've had very good relationships with a wide range of hardware manufacturers. With Quantum Machines, you're starting to see that change, not just into the system builders, but also into the control plane. We're certainly starting to work with a number of control systems manufacturers as well. You were also asking about how many or what did we need to see in terms of traction with the hardware companies. I guess the question behind that is what is enough? For me, the motivation is really to build the software infrastructure that is behind as much of quantum computing software that is generating value as possible. That means we want our tools to be able to program and to be able to execute on as wide a range of quantum hardware as possible. If that means partnering with system builders, if that means partnering with control systems manufacturers, if that means partnering with other companies at different layers of the stack, we will do that to try to drive adoption and ensure that our tools become the default software layer through which quantum applications are developed and deployed. For us, essentially, we want to work with everyone. That makes sense. Thanks for those thoughts, Joe. I'm going to follow up on this general topic, sort of, and also dovetail off of one of your comments earlier, essentially talking about competition here. I think you've made it clear that you don't see anyone else doing anything near what you're trying to do here. I'd love to get a sense if you've seen any evolution in competitive offerings out there. Then ultimately, do you view any hardware partners to be using only Triple Alpha or having a number of solutions that may only offer parts of what the Triple Alpha solution offers? Where things stand at the moment, what I would say is it should be clear that the real competition is classical compute. That is what everyone in the quantum computing industry needs to compete with, not other companies in quantum computing. At the moment, the pie is just too small. We need to get to the point where software running on quantum computers is delivering real value for the users of that software. Are there other ways to program quantum computers? Absolutely. You see this with Qiskit from IBM, you see it from Classiq, you see it from a number of different companies. In terms of what we're building, we think it's significantly different from what is already out there on the market. The way I think about this actually is not so much what ways are there to program quantum computers, but what ways are there to solve the problem of going from a problem to a solution that's accelerated on a quantum computer. I think, at least the path we have been taking to try to abstract away the quantum mechanics and get to a point where we can automatically accelerate classical code, I think that is really unique to us, but there are other approaches. There's a professional services approach that's very common. There's also a kind of education-driven approach. Then there's a libraries approach, where you're essentially pre-building applications for specific tasks. There are other ways to try to solve hard problems on quantum computers, but I think the approach we're pursuing is pretty unique. Okay. Thanks for that. Just a quick question for Greg, and I'll jump out of line here. Greg, just quickly on OpEx here that you reported for the second quarter. Do you view this as kind of the baseline to go forward here? Were there any unique period costs here that aren't going to be repeated here? Just want to get a sense of kind of trajectory, particularly as we go into the third quarter. Yeah. I think this is a reasonable base level. We'll look at opportunities going forward, but this is a good base to look at in terms of expenses for the near term. Okay, great. That's all from me, guys. Thank you. Thanks. Thank you. As a reminder, if you would like to ask a question, please press star one one on your telephone. Our next question is coming from the line of [Wai Lee of StoneX]. Please go ahead. Thank you, Joe, Greg, and Katherine for the update. Great work on the progress in the [Inaudible] and Beryllium Triple Alpha platforms, the test beds in Singapore and Dublin. Let me just start with, I just want to follow up with a previous analyst. In terms of the competitive landscape, Joe and Greg, why is Triple Alpha Horizon the ultimate success versus other competitors, such as participants, as you mentioned, like Cisco, Microsoft, or Google, right? I guess, said differently, what is the competitive moat? Why is the Horizon mindset better in terms of quantum computer programming? Can we start with that? Sure. I think there's two ways to view this. One way is in terms of just the programming tools. What we have been building, we have been building from a very low level of abstraction. At the lowest level, we're able to express the, for example, if we're targeting a superconducting system, we're able to express the shapes of the microwave pulses, the explicit timing of those pulses, the frequencies of them, and so on, that go down particular control lines into the system. We're generating code that runs directly on those control systems. As we move up through the stack, we're building to higher and higher levels of abstraction. That means we're going beyond what is usually the boundary for programming quantum computing systems. Most of the time, when you're programming these systems, you are restricted to quantum circuits, for example, where you just have a fixed list of instructions that are executed, followed by measurement. If you want to be able to express error correction and fault tolerance, if you want to be able to express various different kinds of quantum algorithms and to express more complex computation, you really need to start allowing general control flow. You need to be able to start allowing concurrent classical function evaluation. By that, what I mean is classical computation that is happening concurrently with the execution of the quantum program and interacting with that. We've been building up the tools to do that in Triple Alpha. Our programming languages natively allow you to express anything a mature quantum computer should be able to do. That really allows us to go beyond what a lot of quantum programming systems are even able to express. That also means that we have had to be very early in terms of starting to build essentially systems software for quantum computers. When you're producing a quantum circuit as the end point for your program, for your compilation, then you don't need to worry about assigning memory dynamically, for example. You can work out where all of the qubits are placed before you ever execute the program. As soon as you start to introduce general control flow, you start to introduce loops and so on, then you need to start thinking about how am I going to allocate memory on the fly as the program is running, because you can't pre-allocate it, or if you do, you're going to run the risk of running out of memory and having huge overhead. We've had to start building up these capabilities, building up the logic to dynamically allocate memory and to manage IO and other kinds of system software services in our software development tools. We're early on that. At the highest level, as we push up to higher levels of abstraction, and frankly, I think we're spanning a range that is broader than pretty much anyone else out there. As we push up towards the higher level of abstractions with Beryllium, we start to get to a place where the quantum mechanics itself can start to be abstracted away without losing generality, without using the flexibility to write programs to do whatever you want. As we push towards Carbon, as we push towards the automatic acceleration of code written for conventional computers, that gives us a solution to how do we enable domain experts in the various industries that stand to benefit from quantum computing to harness quantum computing without having to become quantum computing experts themselves. That, I think, for us, is creating a complete chain from developer intent to accelerated quantum application running on hardware. That goes beyond what is available other ways. That makes sense. Thank you for the detailed response, Joe. I'd like to follow up on the Beryllium. We understand it's entering the early access phase, right? Then eventually, you're letting certain users to build out the library. It makes sense to me that your intent to allow developers without deep quantum expertise to build applications, right? In terms of your success factors, right, what do you and Greg view as success? Let's say over the next 12 months, should investors be focused on developer count, the number of pilots? I know you say you guys don't do POCs right now, right, or production workflow or some other KPI metrics that help us guide us that, hey, Beryllium is a success going forward in the next 12 months. There's two specific things we point to. One is integration with partners. We're working to establish more collaborations with hardware companies as we go along. We've had pretty good success on that front, as I say. At the moment, we are more limited by the size of the internal team than we are at demand for collaboration. The other side of this, I would say, is execution against our technical roadmap. We have set out a number of milestones in the F-4. We've been, I think, pretty good at hitting those to date. I would certainly hope that we continue to do so in future. Of course, this will transition to a point where we take Beryllium out of early access. At the moment, it's only with a relatively small group of early access users. We'll continue to expand that to start to build up a developer ecosystem. At the moment, it's still quite small. We're still pushing development, still pushing integration with hardware partners. Thanks for that, Joe. To end it off, I wanted to ask Greg on a financial question. It's good that you guys worked to exercise, you fortified your balance sheet, I think $115 million, right, in cash balance. You got to really prudently managing the resources as you develop the platform. I want to pick Greg's brain on in terms of the balance between your capital allocation, accelerating investment efforts to speed up development timeline, M&As, and other things, right, with that cash balance. That's all I have, gents. Thank you for that, and great results. Okay, great. I can let Joe weigh in. I would say that our strengthened balance sheet gives us more flexibility to consider various initiatives. I think we'll be very careful. We want to manage this cash until we get to cash generation. Yeah. We certainly intend to be responsible with the cash burn. Of course, there's a tension between how much you invest in R&D and how long you can maintain runway for. For us, our focus, I would say, is primarily internal in terms of enabling the research and development within the company. We have a pretty solid team already. Something like M&A, I would say, is not going to be a primary strategy for us. Occasionally, there will be opportunities that make sense, it's not the primary strategy for us. The primary strategy for us is driving the internal team. Joe, it doesn't sound like demand is an issue, right? You have more demands than your available talents, right? I know it's hard to find the PhDs or the advanced degree engineers, right, to do the work, right? Does it make sense to step on the gas in terms of investing internally on the talents, I guess? It certainly does make sense to invest in the talents, but at the same time, what's really important to us is getting to a point where there's a real quantum advantage. Part of that is on us, and part of that is external to us. In some sense, you need the quantum hardware to develop at the same time that the software is developing. There's a pacing question there. From my perspective, we need to be very thoughtful in terms of how we pace that burn because we don't want to burn through our runway before getting to a point where the hardware is ready to actually yield a real advantage. At the same time, we don't want to be too slow either. We don't want to miss that window either. It's really a case of calibrating spend on R&D so we hit that at just the right time with the right momentum. That makes sense. Patience. Thank you very much, Joe and Greg and Katherine. Have a good one. Great. Thanks. Thank you. There are no more questions in the queue. I would like to turn the call back over to Joe for closing remarks. Okay. Well, I'd like to thank you all very much for joining us today. As I said earlier, with the release of Beryllium to our early access users and the opening up of our testbed system, Ember-1, to first users, we really believe we're tracking well against the milestones we set forth in the F-4. The establishment of our internal applications team is going to give us a way to drive forward progress internally to inform our decisions in terms of how we build our software infrastructure, how we build our software development tools to really try to get to a real meaningful quantum advantage. We're looking to harness the latest advances in AI in accelerating that. Finally, the good news this quarter has been the exercise of the warrants that has yielded at Sorry, excuse me, at $27.5 million in gross proceeds, which really significantly strengthens our balance sheet. With that, thank you very much for joining us, and I'll leave it there. This concludes today's program, and thank you so much for joining. You may now disconnect.