Raiku's Mission to Deliver Guaranteed Transaction Inclusion on Solana

The pursuit of blockchain performance has long been constrained by fundamental physical limitations. No matter how sophisticated the technology becomes, information can only propagate through networks at certain speeds governed by the laws of physics. This reality has driven the evolution of Layer 2 solutions on Ethereum and various scaling approaches across the blockchain ecosystem. However, a new breed of infrastructure projects is emerging on Solana that aims to extend the network's capabilities without introducing the fragmentation problems that have plagued other ecosystems. Raiku, founded by Robin, represents one of the most ambitious attempts to solve the transaction inclusion problem while maintaining the cohesion and composability that makes Solana unique.

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

In a recent episode of the Solfate Podcast, Robin joined hosts James and Nick to discuss Raiku's innovative approach to guaranteed transaction inclusion. The conversation revealed a sophisticated system architecture involving validator sidecars, a decentralized coordination layer, and ahead-of-time block auctions that could fundamentally change how applications interact with the Solana blockchain. For developers building high-performance financial applications, the implications are significant: predictable transaction inclusion, reduced retry spam during network congestion, and the ability to plan transaction submission up to 60 seconds in advance.

The Fundamental Problem with Layer 1 Blockchains

Layer 1 blockchains face inherent limitations that cannot be solved purely through software optimization. As Robin explained during the podcast, even if engineers manage to reduce block times and improve propagation speeds, there exists a physical floor below which no system can operate. "Even if you get it down to let's say 120 milliseconds, that's kind of the bedrock. We're not going to get much faster. 120 milliseconds compared to traditional systems, this is shit. It's really slow," Robin stated bluntly. This assessment, while harsh, reflects the reality that traditional financial systems operating in centralized data centers can execute operations in microseconds rather than hundreds of milliseconds.

The challenge becomes even more pronounced when considering the geographic distribution of blockchain networks. Unlike centralized systems that can optimize for specific locations and user bases, L1 blockchains must serve users globally without the ability to optimize for where transactions originate. This creates fundamental inefficiencies that no amount of protocol-level optimization can fully address. The result is a performance gap between blockchain applications and their traditional counterparts that has historically forced teams to make difficult tradeoffs between decentralization and user experience.

Solana has made tremendous progress in narrowing this gap through its high-performance architecture and continuous protocol improvements. The upcoming Alpenglow upgrade, for instance, targets transaction finality as low as 50 milliseconds. However, as Robin pointed out, even these impressive improvements don't eliminate the fundamental physical constraints that L1 systems face. This is where network extensions like Raiku come into play, offering a way to build additional capabilities on top of the base layer without sacrificing the benefits that make Solana attractive in the first place.

Robin's Journey from Ethereum to Solana

Robin's path to founding Raiku began in 2015 with an interest in consensus mechanisms and incentive design. His early work took place within the Hyperledger project, which he described as "pretty much the corporate version of Ethereum" backed by the Linux Foundation and IBM. This experience provided exposure to enterprise blockchain requirements and the challenges of building systems that need to operate reliably at scale. Following Hyperledger, Robin worked with end-to-end teams on Ethereum during the period leading up to DeFi Summer, witnessing firsthand how the ecosystem evolved to meet growing user demand.

The emergence of Layer 2 solutions on Ethereum initially seemed like the answer to scaling challenges. However, Robin observed that L2s created as many problems as they solved. "That led to so many other problems that we see today, right? Like state fragmentation, incentive misalignment, user fragmentation issues, and not optimal," he explained. The proliferation of L2s fractured liquidity across multiple chains, created confusing user experiences as people navigated between different environments, and introduced new trust assumptions that undermined some of the core value propositions of blockchain technology.

After spending six to seven years in the Ethereum ecosystem, Robin made the transition to Solana at the end of 2023. The timing coincided with one of the most challenging periods in the bear market, yet Robin saw opportunity where others saw despair. His interest centered on exploring whether proximity-based computation could unlock new possibilities on fast L1 networks. While evaluating options including Aptos and Sui, Solana emerged as the clear frontrunner for several compelling reasons that would shape the foundation of what became Raiku.

Why Solana Stood Out as the Foundation for Raiku

