The Engineering Contract Part II: How the Rewrite Works
How Ahead-of-Time (AOT) and Just-in-Time (JIT) Execution Reservations Work on Solana
The first article in this series named the execution gap on Solana: what the base protocol promises, where those promises fall short of institutional requirements, and why the gap has a measurable cost. This article covers the mechanism designed to close it. Ahead-of-Time and Just-in-Time reservations are different tools built for different problems. Understanding how each works is the foundation for evaluating what they can and cannot currently guarantee.
Why can't priority fees guarantee a Solana transaction will land?
Priority fees improve the odds. They do not change the structure of the competition. A transaction with a higher fee is more likely to be included in the next block, but it is still competing in an open auction against every other transaction on the network at the same moment. In congested conditions, the outcome of that auction is not certain in advance.
In traditional finance, settlement commitments are backed by contractual obligation, collateral, and legal recourse. A clearing house's failure rate is the product of decades of process engineering. The guarantee is not incidental to the infrastructure. It is what the infrastructure was built to produce.
That is the structural difference. A priority fee is a bid in a competition. An execution reservation removes the competition. The transaction is assigned a slot before other traffic arrives. The block is booked, not won.
What are the two types of execution certainty that institutional Solana operations require?
The execution problem on Solana is not a single problem, it’s two, and they require different mechanisms.
The first is scheduled certainty: the ability to guarantee that a specific transaction lands at a specific future time. A fund rebalancing at quarter-end, a coupon payment on its due date, a settlement instruction with a compliance deadline. These are not races, but are appointments. The relevant question is not whether the transaction can outcompete other traffic for the next available block. It is whether it can bypass that competition entirely and be assigned a slot before the competition begins.
The second is reactive certainty: the ability to guarantee that a transaction lands immediately when a condition is met. A liquidation that must fire the instant a position crosses its threshold. A multi-leg trade that must land as a single unit or not at all. A market maker's cancel that must reach the block before a stale quote is hit. These transactions do not have a scheduled time. They have a trigger. The requirement is not about advance timing but about priority at the moment the trigger fires.
Ahead-of-Time reservations address the first. Just-in-Time reservations address the second. The two mechanisms are not interchangeable, and the architecture distinguishes them because the problems are genuinely distinct.
How does Ahead-of-Time execution reservation work on Solana?
An Ahead-of-Time reservation is a pre-purchase of a specific future block, secured through a sealed-bid auction before the transaction executes. The mechanics work in sequence.
A client identifies a future slot it needs, at minimum approximately ten slots ahead, corresponding to roughly ten seconds of lead time under normal conditions. It submits a sealed bid through a competitive auction. The bid is expressed in the native unit of blockspace: compute units and a price per compute unit. The auction is sealed, meaning other bidders do not see the submitted price before the window closes.
If the bid wins, the client receives a signed confirmation before the trade happens. Payment is pre-authorised into an escrow account the client controls. The escrow releases when the reserved transaction lands in its assigned slot. If the slot is missed, the escrow is returned with a defined penalty applied. The failure has a price and an owner, and both are established before the transaction executes.
At the assigned slot, the validator running Raiku's client injects the reserved transaction into block production ahead of the general queue. The transaction does not compete with unrelated traffic for that slot. It was assigned the slot before unrelated traffic arrived.
Zero-cost abort is part of the design. If conditions change before the slot arrives, the reservation can be cancelled without penalty. The client pays for execution, not for attempts.
How does Just-in-Time (JIT) execution work on Solana, and what does it guarantee?
A Just-in-Time reservation binds a pre-built transaction to a trigger condition and gives it priority access to the next available block the moment that condition fires, ahead of general queue traffic.
The client defines the condition: a position crossing a liquidation threshold, a price moving beyond a defined range, a trigger event in another transaction. The transaction is pre-built and pre-signed against that condition. When the condition fires, the transaction enters a priority path ahead of general queue traffic rather than competing for the next available slot alongside everything else on the network.
This structure addresses the reactive execution problem directly. A liquidation bound to a JIT reservation does not wait in the same queue as unrelated activity at the moment the trigger fires. The mechanism is designed to give it the next available block when the condition is met, ahead of general traffic.
Multi-leg atomicity: A trade that must land as a single unit, where a simultaneous purchase and sale is only valid if both legs execute together, is treated atomically: both legs land in the same block or neither lands at all. This removes the risk of holding half a position because the second leg arrived one block late.
Priority cancellation: For a market maker defending a stale quote, the JIT mechanism provides a priority cancellation path. When a price moves and a quote becomes stale, the cancel or reprice enters the priority channel ahead of general queue traffic. The maker is no longer dependent on the network being uncongested at the exact moment the quote needs updating.
Which validators currently support guaranteed execution on Solana, and how does coverage work?
Every mechanism described in this article operates through validators running Raiku's client. The practical guarantee on any specific transaction depends on whether the validator assigned to the relevant slot is running the client.
The client is live on Solana mainnet. Raiku's own validator is active, with partner integration rolling out across Kiln, Figment, Everstake, Chorus One, and Blockdaemon.
Coverage grows as more validators adopt the client. The economic incentive for validators to do so strengthens as reservation volume increases: each reservation generates auction revenue that flows to the validator and, through rkuSOL, to stakers. An institution evaluating the product today is evaluating a guarantee that holds across a growing subset of validators. The coverage is publicly trackable and expanding in line with adoption. The direction of that expansion follows the same economic logic that drove rapid concentration of stake behind earlier Solana client upgrades once the incentive was clear.
What does guaranteed execution on Solana actually deliver that priority fees cannot?
Strip away the mechanics and the intended outcomes are specific.
A scheduled transaction assigned to a future slot, bypassing competition for blockspace rather than winning it. A reactive transaction given priority access to the next available block when its trigger fires. A multi-leg trade that lands whole or not at all. A cancellation in a priority channel before a stale quote can be hit. A reservation that can be cancelled at no cost if conditions shift before execution.
None of these outcomes is achievable through fee prioritisation alone. They come from structural changes to how blockspace is allocated, not from being faster or better-capitalised in an open queue.
The third article in this series examines what these changes mean in practice: which operations become possible onchain that are not possible today, and why that distinction is what the next wave of institutional capital is waiting on.
