Raiku: Solana’s High-Performance Edge Compute Layer

Explore how Raiku brings deterministic execution to Solana, enabling applications to run with precision, reliability, and speed.

Modern blockchains have achieved scale, but not certainty. While Solana leads on throughput and latency, it still lacks reliable execution guarantees for high-stakes applications. Raiku introduces a programmable coordination layer that restores determinism, predictability, and trust to onchain systems without compromising performance. Built as a sidecar to Solana’s validator network, Raiku enables developers to reserve blockspace ahead of time, schedule transactions precisely, and avoid all the mempool chaos.

This paper explores how Raiku brings execution guarantees, MEV resistance, and pre-confirmation to Solana’s monolithic architecture, offering a system built not just for speed but for reliability in a distributed, adversarial world.

The State of Blockchain Architecture and the Need for Execution Certainty

Global markets demand certainty. Crypto, too often, offers only hope.

Today’s blockchain infrastructure is riddled with architectural compromises. In the pursuit of scale, we've built systems that violate core distributed computing principles, assuming infinite bandwidth, ignoring latency ceilings, and forcing universal state models on applications that don’t need them. The result? Fragile abstractions, unreliable performance, and a developer experience that feels more like survival than innovation.

Imagine launching a modern financial product and being told your transaction might fail, unless you spam it, bribe the validator, or just pray for inclusion.

Blockchain systems are ultimately supposed to abstract that complexity, offering decentralized infrastructure that "just works." But instead, we’ve traded server racks for validator nodes, and latency issues have simply moved from physical hardware to Layer-1 congestion.

This is the daily reality in Web3. Ethereum, the most widely used smart contract platform, handles just 15–30 transactions per second. During high demand NFT drops, liquidations, memecoin seasons, the base layer clogs, fees spike, and L2s are the only escape hatch. These Layer-2 rollups offer massive throughout with reduced gas fees by shifting execution off-chain, but bring new tradeoffs: fragmented liquidity, complex bridging, divergent trust models, and a somewhat fractured user experience.

Meanwhile, Ethereum’s restaking ecosystem introduces even more fragility. Protocols like EigenLayer ask validators to secure third-party systems with Ethereum’s social consensus, effectively betting that if anything breaks, the community will coordinate a bailout. Even Vitalik has flagged this approach as dangerously “high-risk.” Scaling Ethereum is still a 10-year roadmap. Builders need something now.

Solana, on the other hand, pursued a high-performance monolithic design: it keeps consensus and execution in one chain, enabling very fast block times and parallel execution. In practice Solana regularly processes 3,000–4,000 TPS on a global state machine, far outpacing Ethereum’s throughput. This design yields low fees and near-instant finality under normal conditions. However, Solana’s single-chain architecture has also shown stress under extreme load. During periods of surging usage, Solana has experienced congestion and even outages, as every dApp competes for the same global resources.

For example, a dramatic increase in traffic (e.g. a popular NFT mint or arbitrage bots) historically led to stalled blocks and transaction failures. Notably, in Feb 2024 a bug triggered by Solana’s runtime caused a nearly five-hour network halt. Even when the network stays up, users and bots often see transactions fail or time out during peak demand, undermining Solana’s otherwise strong user experience. In fact, high-frequency traders on Solana have observed failure rates up to 75% for transactions when the network is congested. This happens because Solana’s leader schedule and QoS (quality-of-service) prioritization favor certain validators, and when too many transactions flood in, many simply never get included in time.

Beyond throughput limits, both ecosystems struggle with MEV exploitation and unpredictable execution. Solana, despite using a public leader schedule, faces its own MEV dynamics. Solana’s stake-weighted transaction scheduling means large validators or order flow specialists can cut deals to prioritize certain transactions off-book. This lack of transparency leads to centralization concerns, where well-connected bots or firms get fast-lane access while regular users’ transactions struggle. Although Solana has introduced priority fees and solutions like Jito (a specialized MEV-aware client) to bring more open fee markets, the underlying issue remains: when the network is busy, inclusion becomes a bidding war or insiders’ game, and ordinary users face uncertainty and slippage.

On the state side, Ethereum’s rollup-centric model fragments applications across chains. Each rollup becomes a silo, requiring bridges, redundant tooling, and extra security assumptions. Composability, the magic of DeFi, dissolves when liquidity and contracts are no longer co-located.

What’s missing is scale without latency spikes, state fragmentation, or failed trades. The precision global finance requires but blockchains still lack.

This is the design space Raiku occupies.

Born from years of Ethereum infrastructure frustration and a deep respect for clean system design, Raiku introduces a new class of infrastructure to Solana, one built not around more rollups, but around precision execution. It extends Solana’s core by offering programmable building blocks—Edge Compute environments—that give applications their own fast lanes, guaranteed bandwidth, and deterministic settlement without managing a separate chain or breaking composability.

If Solana is the global highway, think of Raiku as the intelligent traffic control system, enabling express lanes for the applications that need them most.

This isn’t another rollup. It’s not a sidechain. Raiku is a rethinking of blockchain execution: fast, modular, programmable, and predictable. A system forged not to chase trends, but to meet the demands of institutions, builders, and global-scale applications that need certainty, not hope.

From Limitations to Vision: The Genesis of Raiku

Raiku was born from a simple observation: not all blockchain workloads need to run in the same crowded kitchen. In late 2023, a team of researchers and Solana veterans began asking how they could offload heavy computations from Solana’s L1 without losing the benefits of being on-chain. This initiative started as a research project (supported by Superteam and the Solana Foundation) out of frustration with the “stagnation” they perceived in Ethereum-centric infrastructure. Ethereum’s ecosystem, while rich in Layer-2s, hadn’t delivered the kind of leap in performance or developer experience these researchers hoped for, rollups were making incremental progress but still tied to a relatively slow and congested base layer. By contrast, Solana represented a chance to try something different: its L1 was already fast and proved that a web-scale blockchain was possible, yet it too could improve by evolving its architecture.