The decision to build on Solana came down to three primary factors that distinguished it from competing platforms in late 2023. First and most importantly, Solana had achieved a level of technical maturity that made ambitious infrastructure projects feasible. Robin noted that "the underlying protocol was really advancing. You could see that the core developers was pushing place like literally every second week." This rapid pace of development, while sometimes leading to the "move fast and break things" consequences that the ecosystem has experienced, demonstrated a commitment to continuous improvement that gave confidence in the platform's future trajectory.

Second, there was already a nascent ecosystem of projects gravitating toward edge compute and network extension concepts on Solana. Teams building perpetual exchanges and other high-performance applications recognized that they needed capabilities beyond what the base L1 could provide, but struggled to find native solutions. "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," Robin observed. These projects often found themselves adopting frameworks from other ecosystems, particularly Ethereum, and attempting to adapt them for Solana's different architecture. This approach rarely produced optimal results.

The third factor was the explosive growth in Solana's user base and developer community. Between 2023 and 2025, developer mindshare on Solana increased by an astonishing 18.5 times. This growth trajectory indicated that Solana was emerging as the platform of choice for the next generation of blockchain developers. For Robin, building infrastructure on Solana meant building for where the ecosystem was headed rather than where it had been. The combination of technical capability, market need, and community momentum made Solana the obvious choice for Raiku's foundation.

Understanding the Core Problems Raiku Addresses

Applications building on Solana, whether native L1 applications or external compute modules, face several interconnected challenges that Raiku aims to solve. The first and most fundamental is predictability. When a developer sends a transaction to Solana today, there is no guarantee it will be included in a block. "If you send the transaction on Solana today, it doesn't matter if an L1 application or an external component, you're always hoping for the best. And you're waiting for it to be approved. You don't know before you send it, if it will be," Robin explained. For consumer applications handling small transactions, this uncertainty is manageable. For institutional applications or high-frequency trading systems, it represents an unacceptable risk.

The second challenge involves coordination between different systems building on top of Solana. As more teams deploy off-chain compute modules and network extensions, the risk of fragmentation grows. Different systems with no way to communicate create siloed environments that undermine the composability that makes blockchain valuable. Robin identified this as a critical issue: "If you're introducing many different separate systems as extensions, and they have no way of talking with each other, then suddenly have the fragmentation issue." Solving this requires infrastructure that facilitates communication not just between applications and the base layer, but between different extension systems themselves.

The third major problem involves validator incentive alignment. When applications use off-chain compute modules, they generate value that validators may not directly participate in. This creates a misalignment where validators have limited motivation to prioritize the reliability of these systems. "You want the validator to be as closely aligned with that system as possible. Such that they can prioritize system reliability as best as they can. And also efficiency, which is like the latency games," Robin noted. Solving this requires building mechanisms that allow validators to capture value from the systems they support, creating economic alignment that improves system reliability.

Raiku's Technical Architecture Explained

Raiku's solution consists of two primary components working in concert to address these challenges. The first component is a validator sidecar that integrates directly with Solana validator software. This sidecar works at the validator level to determine what block space, measured in compute units, can be reserved ahead of time for distribution to applications. By operating at the validator level, the sidecar creates a direct channel for coordinating transaction inclusion that bypasses the typical uncertainty of transaction propagation through the network.

The sidecar is currently compatible with the Agave validator client and will support Fire Dancer before the Midnight release later this year. For validators already running Agave on testnet, installation is straightforward. Robin indicated that the process takes approximately 30 to 60 minutes and includes pre-built dashboards and installation guides. This ease of deployment is crucial for adoption, as validator operators are understandably cautious about adding complexity to their production systems.

The second component is the coordination node, which Robin described as "where most of the magic happens." This node serves as an accelerator to the network, enabling and facilitating outer protocol transaction types that offer more powerful ways of submitting transactions to the blockchain. The coordination node doesn't hold any keys or perform execution—its role is purely to coordinate messages between different stakeholders in the system. This design choice is intentional, as it minimizes the attack surface and trust requirements for applications using Raiku.

How Ahead-of-Time Block Auctions Work

The core mechanism driving Raiku's capabilities is ahead-of-time block auctions. These auctions occur before block production, allowing applications to secure block space with certainty rather than competing for inclusion in real-time. The process works through the interaction between the validator sidecar and the coordination node, with the sidecar communicating what resources can be reserved and the coordination node managing the auction process that distributes this capacity to applications.

One of the most powerful aspects of this system is the inclusion signal mechanism. Applications participating in Raiku receive inclusion signals up to 60 seconds ahead of time, giving them substantial lead time to plan their transaction submission. These signals are currently sent every 40 milliseconds but will decrease to 20 milliseconds as the system matures. This predictability represents a fundamental shift from the current model where applications submit transactions and hope for the best.

