Guaranteed Solana TX Inclusion with Raiku, feat Robin, Founder and CEO of Raiku

Speaker A: Foreign.

Speaker B: Hello. Welcome to yet another episode of the Soul Fate podcast where we chat with founders and builders in the Solana ecosystem. And sometimes not the Solana ecosystem. But today was another Solana focused episode. We talked with Robin, the founder of Raikou. Uh, I'm probably going to use the wrong terminology to describe this, but network extension type. Type work. Right. So, uh, Raiku is basically, you know, building a system to improve the coordination, uh, on Solana so that transactions can get included faster, um, can be guaranteed ahead of time so that you can know for a fact that you'll be included. Right. All kinds of things that are required for, uh, performance systems. It honestly seems really, really cool. They're in Testnet right now, so little bit TBD on how it behaves in the wild, but, uh, really fascinating conversation.

Speaker C: Yeah, it was really, really great. Um, impressive. Uh, I think of what they're doing, uh, they're definitely solving like we allude to in the episode. There's this inclusion problem that happens on the Solana blockchain. Generally users don't experience it with their transactions, but once there is like intense network congestion, it becomes apparent the Anza and Firedancer core engineers making tons of improvements and trying to solve these problems, but having these types of, uh, extens. Sidecar type flows, like Jito, like Raku. Um, I think it's very, very interesting. Um, super excited to see where Raku goes.

Speaker B: Yeah. Um, before we jump into the episode, quick shout out for Unboxed. Unboxed is a dev shop that I've been running for the last decade. If you've got any software needs, um, feel free to reach out@beyondboxed.com or reach out to me on Twitter. We, uh, do a lot of zero to one work, um, for founders and companies that are trying to bootstrap new products. So reach out if that sounds interest to you. We're always here to help. And uh, Nick, you want to, you want to plug your.

Speaker C: Let me, let me chill. I have a new project, a new company. I'm leaving Solana foundation and go to used decal.com to find out more. Join the wait list. Get some alpha.

Speaker B: Nice, Nice. All right, let's jump into it.

Speaker C: Nothing in this podcast is or should be considered financial advice. Any opinions and thoughts expressed are solely those of the individual. They do not represent the opinions of any entity. Enjoy.

Speaker B: I want to start off by hearing the elevator pitch for Raku what you guys are building, but then I'd love to pivot and hear more about you personally, Robin. So maybe just tell us the 60 seconds or so about Raku and then we'll have sort of more personal discussion and then go back into Raku and go more in depth.

Speaker A: I'll keep it short and sweet. Raiku is making applications on distributed networks. So Solana in our case as ah, fast, powerful, scalable as any traditional systems. And we do this by rethinking how applications are built from um, first principles and how users are interacting with those applications. So basically make crypto apps as competitive as they can be. That's the only way we can really make sure that all the applications and users can benefit from the crypto that uh, we, we love today. Right. So that's what we're doing.

Speaker B: Okay, so Raiku is building technology that sort of rethinks the crypto, the crypto experience so that you can get the best of both worlds. The, the decentralized, trustless nature of blockchain while also being as performant as maybe like a Web2 system.

Speaker A: Exactly. So historically the way applications have squeezed the juice in order to be performant is let's take hyper Liquid as an example. You have a fairly limited um, validator set which um, is operated by limited people. And it's, it, it's really its own sandbox. Right? It's a sandbox environment. Um, it hasn't really been possible to create uh, the similar type of trading experience that you get on HyperLiquid directly on L1s for obvious reasons due to the main limitations of L1s in itself. Um, you can only get information to propagate as quickly uh, on an L1 that physical laws really uh, allow for. Right. But even if you get it down to let's say 120 milliseconds, uh, that's kind of the bedrock. It's not going to get much faster. 120 milliseconds compared to traditional systems is shit. It's really slow. Um, so how can you solve for that? Right, so L1s, they have fundamental limitations. Um, and historically L1s, they haven't been able to optimize for um, where the transaction uh, originates in the world. Right. Solana is trying to do this with multiple concurrent leaders. Alpenglow will also obviously help uh, to reduce the overall uh, time frequency and time games on the L1 in itself. But still you hit the same issue and L1 has fundamental limitations. So.

