AOT/JIT: How to Prevent Transactions from Failing on Solana

When you submit a transaction on a blockchain and pay a fee, you expect two things: it should go through, and it should go through on time, meaning it lands in the block when you need it.

That’s how most digital systems work. You pay for Netflix, and it starts streaming. You tap your phone at a coffee shop, and your coffee is handed over. You book an Uber, and it confirms and arrives within minutes, not hours later.

On Solana, that reliability often breaks. A transaction might confirm, it might fail, or it might simply drop, meaning it never even reaches the block producer (the “leader” that assembles the next block) to be processed.

The scale is hard to ignore: in 2024, users sent ~25 billion transactions on Solana, and nearly half of them failed. And that’s not even counting the ones dropped before ever reaching the chain.

Timing makes the problem even sharper: if your transaction lands late by even a few hundred milliseconds, you can miss a liquidation, lose a winning NFT auction, or blow a hard deadline like an oracle update or loan repayment.

Different actions need different timing guarantees. Some must land immediately (a racing bid), some at an exact time (repaying before 14:03 UTC), and some just need to land cheaply without getting dropped (claiming staking rewards during a low-fee window).

That’s the gap Raiku fills with two execution paths, Just-in-Time (JIT) and Ahead-of-Time (AOT), that turn “hope my transaction lands” into deterministic inclusion you can plan around, even under heavy congestion. This reliability is crucial for high-value DeFi and real-time apps, and it noticeably improves everyday flows like transfers or staking rewards.

Why Do Transactions Break on Solana?

When you send a transaction on Solana, there are only three outcomes:

- It succeeds

- It fails

- It gets dropped

Failed transactions make it to a validator. They run, but they revert because conditions aren’t met, like slippage on a trade or a sold-out mint. Most of these aren’t real user errors but spam from arbitrage bots, who flood the network with cheap attempts. This clogs execution, burns compute, and adds noise.

Dropped transactions are worse for users because they never reach the validator, leaving no trace on-chain. From the user’s perspective, the transaction just disappears into thin air. Unlike Ethereum, which has a public mempool where pending transactions sit in view, Solana requires each transaction to connect directly to the current block leader via QUIC, its low-latency networking protocol. If that connection fails, there’s no fallback or record; the transaction is simply lost.

During congestion, this problem becomes worse. Leaders are overwhelmed by thousands of requests, mostly from aggressive bots running in parallel. Instead of dropping the lowest-fee transactions, the system drops connections randomly. That means even a regular user paying a fair priority fee can get cut off, while bots with thousands of simultaneous streams slip through. Lose the connection at that moment, and your transaction is gone forever, no failure log, no on-chain evidence, just silence.

In practice, most dropped transactions come down to two structural issues: spam that overloads leaders and the lack of protocol-level enforcement on priority fees.

Bad spam economics. On Solana today, there’s almost no cost to flooding the network with failed attempts. Arbitrage and liquidation bots can shotgun thousands of transactions in parallel because one profitable success easily pays for the hundreds that revert or disappear. This flood saturates leader connections, pushing out legitimate user transactions. When the leader is overwhelmed, some transactions never get through at all; they’re simply dropped.Around 92% of failed transactions aren’t from real users at all; they’re bot-generated.

Weak enforcement of priority fees. Solana lets you attach a priority fee to signal urgency, but it’s not a binding contract. Validators aren’t required to order strictly by fee; fee estimates differ across RPC providers, and many users rely on off-chain tips just to improve their chances. Without strict enforcement, high-fee transactions can still lose out during congestion, while spam continues to slip through. The result is that even paying more doesn’t reliably protect your transaction from being dropped.

Taken together, these problems leave users with no reliable way to buy certainty. You can’t pay to guarantee your transaction won’t be dropped, you can’t pay to shut out the spam, and you can’t pay to lock in an exact slot. What’s missing is a mechanism to reserve blockspace deterministically, at a known price, for a known time.

That’s where AOT and JIT come in.

What are AOT and JIT?

Being late by even a fraction of a second can mean losing money or missing a deadline. Raiku fixes this by introducing two execution paths that give you control over when your transaction lands, not just if it lands:

1. JIT (Just-in-time): “Put me in the very next slot.”

Use this for urgent actions where every sub-second matters—Liquidations that need to fire instantly, racing bots for an NFT mint, or a high-value swap that can’t afford a delay.

2. AOT (Ahead-of-time): “Put me in this specific future slot.”

Use this when timing is precise—repay before 14:03 UTC, schedule oracle pushes every 30 seconds, or batch jobs at a specific time.

‍

How does Raiku Work? 

1. Submit a Transaction Intent