The ahead-of-time nature of these auctions creates what Robin calls "differentiated block space"—block space with specific features tailored to different application needs. Think of it as validator plugins that cater to different use cases. For example, one plugin might focus on inclusion signals for applications requiring fast confirmation. Another might offer discounted block space for applications with constant but low-value transaction flow, like oracles that need reliable inclusion but don't require top-of-block placement. This flexibility allows the system to serve diverse needs without forcing all applications into a one-size-fits-all model.

Comparing Raiku to Jito and Existing Solutions

A natural question arises about how Raiku differs from existing infrastructure like Jito bundles. The comparison is instructive because both systems aim to improve transaction inclusion, but they approach the problem differently. When users send transactions or bundles to Jito, those transactions enter a mempool where searchers compete to construct the most profitable bundle. After a speed delay—historically 200 milliseconds but now reduced to 50 milliseconds—the winning bundle is sent to the validator for inclusion. Jito has traditionally reserved approximately five to six million compute units, roughly 10% of block space, for this process.

The key architectural difference is that Jito's approach breaks continuous block building while Raiku's does not. With Raiku, transactions are sent directly to the underlying validator through pre-established communication paths created by the ahead-of-time block auctions and inclusion signals. There is no intermediate mempool or auction delay in the transaction path itself. "The transaction is sent to the coordination node on the Raiku node. Then the Raiku node figures out what is the optimal inclusion path, depending on the transaction type, then it's sent down to the underlying network in itself, which is the validator," Robin explained.

This architectural difference has implications for latency and reliability. Because Raiku's auctions happen ahead of time, the transaction submission process itself doesn't incur additional delays beyond what's necessary to reach the validator. The coordination has already occurred, the block space has already been reserved, and the inclusion path has already been established. This design is particularly advantageous for applications where microseconds matter, such as high-frequency trading systems that currently see up to 96% of their transactions dropped during competitive periods.

Transaction Types and Developer Integration

Developers can interact with Raiku in two primary ways depending on their needs. For applications that simply want basic guaranteed inclusion capabilities, the integration is straightforward: submit transactions to Raiku's endpoints instead of default Solana RPC endpoints. This minimal change unlocks deterministic inclusion guarantees without requiring significant code changes or additional complexity in the application architecture.

For applications that want to fully leverage ahead-of-time block auctions and receive inclusion signals, deeper integration through Raiku's SDK is required. This SDK, which will go live in the coming months, provides programmatic access to Raiku's advanced features. Developers configure the SDK according to their specific use case, including the time frequency they want to operate on and which transaction types they want to utilize. The system is designed to be flexible enough to accommodate different business requirements without forcing developers into rigid patterns.

One innovative aspect of Raiku's SDK design involves pricing modules. Determining how to price block space ahead of time—essentially creating a futures market for transaction inclusion—is a complex problem. Rather than attempting to solve this entirely in-house, Raiku is opening the system to allow searchers and other market participants to develop their own pricing modules. This creates a competitive market for price discovery that should lead to more efficient pricing than any single team could achieve. "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 develop the foreign pricing modules, and then you basically open up a free market," Robin explained.

Network Congestion and the Retry Problem

While most end users of Solana rarely think about transaction inclusion, the problem becomes acutely visible during periods of network congestion. When blocks are full and demand exceeds capacity, transactions start failing to land. The typical response from applications is to implement retry logic—if a transaction doesn't land, try again. And again. And again. This retry behavior has a cascading effect: as more applications retry failed transactions, they contribute additional load to an already congested network, making congestion worse and creating a negative feedback loop.

Raiku's approach addresses this problem at its root. When applications have certainty about transaction inclusion through ahead-of-time reservations, they don't need aggressive retry logic. "Once you enable certainty, then suddenly 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," Robin noted. This has system-wide benefits that extend beyond just the applications using Raiku, as reducing overall transaction spam improves network conditions for everyone.

The improvement is particularly dramatic for high-frequency trading applications. Robin cited statistics showing that up to 96% of transactions are dropped in competitive high-frequency trading scenarios—a staggering failure rate that makes reliable operation essentially impossible without significant infrastructure investment. By providing guaranteed inclusion paths, Raiku enables these applications to operate more efficiently while also reducing their contribution to network congestion.

