TL;DR

Execution uncertainty on Solana is two problems, not one. Some transactions miss a race. Others miss a promise.

They look identical from the outside and they need completely different fixes.Raiku's AOT and JIT mechanisms address each failure mode directly, and they share one property that makes them worth holding as standing positions rather than one-off bets.

Understanding why that property matters is what the article is actually about.The one constraint neither mechanism can engineer around: validator adoption. The article explains exactly what that dependency means in practice, and where the guarantee's ceiling sits today.

‍

One Distinction, Two Failure Modes

The first part of this article established that a blockchain guarantees settlement, not execution: once a transaction lands, its finality is absolute, but whether it lands in the intended block, at the intended moment, is never assured. That gap is where the cost identified in Part 1 originates. 

However, execution uncertainty is not a single problem, it is two distinct problems that happen to produce the same unsuitable outcome. The distinction turns on what triggers the transaction.

• Reactive transaction: does not exist until a condition is met, and once triggered, must land in the next available window or the obligation it was meant to satisfy is already lost. A liquidation becomes actionable only when a position crosses its maintenance margin, a cancel-and-replace order becomes urgent only when the oracle price moves against a resting quote.
  
  
• Scheduled transaction: defined by a known point in time rather than an unpredictable trigger. A fund redemption at a fixed window, a periodic oracle update, or a tokenized-asset transfer with a compliance deadline all fall into this category. The failure mode here is not a missed race — it is a known commitment that the network still failed to honor. This corresponds to Part 1's slow money: capital that transacts infrequently, but for which the transaction that matters cannot be treated as probabilistic, since a missed settlement window constitutes a breach of obligation rather than ordinary slippage.

These are not two versions of the same problem with one fix. A system built to win a race against a sudden trigger is solving a different problem than a system built to keep a promise for a fixed future moment.

This distinction is the basis for the argument that follows: Raiku's Ahead-of-Time (AOT) and Just-in-Time (JIT) mechanisms are not alternative products addressing the same need. They are the two mechanisms required to address these two distinct failure modes: one designed to hold a commitment against a fixed point in time, the other to guarantee an outcome against an unpredictable event. 

The rest of this article covers three things: the architecture behind both mechanisms, how AOT and JIT actually work, and where each guarantee's limits are today.

What a Reservation Is Actually Made Of

Before examining how AOT and JIT each solve their respective problems, it is necessary to talk about what makes a reservation enforceable. A guarantee is only as credible as the mechanism enforcing it, and Raiku's mechanism consists of two components operating at different points in the transaction lifecycle.

• Ackermann Node: functions as the planning layer. It receives transaction intents, runs the AOT and JIT auctions against available blockspace, assigns each transaction to a specific slot, and issues a pre-confirmation before the transaction reaches Solana's consensus process. It also monitors validator and sidecar health on an ongoing basis, ensuring that a committed transaction is routed to a validator actually capable of honoring the assignment at the scheduled moment.
  
  
• Ackermann Sidecar: functions as the enforcement layer, running alongside the validator's existing client rather than replacing it. Once the Node has assigned a transaction to a slot, the Sidecar holds that transaction locally and injects it directly into the validator's block-production pipeline at the precise scheduled moment, bypassing the standard transaction transport layer that ordinary traffic competes through.

The architectural significance of this design is that it does not require a modification to Solana's base protocol or consensus mechanism. It operates off-chain, but in tight synchronization with the validator set. Validator participation is opt-in: they can plug alongside either the Agave or Firedancer client.

The core distinction is that a reservation is not a request submitted into the same queue as ordinary traffic with a higher priority attached, it is a transaction that never enters that queue at all. It is planned, assigned, and confirmed before consensus begins, then delivered directly into block production at the moment the plan specifies.

Neither AOT's scheduled guarantee nor JIT's reactive guarantee is possible without this separation between planning and public execution already in place. 

AOT: Solving the Scheduled-Transaction Problem

Ahead-of-Time (AOT) reservations address the failure mode where a transaction is defined by a known future point in time. An AOT reservation is a pre-purchased guarantee of inclusion at a specified future slot, booked with a minimum lead time of around 15 seconds. Once confirmed by the Ackermann Node, the transaction is held by the Sidecar and injected into block production at the assigned moment, independent of surrounding network congestion.