Speaker B: Yeah, got it, got it. Well I, I'm super fascinated to dig into sort of the how of, of all of this, but I do want to do a quick uh, Maybe like what is your background? How did you get into blockchain in general? And how, and more specifically how did you get into, into this? How did Raiku come to be that sort of thing?

Speaker A: I um, I've been in crypto since 2015. It's, it's been a while. Seen a lot of cool projects, mostly worked in Ethereum. Um, my interest uh, when I started was on how we can tweak different uh, incentive mechanisms to reach consensus faster. Uh, so I started doing mostly research work in a project called Hyperledger. So pretty much the corporate version of Ethereum led by um, Linux foundation and IBM, um, worked with end to end teams on Ethereum that led up to the defi summer. That was a great experience. So you could really see the entire industry and ecosystem taking shape. Uh, but at the same time throughout that process, um, that's when L2 started to take shape and okay, we need to scale the underlying L1 because it's just too slow. Um, and we thought we had the answer with L2s. Ah but that led to so many other problems that we see today, right like state fragmentation, incentive misalignment, user fragmentation issues and you know, not optimal. Um, so been in Ethereum for six, seven years. Uh then I joined uh, Solana, the light side or the dark side depending on how you look at it. Uh, at the end of 23 it's. So Riku started as a research project with a very simple idea that was primarily based on uh, um, proximity of computation matters. So basically you want your transaction or your event to be computed and actioned close to where you are. That most likely means that you are having an off chain uh, uh component. Right? But an off chain component is underlyingly limited by the limitations of the L1. And if you put an off chain component on an L1 which is slow, not great. So the idea was okay, let's explore what this would look like on an L1 which is fast. So I started to look into uh, Aptos, Sui, Solana and Solana stood out for many different reasons. Um, but that was kind of the journey and all of this was started by a lot of frustrations that I'd seen in uh, primarily Ethereum. And I mentioned uh, uh, some of them got it.

Speaker B: Uh, what were those reasons that stood out to choose Solana over the alternatives at the time.

Speaker A: So this for context this was November 23rd. So at the time it was also really bad bear market. Like literally nothing was going on. But Solana ah, at the time had reached a good state. Of tech maturity. So the underlying protocol was really advancing. You could see that the core uh, developers was pushing updates like literally every second week. Fantastic. Right. Um, there was also a clear pros and cons there. True, you know, pros and cons, that's for sure, you know, move fast and break things. But anyways, the overall tech majority was getting there. Don't uh, get me wrong, there's still a lot we need to work on, uh, but we're doing that. Right. Um, but more interestingly, uh, there was a lot of applications in the ecosystem that was naturally gravitating towards this edge computer extension idea, but no one really knew how to, to do it. Um, and for context, uh, edge computer extensions is primarily a concept of off chain compute to make a process just much more efficient. And then you use the underlying L1 Solana as the base of truth. Right. So there was a lot of projects back then that was naturally gravitating towards this to make their app a lot more market competitive, to facilitate for new markets, uh, such as a perp Dex for example. But all of them had the same issue and that was how do you do that on Solana? Because historically we've seen off chain compute and external components on other ecosystems and the most prominent one is Ethereum. So what ended up happening back then was that projects took frameworks, overall solutions that was made for another network, another ecosystem and uh, was kind of force fitting it into the context of Solana, uh, which doesn't lead to optimal results. The third factor that stood out was the user base. You could see that it was growing and it was growing fast. I think between 2023-25 the developer Mindshare have gone up like 18.5x, like an insane amount. Uh, so user base and developers was just flocking uh, to Solana. So you could clearly see uh, that this is the future. Uh, that's why it stood out.

Speaker C: Yeah, it's interesting to hear you say some of those things because from my time at Solana foundation we definitely saw that massive growth and we definitely saw basically exactly what you described. The idea of people were taking these, uh, call them bolt on add ons for lack of better phrasing from other ecosystems and other blockchain architectures and trying to make the same thing work on Solana and it just doesn't because it's such fundamentally different architecture and like different limitations, different design, all of these things. And yeah, like we've even had a, we've had a show before with Termina, uh, uh, about like Network extensions and some of the things that they're doing. Which is, which is pretty cool. Um, I would love to hear sort of the architecture of how Raku does this and does it in a Solana native way built for the Solana chain specifically.