The Coordination Layer's Decentralized Architecture

The coordination node is not a single centralized service but rather a network that will ultimately consist of 100 to 500 nodes. While this represents a limited node set compared to Solana's validator network, the focus is on quality over quantity. "What we care about is that those nodes are run by good actors on a good infrastructure layer. So basically the data centers can communicate efficiently and that you have good geographic coverage in terms of proximity of where we see certain transaction hotspots, like New York, London, et cetera," Robin explained.

This design raises important questions about how to ensure good actor behavior in the coordination layer. Unlike traditional blockchain networks where economic incentives from token staking and slashing mechanisms help maintain honest behavior, the coordination layer doesn't hold keys or process transactions in the traditional sense. Its role is purely coordination, which requires different security considerations. Robin acknowledged this as one of the most challenging problems the team is working on, with a paper on incentive mechanisms expected soon.

The testnet currently operates with the coordination node living on a few instances, but v2 will implement full decentralization of this layer. This transition will require extensive testing of inclusion signal latency, transaction propagation speed from various application types to validators, and edge case handling such as what happens when a validator fails to include a transaction it was expected to include. These scenarios are being modeled and will be tested thoroughly before mainnet deployment.

Extending Solana Without Creating an L2

A crucial distinction that Robin emphasized throughout the conversation is that Raiku is not a Layer 2 in the traditional sense. L2s typically involve separate execution environments, their own consensus mechanisms, and bridges to the underlying L1. They hold keys, process state, and create entirely new blockchain environments that require users to navigate between layers. This approach has led to the fragmentation problems that Robin witnessed in the Ethereum ecosystem.

Raiku takes a different approach that extends Solana's capabilities without creating a separate execution environment. The coordination layer facilitates communication and pre-reserves block space, but execution still happens on Solana itself. There is no separate state to fragment, no bridges to cross, and no new consensus mechanism to trust. Applications using Raiku are still Solana applications—they just have access to more powerful transaction primitives and inclusion guarantees than applications that interact with Solana directly.

This architectural choice preserves Solana's composability advantages. Applications using Raiku can still interact seamlessly with applications that don't. Smart contracts called through Raiku are the same smart contracts other users interact with through standard Solana transactions. The shared state and atomic composability that makes Solana DeFi powerful remains intact. Raiku adds capabilities on top of this foundation rather than creating a parallel environment that would fragment the ecosystem.

Use Cases: High-Performance Finance and Beyond

The primary use cases for Raiku center on high-performance finance applications where transaction inclusion guarantees create tangible value. Perpetual exchanges represent a particularly compelling example. These platforms facilitate leveraged trading where price movements during transaction processing can create significant financial exposure. "In use cases where you have solvers that is submitting bids to liquidity requests, once that bid has been submitted, the solvers are taking on a pricing risk between from the time the bid was sent until the time the bid is being accepted and then ultimately executed on to the chain in itself," Robin explained.

By decreasing the timeframe between bid submission and execution while ensuring the guarantee of inclusion, Raiku reduces the pricing risk that solvers face. This allows them to quote tighter spreads and take on larger positions, ultimately improving liquidity and trading conditions for end users. The benefits cascade through the system: traders get better prices, liquidity providers face less adverse selection, and the overall efficiency of the market improves.

High-frequency trading represents another significant use case. These systems execute large numbers of transactions attempting to capture small price discrepancies across markets. With current infrastructure, the high rate of transaction failures makes profitable operation challenging without significant infrastructure investment to reduce latency and improve inclusion probability. Raiku's guaranteed inclusion paths fundamentally change the economics of these operations, making strategies viable that would be unprofitable under current conditions.

Beyond trading, oracle networks stand to benefit significantly from Raiku's differentiated block space features. Oracles need to submit price updates constantly but don't necessarily require top-of-block placement since their transactions aren't competing for MEV opportunities. Raiku's discounted block space for constant-flow, lower-value transactions could reduce oracle operating costs while improving the reliability of price feeds. This improvement to oracle infrastructure benefits the entire DeFi ecosystem that depends on accurate, timely price information.

The Dependency on Faster Oracle Systems

While Raiku can dramatically reduce transaction confirmation times, Robin acknowledged an important dependency that the system can't solve alone. If traders can confirm transactions faster but oracle systems can't provide price information at matching speeds, the benefit is limited. "There is a dependency on real-time pricing feeds today, like basically oracles. Today, there is limitations on how fast that can be," he noted.