This mechanism is useful where the timing is known in advance: a scheduled redemption, a periodic oracle update, a funding settlement, etc. In each case, the relevant question is not whether the transaction can win a race for inclusion, but whether a commitment made in advance will still hold when the moment arrives.

A necessary feature of this guarantee is what may be termed zero-cost abort.

If conditions change before the block is produced (say the transaction is no longer valid) the reservation cancels at no cost, instead of executing wrongly or charging a fee anyway.

This flips the open queue's problem, where every submission costs the same whether it lands or fails. With AOT, a transaction either fires on schedule or cancels for free, there's no version where you pay but the commitment isn't kept, or is kept wrong.

JIT: Solving the Reactive-Transaction Problem

Just-in-Time (JIT) reservations address the reactive failure mode: a transaction that only exists once a condition is met, and that has to land in the very next window once it's triggered. 

Unlike AOT, a JIT reservation isn't booked for a calendar slot. It's bound to a trigger condition and pre-confirmed by the Ackermann Node ahead of consensus — so when the condition hits, the transaction goes straight into the next block instead of competing for it.

This fits operations built around an unpredictable moment, not a known one: a liquidation that has to fire the instant a position crosses its margin limit, a cancel-and-replace that has to land before a stale quote gets hit, or an arbitrage trade that has to execute before the window closes. In each case there's no lead time to plan around — the trigger and the deadline are the same moment.

The difference from a priority fee is pretty obvious:

• A priority fee is charged the moment you submit it, no matter what happens next, it just improves your odds in an auction you can still lose to a full block, a locked account, or an expired blockhash. 
• A JIT reservation only gets used when the condition it was written for is actually true at the moment of execution.

If the trigger condition changes before the block is produced, a position recovers above its margin limit. If a quote isn't stale anymore by the time the cancel would fire, the reservation cancels for free, instead of firing on outdated conditions or charging a fee for nothing. 

That's what makes this work for the people relying on it: a keeper or market maker holding a reservation isn't penalized when things resolve on their own before execution.

Why TradFi Split Its Order Flow

Part 1 described a reservation fee as a form of insurance: a known, fixed cost you pay to avoid an unbounded one. That's accurate, but it's not the whole picture. Traditional markets got rid of price execution risk structurally by splitting retail order flow and institutional order flow into separate channels.

3 examples illustrate this separation:

• Colocation gives latency-sensitive trading firms a dedicated physical channel to an exchange's matching engine.
• Block trade desks allow large institutional orders to be negotiated and executed away from the public order book.
• Prime brokerage provides financing and settlement on contractual terms agreed in advance, rather than through the same clearing process retail participants rely on.

In each case, retail flow keeps competing in a public channel, while institutional flow buys into a separate channel.

Solana's base layer doesn't offer that split today. 

A scheduled redemption, a liquidation, and a random retail swap all compete for the same blockspace under the same rules, no matter what's actually at stake for each one. The network makes no distinction between a transaction that can tolerate a coin-flip outcome and one that can't.

AOT and JIT reservations are the onchain version of that same channel split: they're a separate channel users can use to reserve the slots. The real difference from TradFi is structural: prime brokerage agreements are private contracts, while a Raiku reservation is open to anyone willing to pay for it. The underlying idea (that real stakes need their own channel, separate from ordinary order flow) is the same one institutional markets landed on decades ago.

Case Study: Perp DEX Liquidations as a Reactive-Transaction Failure

A liquidation becomes necessary the moment a trader's position falls below its maintenance margin. This mechanism is based on an oracle price rather than the exchange's own price. On Solana's perp DEXs, this depends on independent keeper bots (liquidators) that watch oracle feeds, spot positions that have crossed the threshold. Once that happens, other keepers submit the liquidating transaction in exchange for a cut of the collateral. Whoever lands first gets paid: the protocol's solvency depends on that transaction landing before things get worse.

If the position can't be closed at a price that covers the trader's losses, bad debt occurs that the protocol has to eat. Velocity DEX (previously called Drift) covers this with an insurance fund funded by trading fees and auctioning off bad-debt positions. That fund exists precisely because liquidation isn't guaranteed to land on time today, it's the protocol admitting upfront that the transaction can fail. If losses ever outrun the fund, the protocol falls back to socialized loss, where other users absorb the gap.

