Thank you for standing by and welcome to Horizon Quantum's third quarter 2026 conference call. Currently, all participants are in a listen-only mode. After the speaker's presentation, there will be a question and answer session. To ask a question during the session, you will need to press star 1-1 on your telephone. To remove yourself from the queue, you may press star 1-1 again. I would now like to hand the call over to Katherine Bailon. Ma'am, you may begin.

Good morning and thank you for joining us on Horizon Quantum's third 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 CFO. Before the market opened today, Horizon Quantum issued a press release with results for its third quarter ended September 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. with the meaning of U.S. Federal Securities Law, including the Private Securities Litigation Reform Act of 1995. You were cautioned that these statements involve material risks and uncertainties, including the risks Horizon Quantum has identified in its most recent annual report on Form 20F 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, November 10, 2026. This discussion includes non-GAAP financial measures. These measures are calculated by management and do not have any standardized meanings 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 the table at the end of our earnings press release issued this morning. This week, our investor conference attendance will include are CEO and CFO at the Cantor Convergence Conference in Miami, Florida, where Joe will participate in a panel moderated by Cantor Quantum Analyst Tori Jensen titled From Chip to Code, Building the Full Quantum Stack. We will also host one-on-ones. The following week, Horizon Quantum CFO Greg Gould will attend the Craig Hallam Annual Alpha Select Investor Conference in New York City, where he will host one-on-ones. And with that, I'll now turn it over to Horizon Quantum founder and CEO, Dr. Joe Fitzsimons.

Thank you very much, Catherine. I want to thank you all for joining the call. We've continued to build momentum in the third quarter, and I want to highlight in particular continued technical execution and in particular on hardware integration and characterization. And I'm going to focus more on characterization in particular in this call. We're also laying the groundwork for strategic expansion with a letter of intent with Entropica Labs, which I'll turn to in a few minutes. We remain laser focused on our mission to unlock broad quantum advantage by building software infrastructure that abstracts away the complexities of quantum mechanics. And we really believe that tight integration between hardware and software is key to unlocking quantum advantage and gaining utility across modalities. In terms of the R&D and operational highlights for Qtree, first of all, I wanted to call out our work with OQC to integrate their Toshiko 32-qubit QPU with Triple Alpha and enable pulse-level control of that processor. That opens up the possibility for developers to start implementing characterization experiments, including qubit relaxation, so T1 experiments, T2 experiments that measure phase coherence, true triple alphas, pulse level control. This also allows developers to take those experiments, those characterization experiments, and wrap them up in a web API so that they're able to integrate those experiments into programs written into standard computer programming languages. We really believe this will be very useful for developers going forward in harnessing the capabilities of triple alpha and of pulse level control on these processors. Another area we've seen significant progress in is in terms of developing new protocols for hardware characterization that scale very well as the number of qubits in a processor increases. So in particular, we have been extending some work we previously did on multiplexing characterization for what's called ZZ crosstalk within a quantum processor. And what that is is essentially is unwanted interactions between qubits within the quantum processor itself. This tends to be an issue in superconducting processors, for example. We've extended that and implemented it on a 100 qubit plus processor for the first time, in particular Rigetti's 108Q Cepheus processor. Being able to do multiplex characterization means that we're able to take experiments that would otherwise have taken a very large number of runs to characterize the interaction between individual pairs of qubits. So for the 108Q processor, that would be more than 5,000 different experiments that you would need to be able to make. and we've been able to multiplex them to be able to do them with only seven distinct experiments. So this is really a massive reduction in the number of experiments you need to run in order to obtain this data from the quantum processor. And being able to do that allows us to gain a much better understanding of what is actually happening in the processor. So our team have implemented this both on the Regetti Cepheus 108Q processor to characterize ZZ crosstalk as well as on our own Ember One testbed system in order to characterize what's called control crosstalk. Control crosstalk is essentially when the signals being used to drive a qubit within a processor affect other qubits in the system. This is an effect that's not generally documented in the specs of a processor. It depends very much on the wiring of the system and other physical factors related to the processor and to the entire setup. And as with the ZZ-Questhook, we've been able to do this in a multiplexed way where the number of measurements we need scales only with the logarithm of the number of qubits in a system. So normally, these kind of experiments would scale linearly or quadratically in the number of qubits. And by being able to reduce those to only logarithmic scaling, it opens up the possibility of being able to apply these protocols to characterize extremely large processors. So, for example, when I talk about a reduction to only seven distinct experiments for a 100 qubit system, that would go only to 20 for a million qubit system and to 30 for a one billion qubit system. So as you can see, these scale very gradually and really open up the door to being able to characterize much larger systems in the future as they become available. We have tested our characterization techniques by validating them against pairwise experiments. So this is basically taking the gold standard experiment for characterizing the interaction between one qubit and another or the control crosstalk between one qubit and another. and measuring it directly and comparing that then with the results of multiplex characterization. And we've seen very good agreement between those two. So we feel that this is very good validation of the approach. And although what we have focused on in the current quarter and there's a blog post up later today that discusses this, although this is focused on superconducting processors in particular, the techniques we've developed are much more broadly applicable and we expect to be able to make use of similar techniques across many other modalities going forward. I want to turn now to corporate updates and in particular to the fact that we have entered into a letter of intent to acquire Entropica Labs. The letter of intent is non-binding. The anticipated consideration for the transaction will be $27 million. dollars of Horizon Quantum Class A ordinary shares subject to completion of due diligence, related audits, signing of the definitive agreements, and the satisfaction of other customary conditions. We believe there's a strong technical synergy with Entropica Labs. We have worked closely with the team over the years. They've been early users of both Triple Alpha and our Ember One testbed. and we have experience working with them previously, myself and Si-Hui both worked with Tomaso in our academic careers. In particular, we feel the focus Entropica have on error correction and fault tolerance is a very natural part of the software infrastructure as we see it and so there's a very natural fit between the two companies. Turning now to the financials, at the end of Q3, cash and cash equivalents stood at $102.8 million. That's a net decrease of $10.5 million from the end of Q2, reflecting ongoing investment in research and development and scaling. I want to give you some context. On this, in particular, because there is a reported net income of $33.4 million, I want to clarify that that includes $43.1 million non-cash gain resulting from the remeasurement of warrant-related derivatives liabilities due to a decrease in share price. I want to emphasize, again, that the gain does not affect our cash flow, and I want Thank you, Joe, and good morning, everyone. I'd like to start off by reviewing our financial results, but before I do, I'd like to mention that all the financial results to be discussed are in U.S. dollars and are approximate.