Speaker A: Yeah. So I think we can actually take one, one step back first. So a, Just to provide helpful context extensions or off chain compute components. They will face a number of issues which are inherent to Solana but also in the general context of L1s. But number one usually being the factor of predictability. So if you send a transaction on Solana today, it doesn't matter if an L1 application or a external component, you're always hoping for the best as in uh, it's an optimistic scenario and you're waiting for it to be approved. You don't know uh, before you send it if it will be right. So the level of predictability is quite important especially for um, larger applications in more traditional uh, uh sectors. That's a big one. Uh, the, the other problem is if you're introducing um, many different ah separate systems as ah extensions and they have no way of talking with each other then suddenly you have the um, fragmentation issue. And we've seen that um, elsewhere. The other issue is also validators on the network. Um, they don't necessarily have a way to participate in the value creation of this which further um, which further uh, uh increases the um, incentive misalignments.

Speaker C: Uh, and you mean specifically value creation of uh, you mean specifically value creation of things in this like ah, off chain compute, external compute model.

Speaker A: Exactly. Because as an external system you're sending transactions down to the underlying L1. That means that the validator somehow is uh, partaking in that. You um, want the validator to be as closely aligned with that system as possible such that they can prioritize uh system reliability um, as best as they can. Right. And also efficiency which is like the latency games and stuff, stuff like that. Uh now that's a really difficult problem to solve for because you need to be directly working at the validated level whilst facilitating the communication with these other external systems. Right. So that's a problem that was quite prominent.

Speaker C: Um,

Speaker A: it's made harder if you want to have one external system talking with let's say an L1 native application. So traditionally we call that state composability. Uh, even harder if you want to have two external systems trying to talk with each other via the L1 as well. Again state composability. So those are like really difficult problems to solve. For um, so that's the base of where we started. Um, and I guess now we can go into how we're doing.

Speaker C: So then how does Raiku actually accomplish this?

Speaker A: Yeah, so Raiku consists of two primary components. One is the sidecar which is working at the validator level. Uh, so the sidecar is um, pretty much working with a validator to ask what block space in terms of resources or compute units can we reserve ahead of time such that we can distribute this to applications which is either directly on the L1 or uh, externally as network extensions or off chain compute modules. So the sidecar is doing that and it communicates with the second component which is uh, the coordination node, which is ancillary to the network. And that is where most of the uh, magic happens. That's where we enable and facilitate the outer protocol transaction types, which is more powerful ways of basically sending transactions to the network. Um, so those are like the two main components and most of this is driven by uh, ahead of time block auctions which is being facilitated between these two components or by the two components.

Speaker B: So uh, that sidecar piece it sounds like helps to solve a couple of those problems in one go. It allows validators to participate in the value creation because they are participants in this ahead of time, you know, block auction. Right. Uh, so they can, they can collect fees that way and there's all. It also presumably there's you know, better coordination with, with these components as a result.

Speaker A: Yeah, yeah, exactly. And the sidecar is compatible with Agave today and will be compatible with Fire Dancer, um, later this year right before mainnet. So yeah, it, that is what facilitates um, the communication you need to have with the underlying network in itself.

Speaker B: So this is something, if you run an Agave validator, you can basically install Sidecar in your existing setup.

Speaker A: Yeah, exactly. So today if you are running. Because right now we're on run testnet. So if you're running a agave client on testnet, you should be able to install this in 30 to 60 minutes. All of the dashboards come out of the box ec, uh, uh, installation guides. Um, so yeah, pretty straightforward.

Speaker C: How is this different from something like what Jito does with Jito bundles and the auctions there and then also I guess with uh. I'm trying to remember the name of the service. I know Triton and I think Helios have a similar service where it's effectively block auctions ahead of time. What's the difference here between those and what you're doing at Raikou?

Speaker A: Yeah, so one is we Today it depends on how you want to look at it really because you can uh, draw a few parallels to JITO today, uh, and how that compares to Raiku. Um, but when you send a transaction or a bundle to uh, the Gita MEM pool, MV searchers is uh,

Speaker C: um,

Speaker A: participating in that game. Out of that historically, uh, it was a 200 millisecond uh, speed delay, but they've decreased that now to 50 milliseconds which is then sent down to the validator once the most profitable bundle has been selected. And then the validator will then include that into the block. Uh, in jito, historically if I remember correctly, they have reserved about 5 to 6 million uh, uh, CEUs or compute units, which roughly corresponds to I think 10% of the block at least back in those days. Now we've increased it, hopefully less percentage of blocks soon. Exactly. Um, so essentially what it does is that it breaks continuous block building. Um, Raiku doesn't. So you will send the transaction straight down to the underlying validator in itself where the, let's say communication line of communication path is already pre established. And this comes down to the ahead uh, of time block auctions and the inclusion signals that we distribute to uh, those applications. That's the primary difference.