Raiku team noted that by January 2024, many Solana applications were “naturally gravitating” toward an extensions architecture, or, in other words, projects were attempting to build their own mini-rollups or isolated execution layers to scale the base layer throughput even further. Lacking an official framework, some teams tried repurposing tools like the Sovereign SDK (meant for standalone chains) to create Solana extensions or arguably “rollups”. The results were suboptimal: misusing an Ethereum-oriented rollup framework on Solana led to poor performance and lots of friction. Every project rolling their own extension would cause state fragmentation (“basically moving towards all the problems that Ethereum has) and duplicated effort. More importantly, these DIY solutions did not integrate cleanly with Solana’s design, they ran into data throughput limits, timing issues, and inability to share state or accounts with L1.

This pattern highlighted a clear design problem: Solana needed a purpose-built extension framework, not one shoehorned from elsewhere.

Raiku’s founding team, led by Robin A. Nordnes and others, set out to solve this by building an “edge compute” layer tightly coupled to Solana from first principles. They chose Solana after surveying other new L1s like Aptos and Sui, concluding that Solana was uniquely positioned to support their vision. Solana had a critical mass of users, a strong developer community, and fundamentally sound architecture (often likened to an early, rapidly improving Ethereum). Importantly, Solana’s leadership and ecosystem were willing to innovate, core developers shipped updates every couple of weeks, and there was appetite for new approaches to scaling. The idea was not to launch yet another independent L1, nor to create a completely separate shard, but rather to extend Solana in a complementary way.

As one team member put it, “We’re not an L2, we’re not an L1... we’re somewhere in between.” More formally, Raiku positions itself as the block building architecture, an infrastructure protocol that connects validators, applications, and the base chain to orchestrate high-performance execution beyond what the base layer alone can provide. If Solana L1 is the highway, Raiku builds the express lanes and traffic control system that allow certain applications to operate with significantly greater speed and predictability when required.

A key insight driving Raiku’s design is that many high-scale dApps do not require constant interaction with the entire global state. Some applications can run largely isolated (their own orderbook or game engine logic) as long as they can occasionally settle to the main chain and leverage its security and liquidity when needed. As Nordnes explained, “most use cases with large-scale potential do not require state composability at all times”. You can sandbox an application’s execution in its own zone (like an L2), but still get the benefits of the base chain for things like settlement finality, shared user accounts, on-chain price data, and asset security.

This realization underpins Raiku’s architecture: it seeks to give applications their own sovereign execution environments (so they aren’t bottlenecked by others) while maintaining the advantages of Solana’s L1 (one unified asset and identity space, and a high-performance settlement layer). In the Ethereum world, one could try to achieve something similar by launching an optimistic or ZK rollup, but as the team noted, “you can build as an L2 in Ethereum, but you’re still severely restricted by the underlying L1”. Even the best rollup will be limited by Ethereum’s data posting throughput, latency, and upgrade timeline (“fixing the L1 is going to take a decade”). Instead of waiting on that, the Raiku team saw an opportunity to leverage Solana’s strengths today and innovate on top of them.

Raiku would introduce a new layer running alongside Solana’s consensus, operated by (and economically aligned with) the validator community, to coordinate advanced execution features. The vision was bold: make on-chain apps “faster, more reliable, and market-competitive” with Web2 and TradFi systems like AWS or NASDAQ, all without compromising decentralization.

By early 2024, this vision gained traction. The concept of Solana “extensions” became a hot topic, and the community settled on that term (or “network extensions”) instead of “L2s” to emphasize adding to L1 rather than forking away. Raiku emerged as one of the leading projects implementing this concept.

Technically, an extension is similar to a rollup or sidechain, and it’s stigmatized and perhaps downplays what the Raiku team is building. Raiku embraced the term “Edge Compute” to describe its execution zones. The phrase “edge compute” is borrowed from traditional IT (where it means computation done at the edge of the network, closer to where it’s needed). Raiku’s edge compute environments aren’t separate blockchains in competition with Solana, instead, they are modular execution zones at the edge of the Solana network, purpose-built to handle specialized workloads with deterministic performance. It’s a term that resonates with Web2 infrastructure teams and institutional players, bridging the conceptual gap between “rollups” and the familiar idea of edge servers. In essence, Raiku provides custom rollup-like environments (“extensions”) integrated as Solana edge compute zones. This gives developers execution sovereignty, i.e. freedom to run their own logic and scheduling, without the headache of launching an entirely new chain or fragmenting users across ecosystems.

Redefining Rollups: From “Extensions” to “Edge Compute Environments”

It’s worth highlighting how Raiku is reshaping the landscape around custom execution environments. In Solana circles, the term “extensions” emerged to describe these Solana-tailored rollups. However, the Raiku team felt that term was a bit narrow (and even “stigmatized” by early rough attempts). To capture the imagination of both crypto and traditional web2 audiences, what Raiku is building is more than just extensions, they’re building “Edge Compute environments”.

Source: https://x.com/owocki/status/1830621049190560061

With Raiku’s Edge Compute environments, we’re no longer thinking of a Layer-2 as an external add-on that lives on top of L1, but rather an integral part of the network’s architecture, an extension of L1 that lives at the network’s edge, close to the users and applications. By calling them “modular execution zones”, Raiku emphasizes that you can plug in different modules (each module being an execution runtime/VM) to one coherent system. These modular execution zones allow developers to plug different execution runtimes or custom virtual machines into one cohesive system, empowering them to shape low-level application logic with unparalleled control.