Total operating expenses for the third quarter of 2026 were approximately 10.5 million dollars compared to 4.9 million a year ago. Increase in operating expenses was largely the result of increase in hiring primarily in our science and engineering teams as well as the transition to being a public company. 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 test bench. For the third quarter of 2026, R&D expenses increased by approximately $2.4 million, or 122%, to $4.5 million to $2.0 million in the third quarter a year ago. Excluding share-based comp and non-recurring comp adjustments, the period-over-period R&D increase was 57%, and attributable to increases in headcount and, to a lesser extent, hardware test bed set-up costs. For the third quarter of 2026, sales and marketing expenses increased approximately 16% to $0.43 million, and G&A expenses for the third quarter total $5.2 million, increasing $2.9 million from $2.3 million in the third quarter a year ago, excluding share-based comp, non-recurring compensation adjustments, and one-time business combinations Expenses of approximately $2.1 million and $1.2 million from the third quarter of 2026 and 2025 respectively, G&A increased 182% period over period. This increase was primarily due to the increase in headcount and other operating expenses associated with the transition to becoming a public company. For the third quarter of 2026, our last from operations total approximately $10.5 million, an increase of $5.6 million or 116% from a year ago. This increase was primarily due to hiring staff across the company, including scientists, engineers, as well as staff supporting the public company compliance. The company reported net income of $33.4 million or $0.61 per ordinary share for the third quarter of 2026, and that compares to a loss of $5.2 million or $0.13 per ordinary share in the third quarter of 2025. Third quarter results included, as Joe mentioned, a $43.1 million non-cash gain from the re-measurement of warrant-related derivative liabilities. The decrease in the company's share price during the quarter decreased the fair value of these liabilities, resulting in the accounting gain. As Joe mentioned, this did not affect the company's cash balance. I'd like to point out that all public and private warrants of Horizon Quantum that remain outstanding will continue to be remeasured at fair value each quarter. Accordingly, future adjustments 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, we also evaluate results on an adjusted EBITDA basis, which is a non-GAAP measure. Adjusted EBITDA excludes changes in fair liabilities as well as share-based compensation and non-recurring expenses associated with the business combination. On this basis, the company reported an adjusted EBITDA loss of approximately $6.3 million for the third quarter, and that compared to a loss of $3.0 million in the third quarter a year ago. Our cash position stands at $100 million as of September 30th, and that compares to $113.3 million at the end of the June quarter. In terms of employees, we ended the third quarter of 2026 with 60 full-time employees versus 42 at the end of the second quarter, at the end of the third quarter a year ago, reflecting a 43% increase period over period and a 5% sequential increase from the June quarter. Historically, science engineers and other technical staff represent between 60 and 80% of the total headcount, and we remain within that range as of the third quarter. Going forward, we expect this mix to remain consistent. Now, in terms of cash flow, net cash used in operating activities for the third quarter of 2026 was approximately $7.2 million, and that compared to cash usage of $3.3 million in the third quarter of 2025 and $5.1 million in the second quarter of 2026. The bulk of the period-over-year increase in cash usage was due to growth in headcount expenses, and the expenses associated with being a public company. For the nine months ended September 30th, 2026, net cash used in operating activities total approximately $16.4 million versus $7 million for the first nine 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 or POC 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 through transitioning early access users to paying customers on a cost per use or either on a cloud or on-premise basis 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. Finally, I'd like to share our cash balance, which stood at $102.8 million at the end of September. Since we are a software company, our model is a capital one. We believe our current cash balances provide us with significant runway as it is our intention to proceed during this pre-routing period with fiscal discipline and rigor. With that, I'll turn it back over to Joe.