Speaker C: Interesting.

Speaker A: Yeah, it comes down to then, okay, what benefits will this have on um, latency games? Right. But also uh, due to the underlying nature of the inclusion signal, you will receive this up to 60 seconds ahead of time such that you can plan for what transactions you want to submit. Right. And that inclusion signal is sent every today 40 milliseconds, but it will go down to 20 milliseconds. Um, interesting.

Speaker C: Okay, so to make sure I understand because I have a very basic understanding of jito, so take this with a grain of salt to summarize your differences that you described. It's effectively JITO has some X percentage of block space that it effectively reserves on all validators that are participating in the JITO network and running the JITO client in order to receive bundles. So that's sort of. And as transactions get sent, they get sent to jito's mempool, all the JITO MEV stuff happens and then it gets sent to the validator. So it's much more, there's much more latency there. Vice with Raku, because the block size is sort of, the block space is auctioned off beforehand. The transactions can just get sent directly to the validators themselves. Normal leader schedule, normal things there. And then because that auction's already happened, the validator as they're receiving transactions that are like should go inside of that auctions block space via the Raku setup. They just can just prioritize those transactions over the other ones and then just continue on. Is that a good summation?

Speaker A: Yeah, pretty much. So with Raiku you have what you can call differentiated block space which means like block space with different features that uh, is specific for different needs, different application needs. Um, and you can pretty much think of it as almost as validated plugins. So for example one validator plugin can be inclusion signals. Another one can be um, ahead of time as in more than 60 seconds which comes with a discount. So discounted block space, um, which is a different feature that might be um, quite uh, uh powerful. For example Oracles, because oracles they have a uh, constant order flow but it's not necessarily transactions which are high value. So they just care about will I get included at this specific time. But it's not necessarily um, uh, it's not necessarily something that they want to have included at the top of the block for example due to low value nature. So yeah, think about it as plugins, uh, for like different use cases.

Speaker B: It's interesting because this is one of those things um, that I had a very direct understanding of the problem set more before I became familiar with Solana, right? So the problem of getting block space was more apparent to me in 2020 using Ethereum, um, right. Than it is right now on Solana, uh, just as a regular user, right? So it's like as a regular user I often was like hey, I don't really care when this goes through. I just, I just need to know it's going to go through. I'm sitting here clicking the button, the transaction is spinning for three minutes and then fails. And that's just really fucking annoying. Like I would, could we just schedule this for sometime in the next 10 minutes and know that it's gonna happen for sure. Uh, and so it's interesting to hear us talking about it now in the context of Solana, which has much higher throughput is much faster chain. I almost never worry about transactions not landing as an end user, but I think what a lot of uh, maybe typical users don't understand is that's not necessarily the case for all systems, right? Like if you're running a system that requires uh, you know, uh, a lot of bandwidth, a lot of speed, you know, it might matter to you that 3% of your transactions aren't landing or whatever, right? And so this sort of solution actually becomes much more important when you're thinking at scale, which most end users aren't. Right. Like most end users and frankly myself. Right. Like just jumping into Phantom and clicking some buttons to execute a transaction here and there. And so this doesn't sound like a salient problem, but I think it is when you think about the broader architecture of what we're trying to build.

Speaker A: Yeah, I think it's quite accurate. As in end users today necessarily care about the certainty or inclusion problem. I think the only time they're exposed to it is during network congestion, um, which we will help to decrease because um, once you enable certainty then suddenly um, applications or developers, they don't need to apply retry logic and with retry logic you will just decrease the amount of spam that is sent to the network. Um, but yeah, it is for those cases where applications needs to think at scale or for edge cases, um, think for example, you know, high value, uh, trading, high frequency trading. In the context of high frequency trading up to 96% of transactions are being dropped. That's a big issue. But also in use cases where you have uh, let's say solvers, um, that is submitting bids to liquidity requests once that bid has been uh, uh submitted the solvers are taking on a pricing risk uh between from the time the bid was sent until the time until the bid is being accepted and then ultimately uh, executed onto the chain in itself. And all of that takes time. Right. So if you can decrease the uh, uh time frame and ensure the guarantee as well, that's a brilliant use case. So there's, I think the use cases that we're talking about here is not necessarily use cases that most end users are being exposed to M but the transaction primitives that we're talking about here will really enable the scale, that's for sure.

