Raiku: Solving Solana's Biggest Pain Points
Despite its high speed and low fees, Solana lacks the deterministic execution guarantee required to unlock institutional adoption, particularly during periods of network congestion.
Solana has become one of the fastest blockchains in the world. Over the past year, the network has processed billions of transactions each month with consistently low fees and sub-second finality.
But there’s a level of adoption Solana hasn’t yet unlocked: institutional capital operating at scale.
Walk into any trading floor at a major financial institution, any regulated payment processor, or any enterprise treasury operation, and you’ll encounter the same non-negotiable requirement: deterministic execution.
For a high-frequency trading desk executing strategies across multiple venues, each transaction in the sequence has to land in the exact slot and in the correct order. If even one transaction arrives late or out of order, the price can move, and a profitable trade can quickly turn into a loss. Similarly, for a protocol’s liquidation system protecting millions in collateral, a single slot’s delay can lead to millions in bad debt.
These operations don’t just need fast transactions or low fees. They need guarantees, cryptographic certainty that a transaction will execute exactly when and where intended, every single time.
Day-to-day, retail flows on Solana are reliable. But at institutional volumes, and especially during bursts of activity, the difference between “very likely” and guaranteed becomes the difference between clean P&L and a post-mortem. Teams need slot-exact, order-aware inclusion that holds even when the tape is hot.
What institutions optimize for is not just speed and low fees, but bounded variance, predictable SLAs, and auditability:
Bounded variance: Transaction landing times fall within a tight, predictable range, allowing trading strategies to accurately price execution risk and enabling insurers to confidently underwrite that risk.
Predictable SLAs: commitments that survive congestion, not best-effort targets.
What are the current fixes, and why do they fall short?
Solana’s ecosystem has already tried to patch reliability through upgrades and alternative clients, but neither solves guaranteed inclusion.
Agave is Solana’s validator client, and the v1.18 update was introduced to fix how transactions were scheduled. Before, they were mostly ordered by arrival time, so even if you paid a higher fee your transaction might lose out to spam or random thread ordering.
Agave created a new system to manage transactions more efficiently. Instead of processing transactions randomly, it organizes them into a clear order based on their priority fees (how much someone pays to get their transaction processed faster) and the resources they use. This makes the system fairer, prevents transactions from failing (reverts), and keeps costs stable for regular users, even when the network is very busy.
Big problems remain
Solana lacks strong economic disincentives to stop spam, so bots can still flood the network during peak demand. And even with Agave, users don’t get guaranteed inclusion: paying a higher fee doesn’t ensure their transaction will land. Some transactions never even reach the block leader in the first place, because they get lost at the networking layer, the system that streams transactions over QUIC connections from users to the validator leader. When those connections fail or throttle, the transaction simply disappears with no record at all.
BAM (Block Assembly Marketplace) by Jito was built to make Solana’s block building more structured. Instead of every validator assembling blocks on their own, BAM adds a coordinator layer where transactions are ordered inside Trusted Execution Environments (TEEs) and then sent back to validators to sign. This creates more predictable ordering and helps reduce certain kinds of MEV.
But the trade-offs are heavy. Routing all traffic through TEEs adds latency, transactions are encrypted, processed, and re-encrypted in single-threaded enclaves, which slows things down. That’s a serious problem for DeFi apps where milliseconds matter. Validators also lose autonomy, since they no longer build blocks themselves but just sign what coordinators provide. Power shifts to a small middle layer, developers face friction writing enclave-compatible plugins, and TEEs themselves add new risk surfaces, given their history of exploits.
In short: BAM improves structure, but it centralizes, slows down, and still doesn’t guarantee fast, deterministic inclusion.
Raiku: Enterprise-Grade Certainty
Raiku addresses these problems head-on. Its tech is built to ensure that transactions are processed predictably, quickly, and in a customizable order. Developers can book space for their transactions ahead of time or ensure their transactions are prioritized instantly, with confirmation in under 30 milliseconds. Validators use a simple add-on tool, called the Raiku Sidecar, that enforces these promises and provides new ways to earn money, all while keeping their existing software unchanged.
Raiku introduced guaranteed execution by ensuring that once a transaction is committed, it will land exactly where intended. This is not achieved through retries or congestion management tweaks, but through two new transaction types that fundamentally change how blockspace is consumed: Ahead-of-Time (AOT) and Just-in-Time (JIT).
Ahead-of-Time Transactions
AOT transactions are designed for operations where precision and predictability are critical. They allow users to pre-purchase a guaranteed inclusion slot for a transaction at a specific future time, at least 35 slots (>15 seconds) ahead. This turns blockspace into a resource that can be scheduled with confidence and eliminate the uncertainty that plagues time-sensitive operations on Solana today.
AOT follows a “Put me in this specific future slot” model. Users submit an intent that specifies the action, timing, and maximum fee they’re willing to pay. Raiku then books that transaction into the requested slot, guarantees its inclusion, and issues a pre-confirmation: an early, signed guarantee that the transaction is locked in place.
When to use AOT:
Repaying loans before hard deadlines (e.g., 14:03 UTC).
Publishing oracle updates on fixed intervals (e.g., every 30 seconds).
Institutional settlement windows that must be honored on time.
Rebalancing large vaults without risk of missed execution.
Running batch processes at optimal times to reduce costs.
Claiming staking rewards during low-fee windows.
Just-in-Time Transactions
If AOT transactions are about planning ahead, JIT is about acting in the moment. JIT transactions are built for situations where speed is everything, where being even a few seconds late means losing money, missing an opportunity, or failing to protect a protocol.
With JIT, users can purchase guaranteed top-of-block inclusion in the very next slot. This is especially powerful for latency-sensitive operations like:
Liquidations: Protocols can’t afford delays when a loan is under-collateralized. If a liquidation transaction doesn’t fire instantly, the system risks bad debt.
Arbitrage: Price differences between markets can vanish in milliseconds. Being even slightly late can turn profit into loss.
NFT mints or racing scenarios: When thousands of users rush to mint at once, only those with top priority get through. JIT guarantees your place.
Emergency rescue transactions: In fast-moving DeFi markets, protocols sometimes need to send a rescue transaction immediately to avoid cascading failures. JIT ensures it gets through without delay.
JIT transactions follow a first-price sealed-bid auction. You submit your bid, and the highest bidder secures the guaranteed slot. To keep the system fair and prevent spam, Raiku sets a minimum bid equal to Solana’s current priority fee plus a 5% premium. This model ensures that only users who truly value immediate execution compete for JIT slots, while keeping costs transparent and predictable.
Once a JIT transaction is submitted, Raiku immediately locks space in the leader’s next block. From that moment, your inclusion is guaranteed: no random drops, no waiting in queues, no hidden mempools. Execution is deterministic, and settlement happens within seconds.
If you win the bid, you’re in, no matter how congested the network gets.
AOT & JIT: Combined
For JIT, Raiku locks space in the next leader slot. For AOT, it books space in the exact future slot requested (e.g. 35+ slots or >15 seconds).
Within that slot, execution is fully deterministic: the highest bid goes first. However, when bids are equal:
JIT → earlier arrival wins
AOT → earlier booking wins
There are no hidden queues, no off-chain favoritism, just transparent slot-level ordering.
The Slot Marketplace
Raiku introduces the Slot Marketplace as the mechanism that makes its promises of guaranteed inclusion real. Instead of treating blockspace as a chaotic free-for-all, the marketplace enforces rules that make inclusion predictable and verifiable. How?
At its core, the Slot Marketplace does two things:
Ensures that if a slot is reserved, it will actually be honored by the validator running that slot.
Distributes responsibility based on validator stake, so stronger validators carry greater accountability for reliability.
There are 2 layers of guarantees: Slot-Inclusion Quality of Service (siQoS) and Stake-Weighted Quality of Service (swQoS).
Slot-Inclusion Quality of Service (siQoS) allows the current leader to provide credible guarantees about transaction inclusion and execution. Once a transaction is scheduled for a specific slot, the validator responsible for that slot must include it, with inclusion enforced at the protocol layer through the Raiku sidecar.
In Stake-Weighted Quality of Service (swQoS), reliability is tied to economic weight. Validators with more stake have higher obligations to deliver consistent service. This prevents small or poorly performing validators from weakening guarantees while ensuring the backbone of the network is secured by the most invested participants.
Primary vs. Secondary Market
Primary Market: This is where long-term reservations happen. Large institutions or validators can secure blockspace capacity in advance, like buying bandwidth contracts. It gives them predictability and aligns incentives with stability.
Secondary Market: Not every slot gets used. The secondary market reallocates unused slots in real time so nothing goes to waste. If bandwidth isn’t claimed, it gets reassigned to keep throughput high and fees fair.
Together, the primary and secondary markets ensure that blockspace is fairly allocated and never wasted. But demand isn’t static, sometimes enterprises need to plan ahead, and other times markets move suddenly and demand instant access, which takes us to dynamic balancing.
Dynamic Balancing
Think of slots like hotel rooms: AOT reservations are pre-bookings, JIT are walk-ins.
If every room is reserved, walk-ins get shut out: if everything is left for walk-ins, planners can’t book ahead.
Raiku avoids this by shifting capacity in real time, honoring AOT reservations while still leaving space for JIT, and opening more room for JIT when demand spikes without breaking AOT commitments.
The result is no starvation, fairer pricing, and full slot utilization.
Ackermann Siblings: Node and Sidecar
Just like in the Attack on Titan anime series, where Mikasa and Levi are related and share the Ackermann name, the Raiku series features a similar relationship between node and sidecar.
Ackermann Node acts as the planner. It receives transaction intents from the Ackermann SDK, runs the AOT and JIT auctions, determines which slots each transaction will occupy, and issues pre-confirmations that guarantee inclusion ahead of time. It also continuously monitors validator and Sidecar health to ensure that booked transactions are routed to the correct validator for execution.
Ackermann Sidecar is the enforcer, running directly alongside validators. Once the Node has assigned a transaction to a specific slot, the Sidecar ensures that this commitment is honored at the validator level. It accepts the pre-confirmed transaction, holds it locally until the precise scheduled moment, and then injects it directly into the validator’s block production pipeline, bypassing Solana’s QUIC transport layer and eliminating networking-layer drops that often cause transactions to disappear under congestion.
The Sidecar also applies strict bandwidth allocation and ordering rules. It enforces both siQoS and swQoS, ensuring that reserved transactions take precedence and validators handle their proportional share of network traffic fairly. Beyond enforcement, the Sidecar enhances network reliability by rerouting transactions to another healthy Sidecar if the scheduled validator is overloaded, without breaking the original inclusion guarantee.
Together, the Node and Sidecar form the coordination and enforcement backbone.
The Node plans and allocates blockspace, the Sidecar ensures those plans are executed precisely at the validator level.
If you want to learn more about the full technical design, please visit the official documentation.
Takeaways
Solana has proven it can deliver speed and low costs at scale. Recent improvements have significantly enhanced reliability for everyday users. But the next phase of adoption, bringing institutional traders, payment processors, AI marketplaces, and enterprise DeFi protocols to Solana, requires more than performance. It requires certainty.
Traditional finance operates on guarantees. When you submit a wire transfer, you know it will settle. When you place an order on a regulated exchange, you know it will execute according to the rules. When you schedule a batch payment, you know it will process on time.
Raiku brings that same level of certainty to Solana. It doesn’t replace Solana’s existing transaction model, retail users can continue using the network exactly as they do today. Instead, Raiku adds a premium layer for users and institutions who need deterministic outcomes and are willing to pay for that guarantee.
This is how Solana becomes more than a fast blockchain. This is how it becomes infrastructure that enterprises can build on with confidence.
Hazeflow is a blockchain & crypto research firm focused on underlying technologies, product approaches, and functions of blockchain products.
Written by Ishita Rastogi, reviewed & edited by Pavel Paramonov.