Thanks very much, Greg. Before I bring this to a close. I wanted to leave you all with a few thoughts in terms of our progress this quarter. In particular, I wanted to focus on integration. Our work with OQC demonstrates the ability to integrate Triple Alpha at the pulse level with different hardware providers, allowing really granular control of hardware that's going to be really critically important to being able to more and more precisely characterize these systems and get more out of the hardware systems themselves. We really believe that tight integration with hardware is key to getting to a quantum advantage as soon as possible. I also wanted to turn to scalability. Our new multiplexed protocols for characterization really open up the possibility of characterizing some of these hard to measure properties even on very large scale systems. So I talked about ZZ crosstalk, I talked about control crosstalk, but there's many other types of characterization you may want to do with a system to understand the imperfections in that system or how the physics of the system requires you to control it slightly differently than you might think in the abstract. Being able to harness this on larger and larger processors allows us really to gain insight into these processors and try to squeeze more performance out of them. And on the strategy side, we have entered a letter of intent with Entropica Labs, as I mentioned before, and we really think this is an important step towards strengthening our capabilities in error correction and fault tolerance. With that, I'm happy to take your questions.

Thank you. As a reminder, to ask a question, you will need to press star one one on your telephone. To remove yourself from the queue, you may press star one one again. Please stand by while we compile the Q&A roster. Our first question comes from the line of Quinn Bolton of Niedermann Company. Your line is open, Quinn.

Hi, Joe. Hi, Greg and Katherine. Congratulations on all of the work this quarter. Joe, I wanted to start just with the acquisition of Entropica Labs. Can you give us a sense of how you would integrate Entropica into Triple Alpha, what the Entropica quantum error correction capabilities brings to the Triple Alpha solution?

Thanks, Gwen. So that's a really good question. We have been thinking a lot about how to integrate full-tolerant compilation within our own pipeline. We have been working on what we call custom compiler layers. And what they allow is for developers to essentially build their own compilation pathway. So this fits pretty naturally into the idea of doing something like taking compilation and compiling it to measurement-based computation or fusion-based computation if you want to deploy it on a photonic system, for example. But you can also take the same kind of approach and use it to do fault-tolerant compilation. So if you think about the steps that are needed in something like that, you would need to compile your program, first of all, into a discrete gate set because the full tolerant gate sets are always discrete, so you don't have continuous rotations. Generally, you have something like Hadamard T-CNOC gate set, something like this. And when you compile to that gate set, you then have to encode those operations into error correction codes, and that's something that Entropica have been working a lot on, on building up the kind of basic building blocks for various error correction codes. You then need to take that along with the decoding algorithms and you need to compile that down into something that actually runs on hardware and again that's where the triple alpha stack comes in and we've had good success on working with Entropica already in starting to collaborate on compilation that goes through both of our systems and so it's something we've generally seen positive signs from so far, but still at a very early stage. So probably a little bit early to go into specifics too much on.