Speaker B: Yeah, yeah.

Speaker C: Ah, I think users in this circumstance it's very much a um, ignorance is bliss problem where they don't see it, they don't have to think about it until they really see it and they really have to think about it or their application providers have to think about it. Um, like times of network congestion. Yeah. I want to circle back to something you said earlier about um, the Raikou um, auctions. You said they can be up to 60 seconds before. How does that work? As an application developer, I build an application, how do I participate in the auction of these and how does that transaction ultimately get to the validator? Because we talked about the application can send it to the validator. The validator's handling everything on the back End effectively. But from the understanding of Solana transactions, once the transaction is signed it has a shelf life. It has an expiration time in the form of the latest block hash. So it doesn't last 60 seconds. Generally it's roughly 13 seconds or so. So how does that work?

Speaker A: So it depends on the use case you have um, for extensions or off chain compute modules. In itself it will work differently than how you would interact uh with raiku and the SDK uh as an L1 application. Um but primarily we'll give there will be two ways to submit transactions to Raiku and leverage the transaction types. If you just want to use the basic types as in um, the basic types essentially enables uh deterministic inclusion so you know it will be included no matter what. That's just a simple um, simple change. As in these are the endpoints where you should uh submit your transactions to. If you want to participate in uh the ahead of time block auctions and receive inclusion signals then you would need to install the SDK which we'll uh, go live with a bit later. Um, where you will have programmatic access to uh, and this is something that you will define uh in the config which is uh specific uh to your use case as in this is the time frequency in which I want to operate on uh this transaction type A or B is what I would like to use and then the SDK will uh give uh the choice on what um pricing modules that the developer would like to go for. So for example a problem uh, that we faced really early on was how do you price an asset uh ahead of time? So basically futures market um this can, is a really difficult problem to solve and we don't think we are the best one to solve it. So we're opening up for the chance where maybe searchers for example they can uh develop their own uh pricing modules and then you basically open up a free market. So that's how the developers can interact with it. So there is a lot of flexibility. Um is it still a couple of things that we're figuring out in terms of like the incentive mechanisms and how fees are being split from the applications down to the validators. Um this we should hopefully have ready very uh soon. But yeah, those are the two primary ways you can uh um interact with Raiku.

Speaker B: So you guys um, you said that you're currently you know on testnet, so you've got some validators that you're working with on testnet who um, who's testing on the, on the other side. Right? So there's obviously the integration with validators, but kind of like what Nick is saying, the folks who are actually submitting transactions using your tech, um, who are you working with, what sorts of use cases are you testing? Um, you know what can you share on that side of things?

Speaker A: So right now we're running Testnet V1, which is pretty much the core construction of Riku. So there's a couple of things it doesn't support yet that will come later in v2, which will be after uh, the summer. Um, so what we're testing for now is the uh, installation process for the validators and really load testing, uh, the core construction of the Riku network. So basically the coordination, uh, node. Um, right now the coordination node is uh, only living on a few instances, but in V2 you'll be fully decentralized. So that's when we will start to test uh, um, the latency of sending out the different inclusion signals, how fast we can send information down from uh, various different application types completely down to the underlying validator and also test for the edge cases of what happens if a transaction is not included by the validator in itself. Like whose fault was it? Uh, that will come a little bit later. Now we're pretty much just testing the core construction of Riku in itself, um, primarily with the validators and then uh, simulations on our end.

Speaker B: So the coordination layer, it sounds like, is its own decentralized network that's sort of dedicated to facilitating this. It's almost like an extremely focused and dedicated L2. Right. Its job is very narrow. It's not an L2 in the way that we normally think about L2s.

Speaker A: No, it's, it's not an L2 as in it doesn't perform, it doesn't hold any, any keys. Essentially. Um, it's primarily there to coordinate messages between the different stakeholders. Um, yes, you can compare it to a decentralized network, but there will be a limited number of nodes. So anywhere between 100 to 500 nodes. And what we care about is that those nodes are run by good actors on a good uh, infrastructure layer. So basically the data centers can communicate, uh, efficiently and that you have good geographic coverage in terms of proximity of where we see, uh, certain transaction hotspots. Right, so like New York, London, etc.