The failure mode has a clear cause. Congestion breaks the liquidation pipeline two ways.

• First, ordinary competition for blockspace: liquidation transactions queue alongside everything else, and under the congestion a real share of transactions fail to land during volatility spikes.
• Second, something more serious: during past Solana outages (2021 token-launch IDO congestion and the 2022 NFT-minting surge) keeper bots couldn't submit transactions at all. Underwater positions sat unclosed until the network recovered, and by then, liquidation would fire against a price that no longer matched the market.

In both cases, the one transaction that mattered most was the one least likely to land in time.

A JIT reservation takes the keeper out of the race entirely. The liquidation is bound in advance to its trigger and pre-confirmed for the next block once that happens, no matter what else is competing for it. 

If the position recovers before the block lands, the reservation cancels for free instead of firing a liquidation nobody needs, or charging the keeper for nothing. The keeper never gets punished for holding a reservation that resolves itself.

The stakes are simple. Every missed liquidation becomes a liability the insurance fund or other users have to cover. A mechanism that guarantees the liquidation fires exactly when needed and costs nothing when it isn't.

Case Study: Prop AMM Quote Defense as a Reactive-Transaction Failure

Proprietary AMMs don't price liquidity off a static curve. They quote actively, using the maker's own capital, and constantly reprice against a fair-value estimate anchored to an oracle. The core risk here is adverse selection: a quote that hasn't caught up to the market yet can get traded against by someone faster or better informed, at the maker's expense. Because this risk comes with the territory, prop AMMs have built their whole cost structure around minimizing it. 

Repricing transactions are engineered to use as little compute as possible: as low as ~143 compute units at one leading venue, over a thousand times cheaper than a normal swap. That way the maker can afford to refresh its quote many times a second and still win the priority race.

This matters because it shows the industry already knows this problem and has built its own workaround. On Solana, transaction ordering favors a higher fee-per-compute-unit ratio, so a nearly-free repricing transaction can attach a small tip and still land ahead of a taker's trade without needing a big fee. 

Leading prop AMMs update their oracle 10-17 times a second, and the venues with the cheapest compute and fastest updates are the ones that hold the tightest spreads. This is a race run entirely inside the public queue, optimized down to a few compute units and tiny tips, but still a race, decided fresh every block, still exposed to the same congestion as everything else.

That exposure is the problem. Compute efficiency makes the race cheaper to enter, it doesn't remove the race. During congestion a maker's reprice competes for the same blockspace as hundreds of unrelated transactions. It can be cheap to send and still miss the block if that block just fills up first. The current defense lowers the cost of winning, but it doesn't guarantee a win.

A JIT reservation changes what's actually being bought. Instead of optimizing a reprice to win a fresh auction every block, the maker binds it to the trigger itself and gets a pre-confirmed guarantee that it lands in the next slot, no matter what else is competing for that block. It becomes scheduled against a defined event.

Zero-cost abort is what makes this live. Quote adjustments happen constantly, and plenty of them respond to moves that reverse before they matter, a maker can't afford to pay for every possible reprice trigger regardless of whether it's needed.

If the price moves back before the block lands, the reservation cancels for free instead of firing a reprice. That lets the maker hold a standing guarantee against adverse selection while only paying for the moves that actually required a response.

Prop AMMs already quote spreads in the low single digits of basis points on pairs like SOL-USDC, good enough to rival CEXes, thanks to how well compute-efficient repricing already works. The gap is congestion: the queue fills up at the exact moments when defending a quote matters most. Pulling the reprice out of that queue entirely is the difference between a spread that holds under stress and one that widens right when liquidity is worth the most.

The Problem Of Validator Adoption

Every guarantee in this article rests on one thing we haven't looked at directly: a reservation is only as strong as the odds that the validator assigned to that slot is actually running the Sidecar and will honor it. This section looks at that dependency head-on, since it's the real limit on everything AOT and JIT promise.

The Enforcement Mechanism

Raiku's guarantee runs on 2 layers of quality of service:

• Slot-Inclusion Quality of Service (siQoS) is how a validator commits to including a scheduled transaction in its assigned slot. The Sidecar enforces that commitment directly.
• Stake-Weighted Quality of Service (swQoS) ties the strength of that commitment to how much stake the validator holds. The logic: a validator with more at stake has more to lose, so it carries a bigger obligation to deliver.