But it sounds like it's sort of at a higher layer of triple alpha where it's sort of helping define that, I guess, the gate setter, the gate required for fault-tolerant computing. And then once you've got that sort of, I guess, circuit set, Triple Alpha would then be able to compile it down to the hardware level for deployment on a specific hardware platform.

Is that the right way to think about it? We're on both sides of this at the moment. So Triple Alpha at the moment allows you to express your program in a high-level programming language and compile it down to a full-tolerant gate set. We have gate synthesis and so on, so you can compile down to Hadamard T, CNOT, or another full-tolerant gate set. Now, there is a missing step where that would need to be translated into operations on an error, well, into encoded operations. But once you've done that, you're left again with a kind of high-level quantum program that you now need to compile all the way down and execute on hardware. Importantly, that program itself is not a circuit. It contains classical processing and quantum processing that are interacting. You need to be able to extract what are called syndrome measurements in order to detect what errors have occurred during your computation. You need to be able to classically process them through a decoder which decides what error has occurred and how to fix it. And then you need to be able to apply that correction back on the quantum system. And that's something we have a lot of expertise in. We've built Triple Alpha specifically to allow developers to go beyond circuits to be able to express these kind of interacting classical and quantum computations. And we've been building up the kind of runtime capable of doing that to run on the control systems themselves. And that's something we've been demonstrating with our Ember One testbed. So we're really on both sides of this. The place we haven't focused to date is on the encoding into specific error correction codes. And that's something where Entropica has done a lot of work.

Got it. And then just looking at the characterization work you discussed with OQC and Ember One, you mentioned that some of these, I guess, techniques could be applied to other modalities. Maybe at a high level, how do you do that? It looks like a lot of the characterization work you've done to date has been on superconducting. Obviously, different modalities, you know, may have lasers, may have different control systems, so... What parts of the characterization work do you see being applicable to other modalities?

Yeah, so I want to separate two things here. The work we've done with OQC is really on pulse level integration with triple alpha, and that's allowed us to start doing basic kind of characterization experiments. We haven't run these multiplexed experiments on the OQC system. There's nothing that would stop us from doing it, but we just have not done that at this point. Our demonstrations have been on the Rigetti, CFIUS, and we've run on ICATRI and some other systems to do those multiplex protocols. In terms of how broadly applicable they are, the particular characterization So ZZ crosstalk is something that is somewhat particular to superconducting systems. A lot of these depend on the processor itself, on how the qubits are laid out, on many different things like this. But the same approach can be used to detect any kind of spurious interaction. So if you have qubits in the system that are interacting with each other that should not be interacting with each other, you can detect it with very similar techniques. What's underlying all of what we've done on this is basically a very general recipe for taking an experiment to characterize a pair of qubits and being able to multiplex that so that we can basically do what look like random measurements across the entire system and then extract the results for all possible pairs. in a way that scales only logarithmically with the number of qubits. So there's nothing about that that is particular to superconducting qubits other than the particular characterization experiments we've chosen to multiplex and test. One of the reasons we focused on superconducting systems is because we have low level access to a number of superconducting systems. So we're able to do this characterization directly in a way that if you were restricted to gate level access, It will be harder to do.

Understood. Thank you very much. Sure.

Thank you. Our next question comes from the line of Richard Shannon of Craig Hallam. Your line is open, Richard.

Well, great. Thanks, Joe and Greg, for letting me ask you a couple of questions. The last question here in characterization is, Interesting, although a little detailed here for me to understand completely, but maybe I'll extend one element of the Q&A here on this topic here, Joe, by asking, especially when you said that you have access to a number of, low-level access to a number of superconducting systems, I'm wondering to what degree you intend to do this with other modalities here, and I guess specifically with the INQ system you expect to have in place sometime next year. and or other modalities, to what degree are you going to continue or press forward with that kind of work?