Some projects are already working on solutions that aggregate pricing information from multiple decentralized sources and centralized exchanges to achieve faster updates. These approaches recognize that waiting for on-chain oracle updates limits the speed at which any trading system can operate. The broader industry challenge of matching asset pricing speed to transaction confirmation speed will need to be solved in parallel with improvements to transaction infrastructure.

This is an area where Raiku's differentiated block space could contribute to solutions. By providing reliable, low-cost inclusion paths for oracle updates, the infrastructure could enable more frequent price updates without proportionally increasing costs. Combined with off-chain price aggregation systems, this could help close the gap between what's possible in transaction confirmation and what's possible in price discovery.

Testnet Status and Roadmap to v2

Raiku is currently operating testnet v1, which focuses on validating the core construction of the network. This phase primarily involves testing the installation process for validators and load testing the coordination node architecture. Validators running Agave clients on testnet can already participate by installing the sidecar component. The focus at this stage is ensuring that the fundamental infrastructure works reliably before adding more complex features.

Testnet v2, expected after summer 2025, will introduce several significant advances. The coordination layer will be fully decentralized across multiple nodes rather than operating on limited instances. This phase will test the latency characteristics of distributed inclusion signals, measuring how quickly information can propagate from various application types to underlying validators. Edge case handling will also receive significant attention, including scenarios where validators fail to include transactions they were expected to include.

The move from v1 to v2 represents a transition from proving that the concept works to proving that it works at scale and under adversarial conditions. Robin emphasized that many of the incentive mechanism details and fee split designs are still being finalized and will be tested during this phase. A paper detailing these mechanisms is expected to be published soon, providing more transparency into how the system will maintain security and proper incentive alignment at scale.

Validator Participation and Incentive Alignment

A key design goal of Raiku is ensuring that validators can participate in the value creation enabled by network extensions. When applications generate value through off-chain compute modules but submit transactions through standard channels, validators capture only standard transaction fees regardless of the application-level value being created. This creates weak alignment between validators and the systems that depend on them.

Raiku addresses this through the ahead-of-time block auction mechanism. Validators participating in Raiku auctions can capture fees from the block space they reserve, creating a direct economic relationship between validators and the applications using guaranteed inclusion paths. The exact fee split design is still being finalized, but the goal is clear: validators should have strong economic incentives to prioritize the reliability of systems that depend on them.

This alignment extends beyond simple economic incentives. When validators have a stake in the success of applications using their reserved block space, they're more likely to invest in infrastructure improvements, geographic distribution, and operational excellence. The relationship becomes collaborative rather than purely transactional. Robin sees this alignment as crucial for the long-term health of the ecosystem, noting that "you need to be directly working at the validator level while facilitating the communication with these other external systems."

Fire Dancer Compatibility and Future Client Support

Fire Dancer, the independent validator client developed by Jump Crypto, represents one of the most significant infrastructure projects in the Solana ecosystem. Its design prioritizes performance at every level, from network I/O to execution. Raiku's commitment to Fire Dancer compatibility before the Midnight release ensures that validators won't have to choose between client diversity and access to guaranteed inclusion infrastructure.

Supporting multiple validator clients is more complex than it might appear. Different clients may have different APIs, different internal architectures, and different performance characteristics. The sidecar component needs to work reliably with each client without introducing bugs or performance degradation. Testing this compatibility thoroughly is part of the testnet process, ensuring that Fire Dancer validators can participate in Raiku with the same reliability as Agave validators.

Client diversity is important for Solana's resilience. If all validators ran the same software, a single bug could affect the entire network simultaneously. By supporting both major clients, Raiku helps preserve this diversity while extending the network's capabilities. Validators can choose their preferred client based on performance, operational familiarity, or other factors without sacrificing access to advanced transaction infrastructure.

Alpenglow and the Future of Solana Performance

The conversation touched on Alpenglow, Anza's upcoming protocol upgrade that targets transaction finality as low as 50 milliseconds. This represents a dramatic improvement from current finality times and would make Solana even more competitive with traditional financial infrastructure. Robin expressed optimism about these improvements while noting that they don't eliminate the need for systems like Raiku.

Even with 50-millisecond finality, applications will still benefit from predictability about transaction inclusion ahead of time. Knowing that a transaction will be included at a specific slot is valuable even if confirmation comes quickly afterward. The combination of fast L1 finality with ahead-of-time inclusion guarantees could create unprecedented capabilities for blockchain applications.