This limits how much small or unreliable operators can weaken the guarantee for everyone else. Commitments are backed by an optimistic failure mode paired with slashing. A validator that takes a reservation and breaks it pays an economic penalty. The guarantee only means something if this enforcement is real and consistent. And that depends on how much stake is actually running under it.

What Adoption Looks Like Today

Raiku's client is live on mainnet, currently running on our own validator with partner testing rolling out shortly. Early validator partners include Kiln, Figment, Everstake, Chorus One, and Blockdaemon.

• The economic incentive offered to validators is a new, non-MEV revenue stream layered on top of standard block rewards and priority fees. It is a compensation for selling predictable blockspace rather than simply building blocks passively. 
• Raiku's liquid staking product $rkuSOL passes a share of AOT and JIT revenue through to stakers. It is an additional adoption lever: it gives capital a reason to delegate specifically toward validators running the Sidecar, which is the same basic mechanism Solana's own ecosystem has used elsewhere to bootstrap client adoption.

Competitors of Raiku pursue a different architecture (trusted execution environments rather than a sidecar model), where they allocate a portion of liquid-staked SOL specifically to validators running its software to accelerate adoption. 

Whether Raiku pursues a comparable formal mechanism or relies on the liquid-staking product alone, the underlying dynamic is the same: adoption of new validator infrastructure on Solana has historically been accelerated deliberately, through stake incentives, rather than left to occur organically.

Why the Precedent For Rapid Concentration Exists

It is worth noting that Solana validator infrastructure has, in the past, concentrated quickly once given a reason to. The Jito-Agave client came to represent more than 70% of Solana's total stake: a level of concentration around a single piece of add-on infrastructure that has no equivalent on Ethereum, where no client exceeds roughly two-thirds of the network. 

This is not evidence that Raiku's Sidecar will reach comparable adoption, but it does establish that stake-weighted concentration around new validator software is achievable on Solana specifically (given sufficient economic incentive within a realistic timeframe).

Adoption is a continuous variable that determines how much confidence a given reservation actually carries. Under partial adoption, a transaction scheduled against a specific, known-participating validator carries a materially different guarantee than one scheduled against an arbitrary future slot leader drawn from the full validator set. 

• For AOT, where the reservation is booked roughly 15 seconds ahead, the relevant question is the probability that the leader assigned to that future slot is running the Sidecar (a probability that rises directly with the share of stake that has adopted it).
  
  
• For JIT, where the reservation must resolve within the next available slot after a trigger fires, the same dependency applies on a compressed timescale: if the next leader is not participating, the guarantee cannot be honored regardless of how well the triggering condition was specified.

What "meaningful" adoption requires  is a stake-weighted share of the validator set large enough that the probability of a reservation landing on a non-participating leader becomes negligible across the specific timeframes AOT and JIT operate on.

Synthesis: Two Mechanisms, One Axis

AOT and JIT aren't two versions of the same idea, they're the two mechanisms this split requires. AOT reserves a slot against a clock, JIT reserves an outcome against a trigger. Neither substitutes for the other: an AOT reservation can't handle a liquidation, and JIT can't hold open a redemption window that hasn't arrived yet.

Both share the feature that makes them actually usable, not just theoretical: zero-cost abort. A scheduled commitment either fires as planned or cancels free if its conditions no longer hold. A reactive one either resolves against a trigger still true at execution, or cancels free if the trigger already resolved itself. Either way, this flips the open queue's problem, where every attempt costs the same whether it lands or not. Being wrong about needing a reservation costs nothing — which is what makes it worth holding as a standing position.

Traditional markets didn't fix execution uncertainty by making one shared venue faster for everyone. They split retail flow from institutional flow into separate channels. AOT and JIT are that same split, built as open protocol infrastructure instead of private deals.

A perp DEX liquidation and a prop AMM's cancel-and-replace are both reactive transactions, and both are currently defended the same way: racing the open queue, whether with priority fees or cheap compute. JIT fixes both with the same mechanism and the same zero-cost abort, even though a keeper and a market maker operate in unrelated markets.

Both mechanisms work because of the same abort property, follow the same channel-separation logic markets used decades ago, and depend on the same open question of validator adoption.

‍