Oh, yeah, that's a good question. So, I mean, the reality is quantum processors are currently imperfect. And if you can understand those imperfections, sometimes you're able to mitigate their effects. So in the case of The ZZ crosstalk on the Cepheus processor, for example, what we were able to do is look at, okay, we know there is, we've been able to measure crosstalk between different pairs of qubits. Can we divide them into different sets and then try to mitigate that error between sets or mitigate that unwanted interaction between sets? I should say, none of this is criticism of any processor. This is true of essentially all processors. So what we were able to do is use that characterization to split the qubits in the processor into two groups. And then basically what we do is periodically flip the groups, just applying a Z gate. So flipping zero to one and then back again. And that has the effect of essentially canceling out the effect of that interaction between those two groups. So using the characterization, we're able to see what's the best way to do this cut? What's the best way to divide them into two groups? If we didn't have the characterization, we'd be guessing on that front. Now, you asked about what's our intention to do this going forward. Generally, I believe until we're in a regime where we have access to essentially perfect qubits, There's still quite a lot to be gained from understanding how interactions are happening in the system itself. Any unwanted interaction or any source of noise in the system that can be cancelled in software is a good thing. So being able to understand that, being able to squeeze more performance out of the system, I see that as an important thing for getting the most performance out of any particular system, no matter what the modality is. and yes, absolutely, we would envisage trying to optimize our control in terms of how we express our programs, how we take advantage of the hardware for as much of the hardware as possible going forward.

Okay, Joe, thanks for that detail. My second question is related to Oxford Quantum here. I guess I'd love to get a sense of the work that you've been doing with them in terms of, you know, how long has this been going on? Are there next steps here? And then also, I guess, to understand the degree to which you can disclose or characterize, you know, the other hardware partners you may be working with to kind of get a sense of that pipeline as well.

Sure. So, I mean, in terms of where things have gone, with OQC, we've been I've been working with them for a fair amount of time. This is our first demonstration on the system in terms of being able to integrate pulse-level control with it. There are future plans in terms of that relationship, but I'm not really ready to go into any of the details of them at this point in time. In terms of the list of partners we work with, we've been disclosing these in press releases as we're ready to announce as we're ready to announce the partnerships so that you and your colleagues can have visibility into what's going on with us. In particular, last quarter we announced a partnership with Quantum Machines, for example, where we're working again on characterization, trying to be able to do real-time characterization as our system is up and running so that we can kind of do continuous characterization during the uptime of the system rather than at discrete periods. So we have a number of different partnerships going on, both with control systems companies as well as with system builders. And these vary in complexity from things like these kind of characterization experiments to the full stack in terms of being able to go from very high level quantum programs down to full deployments on the hardware.

OK, fair enough. I want to ask that question to see if you disclose anymore, but certainly understand we'll be looking forward to announcements in the future. Maybe one last quick question for me, Joe. And that's about Beryllium. I don't think I heard anything regarding an update there after the early access. So I wonder if you had any updated feedback from that. Thank you.

Yeah, we've been working way hard on Beryllium. In particular, with our entire compiler stack, we've been putting in a lot of effort to increase the compile speed and the and the user experience for debugging as well. It's kind of an interesting paradigm because a lot of developers these days are used to programming in Python. And Python's essentially an interpreted language. So when something goes wrong in the program, you get the full stack trace and you can understand what has gone wrong and you can debug quite easily. Whereas if you look at a compiled language like C, for example, that's much harder. You get a segfault and you don't necessarily know what went wrong. And beryllium is somewhat like that because there are some errors you can only get at runtime, meaning that it fails during execution rather than at compile time. And it is essentially impossible to determine at compile time whether a program will run will run successfully to completion because this gets you into a kind of halting problem situation. So it's a kind of undecidable problem even in theory. We've been putting in a lot of effort to build debugging tools to make it easier for developers to figure out when there's an error in their code to be able to trace it back, figure out what line that has happened on, and really build up that debugging experience to make it easier to debug these really complex programs that are utilizing control flow, that are utilizing mid-circuit measurement, and so on, that you can't just work out as a circuit ahead of time. So that's what our focus has been on essentially this quarter in that regard. And we would certainly hope to be able to have more to say later in the year on this.

Great. Thank you for the update, Joe. That's all for me. Sure.

Again, to ask a question, please press star 11 on your telephone. Our next question comes from the line of Yi Hu Li of StoneX. Your line is open, Yi.

Thank you for taking my questions. Good evening, good day, Joe, Greg, and Catherine. So two technical questions for Joe and one financial. Let's start with the software collaboration, Joe. Like, we've seen progression. with hardware partners that ultimately end with the Triple Alpha becoming the default software layer in the platform. You know, this quarter we've seen OQC now achieving post-level integration alongside with like collaboration with Quantum Machines, AQT, Alex and Bob and IIT in the past. So the question is how far you up the integration ladder you are today and what needs to happen, Joe, for like a partner, you know, to become technically or commercially, you know, to collaborate with Horizon, whereby Triple Alpha is the default software stack. I just want to get an understanding of that.