Instead of sending a raw Solana transaction, the user submits a Raiku intent — a structured request that specifies:

- What the transaction should do (e.g. swap, repayment, liquidation),

- When it should execute:• Just-in-Time (JIT): in the next available slot,• Ahead-of-Time (AOT): in a specific future slot,

- How much they are willing to pay (maximum priority fee bid),

- Any conditions that must be met (e.g. “only if price ≥ $X” or “cancel if not executed by time Y”).

This gives Raiku full context: what needs to be done, when, and under what constraints.

2. Raiku Reserves a Slot and Sets Priority

Raiku’s coordination layer, powered by the Ackermann node, now handles slot reservation and execution ordering.

Analogy: Think of the Ackermann node like an air traffic controller. It doesn’t fly the planes (run the transactions), but it decides which flight lands when. Whether a flight is requesting immediate landing (JIT) or has a scheduled arrival (AOT), the controller allocates the runway, locks in the time, and ensures everyone lands in the right order — no chaos, no cutting in line.

In practice:

- 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.

- If bids are equal:• JIT → earlier arrival wins,• AOT → earlier booking wins.

This ensures fairness and predictability. There are no hidden queues, no off-chain favoritism — just transparent slot-level ordering.

3. Pre-Confirmation

Once a slot is reserved, Raiku issues a pre-confirmation, a signed guarantee that:

- The transaction has a reserved execution window,

- Its position within that slot is locked (unless the user’s conditions invalidate it),

- It won’t be displaced, delayed, or dropped, even under heavy network congestion.

This guarantee arrives before the Solana consensus begins, giving applications a reliable signal that their transaction will land exactly as intended.

4. Timed Delivery and Finality

As the reserved slot begins, Raiku delivers the transaction directly to the correct block leader, bypassing Solana’s public QUIC transport — a common bottleneck where transactions are often dropped or throttled.

Because ordering was pre-determined, the leader executes the transaction with the promised priority. After that, the standard Solana consensus process takes over:

- The block is proposed,

- Validators vote,

- Finality is reached.

Raiku doesn’t replace consensus; it guarantees delivery, timing, and ordering before consensus even starts.

Examples in Practice

- Urgent rescue (JIT): “Include my liquidation save in the next slot with max bid b.” You know it will fire instantly.

- Exact deadline (AOT): “Include my repayment just before 14:03 UTC with max bid b.” You know it won’t miss the cutoff.

- Cheap but safe: “Include my staking claim sometime after 02:00 UTC with a low bid; don’t drop it.” You can pick a quiet window cheaply.

- High-value trade with guards: “Try JIT now with bid b, but only execute if price ≥ X; if not included in 2 slots, cancel.” You avoid ghost txs or overpaying in dead markets.

But guaranteeing timing alone isn’t enough. The system also has to decide how much room each slot gives to AOT reservations versus JIT walk-ins. One of Raiku’s key differentiators and a critical piece of why this matters is its dynamic slot allocation, which keeps both paths viable without starving one for the other.

Raiku’s dynamic slot allocation

Ordering determines who goes first within a slot. Allocation determines how much of a slot (or series of slots) is available to AOT vs. JIT in the first place.

Most systems have hard-split capacity, which causes starvation. Think hotel inventory: reservations are AOT, walk-ins are JIT. If you pre-book every room, walk-ins get turned away. If you save everything for walk-ins, planners can’t reserve.

Raiku does something smarter: it dynamically balances AOT and JIT moment by moment based on real demand.

- When AOT demand rises (lots of scheduled jobs), AOT gets more share, but never 100%, so urgent JIT “walk-ins” still have rooms.

- When JIT demand spikes (market moves, liquidations), the system temporarily shifts headroom to JIT while preserving existing AOT reservations.

- Inside any slot, the same priority rule still applies (highest bid first; ties by arrival for JIT, booking time for AOT).

Net effect: no starvation, higher overall utilization, and cleaner price signals to help you choose JIT vs. AOT. In other words, you don’t have to live in a world of only reservations or only walk-ins; the system keeps both viable as demand shifts.

Conclusion

On Solana, timing uncertainty destroys value and cannot be reliably solved by “pay more,” because many losses occur before scheduling (drops), and inside the scheduling process, fee order is not strictly enforced.

Raiku makes time-to-inclusion contractible: JIT/AOT sells timing as a resource; ordering is bid-first with transparent tie-breaks; dynamic allocation prevents reservation/walk-in starvation.Therefore, for any transaction with positive time value, buying the timing you need (JIT for immediacy, AOT for deadlines) strictly dominates spamming and guessing. The system converges from stochastic inclusion to a priced, predictable timing market, reducing waste and aligning fees with the true value of time.

‍