Speaker B: Got it. Um, how do you ensure good actors in a setup like that?

Speaker A: That's a good question. And that comes down to a lot of the uh, incentive mechanisms which we're currently hashing out. So hopefully we'll have a paper on this. Really, really soon.

Speaker B: Awesome. Awesome. It's, you know, the whole idea of, of sort of extending the network is interesting to me because I do think Solana, for years, uh, the marketing was kind of anti L2s. Right. And I understand why you mentioned all the problems with L2s at the beginning of this call. Right. There's, uh, these coordination issues, fragmentation of, uh, liquidity, misalignment, uh, of incentives, et cetera. Right. But it's almost, uh, it's almost like a, uh, don't throw the baby out with the bathwater situation, where it's like, hey, just because, Just because we, we don't want to create a full, you know, uh, L2 doesn't mean we can't take some of the concepts of extending the base functionality of the network to improve the network. So, you know, it sounds like there are still some unknowns with what you guys are building. Um, but I don't see that as, I don't see that as a bad thing. I see that. I mean, there are unknowns with, I mean, we said it earlier as well that Solana is still improving. Right. We see that Solana is a very great chain, but we're not done. Right. We're still making improvements to the network we're still building. Exactly. And so I, you know, I, it sounds like you guys have a really neat, uh, solution already. And some of these, some of these outstanding questions, like what I just asked, like how, you know, how do you prevent bad actors here is like, oh, well, we've got some ideas. We're working on a paper right now. Some of this we're building for V2 type of thing.

Speaker A: Yeah, exactly. Yeah. It comes down the, it comes down to the incentive mechanisms of the overall, let's say, RU economy. Um, this is something we've been focused on for a long time. However, we're only now starting to get ready to implement, um, to implement and test it in the scenarios that, that we're modeling for. So we should be able to achieve some good progress, uh, uh, at the end of the summer. So let's see. We'll keep you updated.

Speaker B: Yeah, I am, ah, I, um, am very interested to see what you come up with, especially given, like, you said that that coordination layer doesn't hold any keys or anything. So my whole concept of how do you build, uh, a distributed network that has economic incentive to maintain good actors sort of hinges on my understanding of a traditional blockchain network, which it sounds like the coordination layer is not. So how to map some of those same economic incentives over to a slightly different system is, you know, is new to me and something I'd be interested to dig into.

Speaker A: There's many different options you can go for. Like we've seen in Ethereum that some of the pre confirmation players have merged M pre comps, which what I've traditionally called like base security, uh, because it's like very similar to how you built rollups traditionally. Uh, they merge that with Restake security, um, so like eigenlayer, uh, Jito, et cetera. So it does merge at some point. But Restake security as well has its own issues. Uh, so there are multiple ways you can secure ancillary components to the network. The question is though, what risk exposure will that lead to for the applications that is ultimately ending up building on this? Right. So there's many different considerations to take into account, if not one of like the most difficult problems to solve for, uh, to be honest. So that would be a fun one.

Speaker B: Interesting. Uh, so when, um, when an application is trying to use Raiku, are there transactions submitted through that coordination layer or is that sort of a side process directly to validators?

Speaker A: Yeah, the transaction is sent to uh, the coordination node on the Raiku node. Then uh, the Raiku node figures out what is the CA usage of the transaction that has been submitted. What is the optimal inclusion path depending on the transaction type, then is then sent down to the underlying network in itself, which is the validator.

Speaker B: Got it.

Speaker A: So transactions go to, to the node, the icon node.

Speaker B: Yeah, um, so, so yeah, then it, then it is, you know, it is important obviously to maintain good actors because it's not, um, you know, you don't want a node that's going to drop transactions that's, you know, it's kind of defeats the point of the system. Um, who is the, you mentioned a couple use cases, but like who do you think the first, uh, users of Raiku are going to be? Is it going to be high frequency trading systems? Is it going to be end user applications? Like what are you sort of. Obviously some of this is a hypothesis, right? But I'm curious what the hypothesis is.