Multiple concurrent leaders, another feature being explored for future Solana upgrades, could further improve throughput and reduce the timing games that create unfairness in transaction ordering. These protocol-level improvements complement rather than replace infrastructure like Raiku. Each layer of the stack contributes to the overall goal of making blockchain applications competitive with traditional systems.

Why This Matters for Solana's Competitive Position

Solana's competitive position depends on its ability to serve high-performance applications that other blockchains cannot support efficiently. While consumer applications and simple DeFi protocols can operate on many chains, applications requiring guaranteed inclusion, predictable latency, and high throughput have few options. Infrastructure like Raiku strengthens Solana's position in these high-value segments.

The alternative to native network extensions like Raiku is often application-specific L2s or centralized hybrid approaches. Hyperliquid, which Robin mentioned as an example, achieves its performance through a limited validator set operated by limited participants. This approach sacrifices decentralization for speed. By building on Solana with Raiku's extensions, applications can potentially achieve comparable performance while maintaining the security and decentralization properties that make blockchain valuable.

The 18.5x growth in developer mindshare that Robin cited reflects Solana's momentum in attracting builders. Sustaining this growth requires providing developers with the tools they need to build competitive applications. Raiku represents one piece of this tooling ecosystem, addressing specific challenges around transaction inclusion that become more important as applications scale and competition intensifies.

Building Teams and Open Positions at Raiku

Robin closed the conversation with an active recruiting call. Raiku is hiring across multiple functions, with particular emphasis on core engineering roles. The ideal candidates are Rust-native developers with experience working on validator clients or other low-level blockchain infrastructure. Experience with Agave client development would be particularly valuable given Raiku's current focus on Agave sidecar compatibility.

Beyond engineering, Raiku is also hiring for marketing and growth roles. Building infrastructure is only valuable if applications adopt it, which requires effective communication about capabilities and benefits. The growth team will be responsible for onboarding validators to the network, educating developers about integration options, and building awareness in the broader Solana ecosystem.

For those interested in contributing to Solana infrastructure at a fundamental level, Raiku represents an opportunity to work on challenging problems with significant ecosystem impact. The combination of research-grade incentive design, low-level systems engineering, and practical product requirements creates a diverse technical environment. Interested candidates can find more information at raiku.com.

The Path Forward for Network Extensions

Raiku's approach represents a broader trend toward network extensions that enhance L1 capabilities without creating separate, fragmented environments. This middle path between pure L1 operation and full L2 deployment offers a promising architecture for applications that need more than the base layer can provide while wanting to maintain composability with the broader ecosystem.

The success of this approach depends on several factors that will become clearer as Raiku moves from testnet to mainnet. Validator adoption is crucial—the system becomes more valuable as more validators participate, creating better geographic coverage and more available block space. Application adoption is equally important, as the economic sustainability of the system depends on demand for guaranteed inclusion paths.

The incentive mechanism design that Robin mentioned as a work in progress will be critical for long-term sustainability. Systems that rely on subsidies or unsustainable economics eventually fail. Raiku needs to create genuine value that applications are willing to pay for while distributing that value in ways that maintain validator participation and node operator engagement. Getting these dynamics right is challenging but essential.

Conclusion

Raiku represents an ambitious attempt to solve one of blockchain's most persistent challenges: making decentralized applications as performant as their centralized counterparts. By combining validator sidecars, a decentralized coordination layer, and ahead-of-time block auctions, the system offers guaranteed transaction inclusion, reduced network spam, and predictable execution for high-performance applications.

The technical architecture preserves Solana's core strengths—composability, shared state, atomic execution—while adding capabilities that native L1 operation cannot provide. This approach avoids the fragmentation problems that have plagued L2 ecosystems while still enabling the performance improvements that demanding applications require.

Currently in testnet with v2 development underway, Raiku is positioned to ship significant capabilities to mainnet in the coming months. For developers building trading systems, solver networks, oracle infrastructure, or other performance-sensitive applications, the arrival of guaranteed inclusion paths could unlock new possibilities that weren't previously feasible on any blockchain.

The broader significance extends beyond Raiku itself. As more projects explore network extensions and off-chain compute modules that coordinate with Solana, the infrastructure for these systems becomes increasingly important. Raiku's focus on preventing fragmentation while enabling extension represents a design philosophy that could shape how the Solana ecosystem evolves. If successful, it demonstrates that blockchains can extend their capabilities through careful coordination rather than fragmentation into isolated environments.