The Raiku team believes that performance at scale isn't patched in, it's built in from the outset. Raiku begins precisely where others stop: at the physical boundaries of bandwidth, geography, and time constraints inherent to distributed networks. Specifically, Raiku delivers:

• System reliability that maintains robust operation even under extreme load and pressure.

• Deterministic execution guaranteeing predictable outcomes for every transaction.

• Low latency by placing high-performance edge computing (HPEC) capabilities directly at the edges of the Solana network, enabling transaction processing within milliseconds.

• Developer freedom to customize low-level logic, providing unmatched flexibility and control.

Raiku’s Coordination Engine orchestrates transactions with precision, ensuring they are sent, scheduled, and confirmed swiftly, supported by a sophisticated ahead-of-time blockspace marketplace that guarantees inclusion (more on this in the later sections). Validator Plugins power both ahead-of-time (AOT) and just-in-time (JIT) execution. Combined with proof streaming, these plugins allow for instant pre-confirmation of transactions, turning today’s unreliable, best-effort interactions into dependable and scheduled execution.

Edge compute environments have practical implications. It helps differentiate Solana’s approach from Ethereum’s in the narrative: Ethereum has “Layer-2 rollups”, Solana (via Raiku) has “Edge Computes”. The latter suggests enhancement rather than separateness. It is a term that traditional finance will understand. In enterprise computing, edge compute is a positive concept, it implies faster response by moving compute closer to where it is needed.

Raiku is effectively saying: we move execution closer to the app (in a logical sense) while still being anchored to the main network.

So, in this report we’ve consistently used “edge compute environments”, “extensions”, and “modular execution zones” somewhat interchangeably, to reflect how Raiku’s idea might be referred to. Going forward, as Raiku hits mainnet and more marketing, you’ll likely see “Raiku Edge Compute” as a branded term, much like how Polkadot has “parachains” or Avalanche “subnets”. This terminology also makes it easier to convey new capabilities: for example, Raiku can say “deploy your own edge compute environment on Solana in one week”, which sounds like setting up a cloud environment, thus familiar to developers.

By emphasizing “edge compute”, Raiku aligns itself with the broader trend in web infrastructure where logic is moving closer to the user (edge networks, CDNs, etc.) for speed, except here the “user” is the application transaction, and the edge is a special zone in the network. It’s a powerful analogy that could help more people grasp how Raiku differs from just another scaling hack.

Raiku’s design is guided by a few key principles:

Not all dApps need continuous global state:

Some of the highest throughput applications (exchanges, games, payment networks) can operate in siloed environments for most of their activity, tapping the main chain only when needed. Raiku embraces this by providing opt-in isolation, freeing those apps from the global mempool competition, while still giving them access to L1 liquidity/state when necessary. This stands in contrast to the Ethereum DeFi ethos where everything is highly interwoven on one chain (which is powerful but doesn’t scale when every minor app demands global atomic composability). By recognizing that temporal or contextual composability (only when needed) is enough for many cases, Raiku achieves massive performance gains.

Keep the one-network feel:

Despite introducing modular zones, Raiku strives to avoid the multi-chain UX headaches. The global accounts and orchestration engine ensure that from a user’s perspective, Solana remains one network. You don’t need to manage multiple tokens for gas on different chains/ zones or switch RPC endpoints manually. You interact with Solana, and under the hood Raiku may route your transaction to an extension or the main chain as appropriate. This is a stark difference from, say, the Cosmos app-chain model or even Ethereum’s L2 landscape, where using a new chain means new tokens, new block explorers, and a mental shift.

Raiku’s edge compute zones are much like “network extensions” rather than independent networks, signaling that they extend Solana rather than compete with it. The architectural advantage here is network effects preservation: SOL token’s utility still underpins the whole (fees, staking), and Solana’s community isn’t split among dozens of mini-chains. This addresses a common critique of Ethereum’s rollup-centric roadmap, that Ethereum might become just a settlement layer while user activity migrates to various L2 tokens and ecosystems, potentially diluting Ethereum’s economic security. Raiku’s approach adds capacity and keeps it under the Solana economic umbrella.

Leverage existing security, don’t reinvent it:

Raiku does not create a new base consensus mechanism or require users to trust a brand new validator set with their funds (in fact, Raiku won’t custody funds separately, assets remain on Solana). This is a major advantage over launching a sovereign appchain or a new L1. If a project today chooses to start its own chain (whether via Cosmos SDK, Avalanche subnet, or some sovereign rollup), it faces the monumental task of bootstrapping validators, incentivizing them (often via inflationary new token rewards), and securing bridges back to other ecosystems. Raiku shortcuts this by building on Solana’s validator community and bridging natively via global accounts.

There’s no separate bridge contract, the extension is logically part of Solana. This dramatically lowers the security risk and development overhead compared to sovereign chain approaches. For example, teams who tried Sovereign SDK on Solana ended up with state fragmentation and poor performance because Sovereign SDK wasn’t made for Solana’s context. Raiku’s custom solution avoids those pitfalls and maximizes reuse of Solana’s battle-tested components (like its networking, validator incentives, etc.).

Predictability and transparency as core features:

Both builders and users value knowing what will happen. Raiku bakes predictability at the protocol level. Inclusion signals remove the guesswork from transaction submission. MEV is handled by design (no private mempools, everything goes through auctions or known channels. This fosters a healthier ecosystem.

On Ethereum, despite improvements, users still fear being sniped by an arbitrage bot the moment they send a Uniswap trade. On Solana, users fear transactions “not going through” when the network is busy. Raiku wants to eliminate those fears, making the blockchain feel reliable and “boring” in the best way, like AWS infrastructure where if you schedule a job, you trust it runs on time. This is a key selling point for institutional adoption (who require SLAs and predictability) and for broad consumer use (no one wants to spam “Submit” hoping one transaction sticks).

Real-World Use Cases Enabled by Raiku’s Edge Compute Design

What can developers actually do with Raiku that they couldn’t before? The answer: build on-chain applications with the speed and guarantees of off-chain systems, and deploy new types of services on Solana that previously might have required a separate chain or centralized solution. Let’s explore a few illustrative use cases that Raiku’s team and community have envisioned, highlighting how the edge compute approach makes a difference:

High-Frequency Trading and Exchanges (Drift Protocol’s Swift as an example):

Drift is a leading Solana-based perpetuals exchange that processes large volumes of trades. In early 2025 they introduced Swift Protocol, an on-chain ultra-low-latency matching engine built directly on Solana. It keeps the order book and matching logic on-chain, then routes filled trades to Drift’s perpetuals program for settlement. While innovative, Swift still faces a limitation: when it comes time to settle those matched trades on Solana L1, it’s subject to the usual network conditions and could experience delays or contention (especially during volatile market moves when many exchanges are active).

Enter Raiku: a Drift-like DEX could deploy an edge compute extension specifically for its trading engine. In this extension, orders could be matched and immediately finalized on-chain (in the extension) with microsecond precision, far faster than even Solana’s 400ms block time. The extension could use Light SVM optimized for trading, enabling thousands of operations per second (e.g. matching bids and asks, updating trader positions) with deterministic timing. Crucially, using Raiku’s guaranteed inclusion, once a trade is matched, it can be scheduled to settle on the next Solana block with zero uncertainty. No more racing the clock or praying your transaction gets in, the trade settlement is reserved and confirmed ahead of time.

This means Drift could offer execution guarantees akin to NASDAQ, something unheard of in DeFi. Swift Protocol currently can’t guarantee exactly when a Solana settlement lands or that it won’t be front-run. With Raiku, they can guarantee inclusion and timing, solving that problem. In effect, Raiku could turn a decentralized exchange into a low-latency trading platform where market makers and arbitrageurs can operate on-chain with confidence.

Beyond Drift, any exchange or AMM could benefit, imagine an on-chain order book that updates prices every 100ms in a dedicated extension without bogging down the mainnet. Raiku’s design even supports HFT (high-frequency trading) strategies: as stated on their website, you could execute “thousands of cross-exchange trades per second with microsecond precision and guaranteed settlement timing,” giving quantitative traders an institutional-grade DeFi infrastructure. This is exactly the kind of performance unlock that could bring serious trading firms into DeFi, when they no longer have to worry about network jitter or unpredictable failure rates.

Payments and Fintech Infrastructure (e.g. “Stripe-like” payments, Squads):

Payment applications demand both high throughput and high reliability. Consider a scenario like Stripe on Solana, a service handling thousands of transactions per second for merchants, payroll, micropayments, etc. On Solana L1, this is possible in theory (given the high TPS), but in practice if the network gets congested or if a program in one payment workflow eats too many compute units, others might fail.

With Raiku, one could create a payments extension, essentially a specialized (edge compute) zone for payment transactions. This extension could be optimized for simple token transfers, including specialised/optimised environments or Light SVM for maximum efficiency. Through Raiku’s bandwidth reservation, a payment operator (like a stablecoin issuer or a CBDC platform) could reserve throughput for, say, 500 tps continuously to ensure their transactions always go through regardless of external demand. Users sending funds would get instant inclusion confirmation (no stuck transactions).

For enterprise or institutional use, Raiku can enable private settlement networks on Solana: “private settlement channels between major financial institutions with deterministic finality and encrypted flows”.

Think of big banks settling FX trades or securities on a shared Solana extension, they could have their own Raiku extension with transactions visible only to the parties (via encryption, yet still verifiable) and guaranteed finality. This unlocks use cases like cross-border payments, remittances, or inter-bank settlements on a public chain, but with the predictability of SWIFT or FedWire.

On the consumer side, something like SquadX (a popular Solana multisig and coordination tool) could use Raiku to guarantee that multi-signature transactions (which might involve many instructions) execute reliably even during peak network times. A major pain point for DAO treasuries or multi-sigs is when you try to execute a complex transaction and it fails due to network issues, Raiku could eliminate that by allocating a dedicated slot when all signers have approved, so the multi-sig transaction goes through atomically. Essentially, Raiku can provide institutional-grade reliability for any critical transaction flow, “five nines” of success rate, as they say in cloud, which is vital if blockchain is to be trusted for payments at scale.

Moreover, with RFQ-style liquidity integration, Raiku could empower new payment models: for instance, a decentralized payment app could query market makers via Raiku’s RFQ system to get the best conversion rate for a currency swap as part of a payment, all settled within one extension with no slippage or MEV. This is analogous to how Stripe routes payments through various banks to optimize fees and success, Raiku could let crypto payments route through various liquidity sources in a controlled, deterministic manner.

DeFi Protocols and Services (beyond trading):

Beyond exchanges, many DeFi protocols can benefit from Raiku’s edge compute environments. Lending platforms could use them to perform instant liquidations via dedicated channels (Raiku even enables “automated risk management with microsecond precision”,meaning a lending protocol could monitor positions and execute liquidation transactions in a guaranteed time window, reducing bad debt). Options and derivatives platforms could coordinate complex multi-leg strategies across venues by using an edge compute zone as a co-ordination hub, with Raiku guaranteeing all legs execute atomically in consecutive slots.

For instance, an options DEX could ensure that when a user rolls over a position (closing one option and opening another), both transactions happen back-to-back with no gap for price movement. This level of control is currently only feasible in centralized systems. Stablecoin issuers could benefit as well: imagine USDC could use a Raiku extension to manage its mint/redeem flows in large batches with priority, ensuring big redemptions don’t clog the network or get front-run. By allocating blockspace, they maintain smooth operation even in stress times.

Hybrid CEX/DEX and Institutional Access:

Raiku could blur the line between centralized exchanges and DeFi. Its architecture allows something like a “regulated DeFi zone” where only KYC’d entities (say institutions) participate, enabling compliance while still settling on Solana. The site hints at “hybrid CEX/DEX exchanges with superior UX”, a scenario where a central venue (or consortium) provides liquidity but trades settle on a public network extension. With edge compute, such a platform could offer the speed of a CEX (matching engine on dedicated hardware) and the transparency and custody benefits of DeFi (settlement on Solana). Institutions could use this to trade on DeFi markets without dealing with retail traffic or uncertain fees, since they might have their own extension or guaranteed lanes. Over time, this could attract significant volume from traditional finance into the Solana ecosystem, as Raiku can meet their performance and privacy needs (e.g., encrypted order flows in a private extension).

Non-Financial Apps (Real-time Games, Social, AI Agents, IoT):

While Raiku’s focus seems to start with DeFi and the financial markets, the framework is broadly applicable. For real-time games or virtual worlds, Raiku could support an extension that handles rapid game state updates (imagine a fully on-chain fast-paced game, Raiku’s scheduling could guarantee actions happen in a timely tick system). For social networks or messaging apps on Solana, Raiku could provide throughput to handle spikes in activity (say a viral post causing thousands of reactions, handled in an extension so the main chain isn’t flooded).

The website’s use cases explicitly mention bringing “AI Agents, DePIN, Social Networks, Payment Infrastructure, Capital Markets, HFT Trading, The Internet to Solana”. This sweeping vision suggests Raiku sees itself as enabling any high-demand application that today might think a blockchain can’t handle their scale or speed.

For example, AI agents that perform dozens of on-chain actions per second (perhaps bidding in auctions, rebalancing portfolios, etc.) could utilize Raiku to get those actions processed reliably. DePIN (projects like Helium or decentralized Uber/Airbnb concepts) often require lots of micro-transactions and device interactions, Raiku could ensure IoT devices have reserved throughput to log data or settle payments consistently.

In all these cases, the common theme is that Raiku enables a level of performance and trust that wasn’t possible on a single L1. It lets developers think bigger, to imagine on-chain services matching the responsiveness of centralized servers.

An example: if Solana is already very fast for blockchain, Raiku makes “fast” the default even under load, much like a well-provisioned cloud server that auto-scales capacity for your app.

The edge compute model is particularly attractive to projects that considered launching their own chain for performance reasons: now they can get similar benefits while plugging into Solana’s ecosystem, with a shared global state and full composibility. We may see projects from Ethereum L2s or other ecosystems “orbit” to Solana via Raiku. In fact, Raiku explicitly plans to court EVM-compatible protocols in its go-to-market, showing them that they can deploy on Solana with minimal friction and huge performance gains.

Raiku’s Novel Approach: Execution Consensus Separation with Predictable Performance

Raiku introduces a new block-building architecture that improves Solana’s base layer from within. It does this by enabling programmable coordination, allowing validators and applications to engage in more deterministic execution without introducing separate consensus or fragmented environments.

One can think of Raiku’s network as a specialized execution layer that runs in parallel to Solana’s main chain, powered by the same validator set, that simply opts in by running the Raiku sidecar. By doing this, Raiku frees intensive application logic from contending with all of Solana’s traffic, yet it’s not an island, it remains tightly synced with Solana for finality and data availability.

Unlike other ecosystems still wrestling with modular tradeoffs or fragmented execution models, Solana offers a high-performance, monolithic base layer. It delivers sub-second block times, ultra-low fees, and parallelized execution via Sealevel. These characteristics make it the most likely chain where ideas like just-in-time (JIT) or ahead-of-time (AOT) block auctions can be implemented at scale without prohibitive latency.

While Solana delivers fast block times, low fees, and parallelized execution through Sealevel, the current block construction process still has limitations:

• Validator profitability remains volatile, heavily reliant on native inflation subsidies and occasional MEV spikes.

• Transaction inclusion is unpredictable, particularly for applications that require atomicity, deterministic ordering, or pre-confirmations.

• Out-of-protocol coordination is rising, with protocols like Jito stepping in to address the lack of robust auction mechanisms and bundle execution guarantees.

What’s been missing is a programmable coordination layer, one that gives validators more consistent revenue opportunities, empowers dApps with reliable execution features, and plugs into Solana’s native architecture without compromising its low-latency, high-throughput properties.

Solana’s incentive and economic framework is evolving rapidly, guided by a series of critical Solana Improvement Documents (SIMDs). These proposals reshape core validator incentives, transaction priority mechanisms, and reward distribution, setting the stage for a more competitive and robust ecosystem:

• SIMD-0096: Redirects 100% of priority fees to validators, significantly increasing validator profitability and discouraging off-network side deals.

• SIMD-0123: Introduces a native, scalable protocol mechanism for validators to distribute rewards directly to stakers, enhancing economic alignment and transparency.

• SIMD-0228: would have introduced a dynamic, market-driven emission schedule by adjusting inflation according to staking participation levels to improve economic efficiency and security. (However, the proposal failed to reach the required two-thirds supermajority in its March 2025 vote and has not been activated)

While these changes focus on incentive alignment, they also amplify competition among validators, driving them to find new external revenue streams, especially important in bear markets when MEV and priority fee opportunities decrease.

This ongoing evolution in Solana’s market structure lays the foundation for Raiku’s orchestration engine, designed precisely to enable reliable, predictable, and high-performance decentralized execution.

The benefits of this execution–consensus separation are profound.

First is predictable inclusion: where normally a user’s transaction might sit in a mempool or queue and hope to be included in the next block (or be dropped due to a spike in load), Raiku’s design aims to offer hard guarantees on inclusion and timing. Transactions submitted via Raiku can receive an “ahead-of-time” confirmation of inclusion, effectively a reservation in an upcoming block. This is achieved through Raiku’s novel scheduling and auction mechanisms (which we’ll discuss shortly). For users and dApp developers, it means no more spamming transactions or anxiously waiting to see if a critical trade gets mined, you can know within milliseconds that your transaction is scheduled for a specific future slot. This focus on deterministic, predictable execution is a key differentiator. Traditional L2s on Ethereum can improve fees and throughput, but they generally cannot guarantee exactly when a transaction will land on L1 (especially for optimistic rollups with challenge periods). By contrast, Raiku provides time-slot guarantees on Solana, an L1 known for its 400ms block times. Raiku essentially extends Solana with a “global scheduler” that applications can tap into for reserved blockspace.

Another major advantage is failure isolation. In a monolithic L1, if one application (say, a popular NFT mint program) suddenly consumes huge resources or crashes, it can degrade or halt the entire chain. We’ve seen this on Solana, one dApp’s workload can cause network-wide slowdown. With Raiku, applications run in isolated execution zones, a.k.a. edge computes. If one of these zones faces an issue, for example, a runaway program consuming excessive compute, it won’t directly clog Solana’s main chain or other zones. The fault is contained to that extension environment. Solana’s consensus remains unaffected, and other extensions continue normally. This failure isolation is akin to having multiple “sandboxes” on the network: each application (or group of applications) can utilize a dedicated slice of capacity and even have custom parameters, without risking the stability of the whole. Traditional L2s offer some isolation (a fault on Arbitrum doesn’t halt Ethereum), but because they ultimately depend on L1 for proofs and bridging, a severe failure (or exploit) on a popular rollup can still have systemic effects (e.g. mass withdrawals through L1, or social pressure on L1 to intervene in case of a huge hack. Raiku’s close integration with Solana means extensions are first-class citizens of the ecosystem, but any given extension’s troubles don’t spill over. It’s like partitioning traffic into separate high-occupancy lanes, an accident in one lane won’t gridlock the entire highway.

Crucially, Raiku’s architecture preserves what both L1s and L2s aspire to: security and sovereignty. Each Raiku extension environment has execution sovereignty, meaning the application developers can customize the execution logic, VM, and parameters to their needs (it’s their “own chain” in that sense), but they do not need to bootstrap a new set of miners or validators from scratch. Raiku leverages a validator network that works in sync with Solana’s validator set. In practice, Raiku validators will be Solana validators opting to run Raiku’s software (a sidecar for the validator client), potentially earning additional fees for doing so. This means security is professional and robust from day one, you have an experienced validator set at the helm, and there isn’t a need for a separate token for security.

By separating consensus (still handled by Solana’s PoH/PoS for finalizing blocks) from execution (handled by Raiku’s scheduling and validator network), throughput scales up significantly. Solana no longer has to execute every single instruction of every program itself; it can outsource execution of certain programs to Raiku extensions and simply verify outcomes or proofs. This is a different philosophy from Ethereum rollups which fully verify proofs on L1 (often incurring high costs). Solana can instead trust its own validator-integrated network to do much of the heavy lifting, given the alignment of incentives and real-time cooperation.

In summary, Raiku is neither a standalone L1 nor a typical L2, it is an execution layer for Solana that introduces:

(a) execution–consensus separation (freeing apps from L1’s throughput limits),

(b) predictable inclusion and scheduling (no more probabilistic mempool games), and,

(c) robust fault isolation (one extension’s issues don’t threaten the whole)

It transforms Solana from a single-tier network into a multi-tier system: the base layer for consensus and global state, and an upper layer for high-performance application-specific execution.

Inside Raiku’s Technology Stack: Deterministic Settlement and Modular Execution

To deliver on its promises, Raiku introduces several novel components and transaction types. These can be thought of as infrastructure building blocks that work together to enhance Solana. Let’s break down the key elements of Raiku’s tech stack:

1. Ahead-of-Time Block Auctions & Inclusion Signals:

At the heart of Raiku is a new way of managing blockspace. Instead of the ad-hoc first-come-first-served mempool model, Raiku implements a slot auction marketplace. Applications or users can bid for upcoming slots on Solana (or rather, on Raiku’s coordinated schedule) in advance, securing priority for their transactions. The winning bids receive “inclusion signals” ahead of time, essentially a guarantee that their transaction (or bundle of transactions) will be included in a specific future block or sequence of blocks. These auctions are stake-weighted and atomic, meaning the scheduling respects the Solana stake distribution (validators with more stake have more capacity to include reserved transactions, aligning incentives) and transactions can be reserved in bundles that execute sequentially without interruption. The outcome is that a Raiku user can get a faster confirmation now that their “ticket” for execution is secured.

Compare this to the traditional experience: on Ethereum, you send a transaction and hope a miner picks it soon (maybe boosting the fee if you’re desperate), and even on Solana, you might spam several transactions to ensure one lands during congestion.

With Raiku, the process becomes akin to booking a train seat in advance rather than elbowing through a crowded platform. This system dramatically reduces failed transactions and uncertainty, one of Raiku’s core objectives is guaranteed execution.

Proof Streaming: Unlocking Large Payload Execution via Sequential Blockspace

One fundamental limitation in Solana today is strict per-block data constraints, designed to preserve fast block propagation. This can become a bottleneck for applications that need to submit large state updates, such as settlement engines or ZK rollup proofs.

Raiku addresses this through sequential blockspace reservations, a concept enabled by its Ahead-of-Time (AOT) block auction model. By securing a sequence of upcoming slots, applications can reliably stream large proofs or payloads in smaller, verifiable chunks, without hitting Solana’s per-block cap.

The idea is to break up large transactions or proofs into smaller pieces that can be streamed and verified over multiple slots, bypassing Solana’s strict per-block data limits. Practically, this means an application could submit a very large state update or proof (for example, a zero-knowledge proof or a batch of hundreds of trades) through Raiku, and Raiku will handle feeding this data into Solana in chunks that validators can handle.

Rather than submitting a large transaction that risks failure or bloat, applications can schedule and stream structured data across multiple slots, while validators process and verify it in a controlled manner.

2. Fast and Deterministic Settlement (“Guaranteed Execution”):

Many of the next-generation applications Solana aims to support, such as high-frequency trading platforms, real-time gaming systems, and institutional payment networks, demand strict guarantees that transactions will land exactly when and where they are expected. In these domains, execution uncertainty is not just a UX flaw; it is a deal breaker.

Unpredictable network congestion and mempool dynamics can result in transaction failures, reordering, or delays. For advanced use cases like automated liquidations, synchronized asset swaps, or arbitrage strategies, this unpredictability leads to missed opportunities and capital inefficiency.

Raiku addresses this gap with Guaranteed Inclusion through Ahead-of-Time (AOT) and Just-in-Time (JIT) slot reservations. For example, bots acting on real-time price movements may prefer JIT inclusion, while external systems may opt for scheduled AOT slots. In both cases, users pay for precision, both in timing and bandwidth (using a combination of Raiku tokens and SOL).

When a Guaranteed inclusion transaction is submitted through Raiku, it is assigned a reserved execution window, ensuring it is processed at the intended time and never dropped or reordered due to validator behavior or network congestion. While only the slot leader can include the transaction, all validators running the Raiku sidecar help propagate and acknowledge the schedule ahead of time. Raiku uses a pre-consensus scheduling system to coordinate transaction plans, which the slot leader then executes during block production.

By reserving blockspace in advance and assigning deterministic execution slots, Raiku mitigates peak failure scenarios where high-frequency users on Solana have historically seen failure rates exceeding 90 percent. It delivers guaranteed bandwidth, latency precision, and settlement predictability, even during periods of extreme load.

Guaranteed Execution also introduces MEV resistance by design. Since transactions are scheduled in advance and confirmed across the network, frontrunning is mitigated, and sandwich attacks are neutralized by incorporating expected value extraction into the auction mechanism itself. Private order flow deals that previously operated outside the protocol are no longer necessary. Instead, inclusion is handled transparently via a fair scheduling auction or reservation system.

For developers, Guaranteed Execution means you can offer your users a web2-like guarantee: e.g. a trade on a Solana DeFi app can be confirmed in milliseconds with certainty it will settle, no more “transaction dropped, please retry” errors.

3. Global Account Model and Unified State:

One of the most groundbreaking aspects of Raiku is its Global Accounts Module. This component (planned for V2 alongside proof streaming) tackles the state fragmentation problem head-on. The idea is to allow users and applications to maintain a unified identity and state across multiple execution environments.

In practical terms, a user would still have one Solana wallet/address that they use on the main L1 and across any Raiku extension they interact with. Assets and data can move seamlessly between the main chain and extensions without traditional “bridging.” The global account model will enable composability across extensions, so two Raiku extensions can interoperate or access a shared user state if needed.

This is a significant differentiator from typical L2s, where each rollup is a walled garden requiring a bridge to move assets and where accounts/contract addresses might be chain-specific. With Raiku, since extensions are more like “zones” within the Solana ecosystem, the user experience remains unified. Developers can deploy in an extension environment and still easily integrate with Solana-native programs or accounts.

For example, an order placed in a Raiku-powered orderbook extension could settle into a user’s main Solana wallet or be recognized by a program on L1, thanks to unified accounts. Technically, this might be achieved by having Raiku share Solana’s account address space and signature verification, or by having a mechanism to synchronize state roots between the extension and L1.

The outcome is that state fragmentation is solved, you get multiple execution environments with one combined state. As the Raiku team describes, this allows composability across extension environments, which is something neither Ethereum L2s (all separate) nor earlier Solana rollup attempts achieved. It’s a first-principles approach to ensure that scaling out doesn’t mean splitting the user base or liquidity.

The Global Accounts Module also supports multi-VM functionality. Raiku isn’t limited to Solana’s native VM (SVM), it is being built to potentially host different virtual machines under the same umbrella of coordination. In fact, Raiku aims to support EVM-compatible extensions, allowing projects from the Ethereum world to deploy their Solidity code as a Solana extension.

The mention of “projects like Arbitrum Orbit to deploy on Solana” suggests an Ethereum L3 or custom chain could effectively plug into Solana via Raiku. This is huge: it means an Ethereum dApp could enjoy Solana’s performance and user base without abandoning its codebase. All of this is enabled by global accounts, users wouldn’t even need to switch wallets or bridge tokens; the EVM extension would recognize their same wallet (possibly via an address derivation or mapping) and could use Solana’s native assets.

This suggests Raiku has a somewhat layered node architecture: normal users/apps talk to an Ackermann node (or cluster) which then interfaces with validators to schedule execution. It’s an interesting design for scaling input handling and ensuring the system can handle bursts of transactions by distributing them across validators effectively.

Concluding thoughts

Raiku’s emergence signals a turning point for Solana and blockchain architecture at large. It offers a vision where a decentralized network can achieve the reliability, speed, and flexibility that were once the exclusive domain of Web2 cloud or traditional finance systems. By introducing a coordination engine with deterministic execution, Raiku enables Solana to transcend the label of “just another L1” and become a platform for truly mission-critical, high-performance applications.

Consider what this means for developers: With Raiku, building on Solana can feel like building on a scalable cloud service.

• Need more throughput? just spin up an extension and reserve the slots you need.

• Need custom execution logic or a different VM? plug it in as an edge compute zone.

• Worried about user experience during peak times? offer guaranteed tx inclusion so users never see a failed transaction again.

The developer experience is significantly improved. Developers can build with confidence, knowing that the infrastructure will meet their app’s demands instead of the other way around. The base Solana chain acts as a stable backbone, while Raiku provides the agile, programmable scaffolding to push the limits.

This has the potential to attract not only crypto-native developers but also Web2 developers who have performance-sensitive use cases. They can come to Solana without worrying that the network might slow them down. In effect, Raiku could make Solana the preferred platform for any application that requires both decentralization and high throughput.

On the institutional front, Raiku could be the key that unlocks serious enterprise adoption of Solana. Banks, hedge funds, gaming companies, social media upstarts, all could finally feel comfortable building on-chain because the performance and control they require are available. Solana has already been one of the more institution-friendly chains (with firms like Jump investing in its tech); Raiku turbocharges that appeal by promising fine-grained execution control and high reliability. Institutional-grade means things like 99.999% uptime, transaction deadlines, privacy where needed, compliance hooks – all of which Raiku can facilitate (through isolated extensions, scheduling, etc.). We might see pilot projects like a stock exchange settlement network on Solana, or a large payment processor integrating Solana via Raiku for instantaneous global transfers.

The journey is just beginning, Raiku is in testnet, with mainnet slated for late 2025,but the foundational narrative and architecture are in place. It addresses the pain points we outlined at the start: scaling limitations (solved by adding modular throughput), MEV exploitation (minimized through predictable ordering and auctions), restaking challenges (avoided via a more contained approach), fragmented state (solved by global accounts), and performance issues (solved by guaranteed inclusion and fault isolation). Raiku thus emerges as a cohesive solution, not a piecemeal fix.

References

1. CoinShares. (n.d.). Ethereum’s major problem: Fragmentation. CoinShares Blog. https://blog.coinshares.com/ethereums-major-problem-fragmentation-aa80c71be455

2. CoinShares. (n.d.). Integrated vs. modular: Solana vs. Ethereum. CoinShares Blog. https://blog.coinshares.com/integrated-vs-modular-solana-vs-ethereum-b0438ef1e1dc

3. Cointelegraph. (n.d.). Solana vs. Ethereum: A detailed comparison of blockchains. Cointelegraph. https://cointelegraph.com/learn/articles/solana-vs-ethereum-blockchain-comparison

4. Hedera. (n.d.). Blockchain and edge computing. Hedera Learning Center. https://hedera.com/learning/data/blockchain-and-edge-computing

5. Helius. (n.d.). Solana permissioned blockchains. Helius Blog. https://www.helius.dev/blog/solana-permissioned-blockchains

6. Helius. (n.d.). What is Firedancer? Helius Blog. https://www.helius.dev/blog/what-is-firedancer

7. Kiln.fi. (n.d.). Ethereum L2 challenges and fragmentation. Kiln Blog. https://www.kiln.fi/post/eth-l2-challenges-fragmentation

8. Kiln.fi. (n.d.). What are Solana network extensions, and how are they different from Ethereum layer-2s? Kiln Blog. https://www.kiln.fi/post/what-are-solana-network-extensions-and-how-are-they-different-from-ethereum-layer-2s

9. Medium. (n.d.). AMA with Raiku founders: Problems and roadmap. Medium. https://medium.com/

10. Medium. (n.d.). MEV exploitation on Ethereum and Solana. Medium. https://medium.com/

11. Medium. (n.d.). Raiku technical offerings: Guaranteed Inclusion, Inclusion Signals, Proof Streaming, Global Accounts. Medium. https://medium.com/

12. Raiku Labs. (n.d.). Raiku Docs – Conceptual documentation. Raiku Documentation. https://docs.raiku.com/

13. Raiku Labs. (n.d.). Raiku Docs – Technical documentation. Raiku Documentation. https://docs.raiku.com/technical-docs

14. Solana Foundation (Colosseum). (n.d.). Raiku: Introduction and features. Colosseum Blog. https://blog.colosseum.org/

15. Solana Foundation (Colosseum). (n.d.). Solana congestion and failure issues. Colosseum Blog. https://blog.colosseum.org/

16. Terminal Technology. (n.d.). Network extensions #2. Termina Technology Blog. https://www.termina.technology/post/network-extensions-2

17. Unchained Crypto. (n.d.). Are Solana’s network extensions just like Ethereum’s layer-2s, but by a different name? Unchained Crypto. https://unchainedcrypto.com/are-solanas-network-extensions-just-like-ethereums-layer-2s-but-by-a-different-name/

18. Vitalik Buterin & Blockworks. (n.d.). Vitalik’s caution on restaking risks. Blockworks. https://blockworks.co/news/vitalik-buterin-restaking-risks

    ---

    Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

    Disclosures. All posts are the author's own, not the views of their employer. This post has been created in collaboration with the Raiku team. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.