Speaker A: The simple answer is most defi applications on the L1 today, they will be able to participate and improve the overall user experience and performance of their underlying L1 applications by adopting some of the transaction types which then will lead to higher uh, protocol margins for the underlying app in itself. But also let's say at ah, Perpdex there, the traders will be able to take advantage of price movements that they haven't been able to do. Uh, uh historically um, so the simple answer is the Pre existing native L1 apps today. But longer term where you can uh, create most value is by adopting this new way of building the app application. So off chain uh compute modules. Right. So um, the biggest vertical that makes the most sense is finance. High performance finance which also includes defi, um yeah,

Speaker B: so finance because of how valuable transaction inclusion is there.

Speaker A: Yeah, exactly. You want to beat the market, uh

Speaker C: the guarantee and the speed of getting your transaction to land if it's worth a lot of money to you. Makes sense.

Speaker A: Exactly.

Speaker B: You mentioned traders being able to take advantage of price movements that they otherwise wouldn't. Could you explain maybe just step by step how Raiku facilitates that? Right. There's a little bit of a gap for me uh there where this maybe is a good opportunity to like dig in and provide a concrete example for me.

Speaker A: Yeah, so if you have a off chain compute, uh scheduler or an off chain scheduler, uh that uh receives inclusion signals every 20th millisecond, that scheduler will be able to order the transactions which comes inherently from its users, let's say the traders and the market makers according to you know, the best business requirements or use case for this uh, um, uh per deck, um since it receives the inclusion signals again 26:20 uh every 20th millisecond up to 60 seconds ahead of time you will be able to confirm uh the execution of those transactions uh much faster than you would uh originally and with that uh, you decrease the uh, uh time frames for um, basically getting a trade confirmation as an end trader in itself. Now so that's with the transactions but there is a dependency on real time pricing feeds today like basically Oracles, um, today there is limitations on how fast that can be. So I think that is a interesting industry challenge that has to be solved. Some players, they have made interesting solutions where they basically take in multiple different pricing feeds from uh, decentralized sources and, and up to centralized exchanges. That is one possible way to solve it. So because you do need to have the, the asset pricing to support the time frequency of how fast you can confirm trades. Right. So yeah there are multiple things that would uh, be relevant.

Speaker B: Yeah a few things to work on in parallel because confirming the transaction quicker doesn't matter if you don't have accurate pricing information at the same speed.

Speaker A: Yeah, got it. Spot on.

Speaker C: Gotcha. Yeah, uh, this is going to be very interesting especially once uh, Alpenglow eventually reaches testnet and Mainnet, probably next year hopefully. That's like Anza's optimistic timeline when they're quoting transaction finality at 50 milliseconds. Um, which is crazy from what it is right now. Um, it's going to be interesting to see. Uh, yeah, this has been such a great conversation, Robin. Um, I would love to have you back on the show here in maybe a couple of months to talk more about what progress you guys have made and testnet v2. Yeah, that'd be great. Um, as we wrap up here, I was wondering if there's any last minute things that you want to relay to the audience.

Speaker A: We are hiring big time. If you're an engineer or a marketer or growth. Yeah, please go to riker.com always hiring.

Speaker C: Amazing.

Speaker B: Uh, what types of engineers are you looking for? Mostly.

Speaker A: What? Mostly core engineers. Okay, core engineers. Ros. Uh, fairly low level experience if you built, uh, worked on. On a Validator Light client. Fantastic. But ros. Native.

Speaker B: Okay, sounds great. You heard it here, folks. If you are an, uh, engineer who fits the profile, go to Raiku. Sounds like other things too, right? You said marketing. Some other things, if any. If this sounds interesting and you're not an engineer, of course. Still, still reach out. Right. Like there are, there are other roles and other ways. Of course. Um, well, awesome, Robin, thank you. Thank you so much. This was, this was a great convo. I'm excited to see how V2 goes. I'd love to, you know, chat more about the challenges that you've solved, uh, once. Once V2 test net comes out.

Speaker A: Thank you, guys.

Speaker B: All right, to the listeners. We will see you all next time.

Speaker C: Bye. Bye.

Speaker A: Bye.

Speaker C: All right, thanks for joining us for this episode of the Sulfate Pump podcast. I hope you liked it. I know we did. We always have a blast recording with our amazing guests. If you've got a moment, please leave us a review in your podcast app or subscribe on YouTube. And I guess it's time, uh, to get some more coffee and get back to work.