Facts + Figures

• Raiku consists of two primary components: a validator sidecar that integrates directly with validator software and a coordination node that facilitates ahead-of-time block auctions

• The validator sidecar is currently compatible with Agave and will support Fire Dancer before the Midnight release later this year

• Sidecar installation on Agave validators takes approximately 30 to 60 minutes and includes pre-built dashboards

• Inclusion signals are sent every 40 milliseconds currently, with plans to decrease to 20 milliseconds

• Applications can receive inclusion signals up to 60 seconds ahead of time for transaction planning

• Developer mindshare on Solana increased 18.5 times between 2023 and 2025

• Up to 96% of transactions are dropped in high-frequency trading scenarios on Solana

• Physical latency limits mean even optimized L1s hit approximately 120 milliseconds as a floor

• Jito historically reserved approximately 5-6 million compute units (roughly 10% of block space) for bundle auctions

• Jito reduced their mempool delay from 200 milliseconds to 50 milliseconds

• The coordination layer will ultimately consist of 100 to 500 nodes run by vetted operators

• Raiku is currently operating testnet v1 with v2 expected after summer 2025

• Alpenglow upgrade targets 50-millisecond transaction finality for Solana

• Robin has been in crypto since 2015, starting with research in the Hyperledger project

• Robin transitioned from Ethereum to Solana at the end of 2023

• The Raiku testnet is live and accepting validator participants

• Raiku is actively hiring Rust-native core engineers with low-level blockchain experience

• Pricing modules will be open for development by searchers and other market participants

• The coordination layer is not an L2—it doesn't hold keys or process execution

• Differentiated block space allows different features for different use cases, like discounted lanes for oracles

Questions Answered

What is Raiku and what problem does it solve?

Raiku is infrastructure for guaranteed transaction inclusion on Solana, solving the predictability problem where applications currently send transactions hoping they'll be included without any certainty. Through validator sidecars and a coordination layer, Raiku enables ahead-of-time block auctions that let applications secure block space before sending transactions. This eliminates the uncertainty of transaction inclusion that particularly affects high-performance applications like trading systems and solvers. The system also reduces network congestion by eliminating the need for aggressive retry logic that applications currently use to cope with failed transactions.

How is Raiku different from Jito bundles?

While both systems aim to improve transaction inclusion, they differ architecturally in important ways. Jito sends transactions to a mempool where searchers compete to construct profitable bundles, introducing a delay (now 50ms, previously 200ms) before transactions reach validators, and breaks continuous block building. Raiku instead establishes inclusion paths ahead of time through block auctions, then sends transactions directly to validators through pre-established channels. This means Raiku doesn't introduce additional delays in the transaction path itself—the coordination has already happened before the transaction is submitted. This makes Raiku particularly advantageous for latency-sensitive applications.

What are inclusion signals and how do they work?

Inclusion signals are notifications sent to applications indicating their reserved block space and when their transactions can be included. These signals are currently sent every 40 milliseconds, decreasing to 20 milliseconds in future versions, and can arrive up to 60 seconds ahead of the actual block. This gives applications substantial time to plan their transaction submission strategy, knowing with certainty that their transactions will be included. For trading applications, this predictability enables strategies that would be impossible with uncertain inclusion, as they can commit to positions knowing their transactions will execute.

Does Raiku create fragmentation like Ethereum L2s?

No, Raiku explicitly avoids the fragmentation problems of L2s by not creating a separate execution environment. The coordination layer doesn't hold keys or process state—it only facilitates communication and pre-reserves block space on Solana. Applications using Raiku are still Solana applications, executing transactions on the same shared state as applications that don't use Raiku. This preserves the composability that makes Solana DeFi powerful. Smart contracts called through Raiku are the same contracts other users interact with, and atomic composability between applications remains intact.

Who are the target users for Raiku?

The primary target users are high-performance financial applications where transaction inclusion guarantees create tangible value. This includes perpetual exchanges where solvers face pricing risk during transaction processing, high-frequency trading systems that currently see up to 96% transaction failure rates, and oracle networks that need reliable inclusion for constant price updates. Native L1 DeFi applications can also benefit by upgrading their underlying infrastructure with Raiku's transaction types. The common thread is applications where predictability and reliability matter more than the marginal costs of guaranteed inclusion.

What is the current development status of Raiku?

Ra