Sure. So the way we think about engagements is that various different possible levels of engagement. So, I mean, you can start from the basis of no engagement at all. And then above that, you have a situation where we are able to integrate hardware from a particular vendor into our stack for our use and for their use, for example, but not able to offer it to other users of Triple Alpha. Above that, you have the, you know, let's call this Level 2, where we are able to give access to those systems to other users of Triple Alpha. So we've integrated the hardware and it's available for other users of our system to be able to make use of. Above that, you have partnerships, let's call them level three, or collaborations where we are working together to solve meaningful technical problems in relation to those systems. So that can be all sorts of things. It may involve figuring out compilation problems as part of this. It may involve higher level programs and being able to resource count them on particular processors, being able to compile them for particular processors and so on. And those are really to build confidence with the hardware companies. Then level four above that is when we start to be in a position where those hardware companies are able to offer Triple Alpha to their users. And level five then for us would be becoming the the default software, essentially the default software there for particular systems. At the moment, we tend to announce partnerships when they're at about what I would call level three or level four of this. We're starting to have level four language in a number of the contracts We're not ready to announce any level five partnerships at this point. So that's still a little while off.

Thanks for that. Thanks for that, Joe. Second question is like the ZD cross talk application. This seems to be a very good headway development. So, you know, understanding like it's you're reducing the experiment needed to characterize cost talking I think 100 plus cubic processor from I think from your PR is like 5,000 to about seven. It looks like it does have tangible software value. So our question is how portable is this capability across hardware platform and could it be a monetizable product or is it something that helps Triple Alpha become that software layer for those hardware partners?

Yeah, so I think it's the latter, really. We see our work on characterization as a way to build value with the hardware companies to be able to get more out of their system than potentially other platforms are able to. We want to be able to get the most out of quantum computers we possibly can. So that's why we put in this effort. We want Triple Alpha to be The best way to program essentially any kind of quantum computer. Now, you asked about how portable they are. And I guess this goes back to Richard's question as well. The reality is that the low-level physics of the device is different across different modalities. So the ways in which it can differ from just an abstract model of perfect qubits that interact exactly as the gates are supposed to, are different for different modalities and even for different processor architectures. However, where we have put in the effort is on developing techniques to multiplex very general types of experiments. Now, we've done it in particular for specific types of experiments that are relevant to superconducting processors in particular because we have pulse level control of quite a few superconducting processors. So it allows us to test across a range of processors quite easily. So that's why we kind of go there first. The techniques themselves though for multiplexing two-qubit characterization are extremely general. So they're not tied into only ZZ crosstalk or only control crosstalk. We can essentially multiplex the, well, essentially any two-qubit characterization experiment using similar techniques, or at least we would expect to be able to. So we don't think this is particular just to superconducting qubits. We would expect to be able to do very similar things across a wide range of modalities.

Okay, so it's extremely flexible. And then my final question is more financial related. I think it's $102, $103 million left on the balance sheet, Greg and Joe. You know, obviously you have Entropico, right, $27 million. Cash burns about 10.5 this quarter. I was wondering, like, can you give us an update on the financial sources and uses, right? Should we expect once the Entropico closes, Cash Balances, whatever the 102, less the 27, and your go-forward burn rate, just because you have more people, more resource on your payroll now. Thank you very much, guys.

Sure. So let me, I want to point out that there's a, I want to point out that the deal with Entropica, the letter of intent, is non-cash. It's inequity. So it's in Horizon Class A shares. so it won't affect our cash balance. So the main effect on us will be the impact of salaries. So purely from a headcount perspective. I can turn over to Greg for further commentary.

Yeah, Joe, that's exactly right. The main driver of our headcount, keep in mind that we are, in addition, paying for the new quantum system. And so that will go through the cap periodically. So keep that in mind. The $6.3 million burn from an adjusted EBITDA basis is more similar. Think of that as more of a basis. Thank you very much.

Thank you. I would now like to turn the conference back to Dr. Joe Fitzsimons for closing remarks. Sir?

Well, thank you very much for joining us. I think we've had a generally a pretty good quarter in terms of making advances on the technical side. I'm really excited about the work that has been happening on multiplex characterization, you know, and I look forward to seeing how things will pan out within Tropica Labs. So thank you very much for joining, and I'll leave it there. This concludes today's conference call.

Thank you for participating. You may now disconnect.