The Engineering Contract: Part One
What Institutional Finance Is Being Asked to Accept Onchain
Solana's performance properties have attracted institutional capital. What they haven’t provided is execution certainty and the ability to schedule a transaction into a specific block, with a commitment record and defined consequences if it does not land. This article examines that gap, what it means for the institutions now arriving, and what AOT and JIT execution do about it.
What the Trade Assumes and What the Chain Provides
Something bleeds out between the decision and the outcome. A few basis points per trade, compounding across a quarter, with no clean entry in the post-trade analysis. The strategy was right but the market didn’t move against it and the infrastructure just did not hold up its end.
Fund managers arriving on Solana bring calibrated models and set mandates. The network's speed, cost, and finality properties are attractive and real, and they are genuinely why $3.62 billion in real-world assets now sit on the chain. But those properties describe what Solana can do on average. For institutional finance, averages are not the same as commitments and that distinction is what the engineering contract is about.
What Is the Engineering Contract?
Every blockchain makes a set of implicit promises to every participant who builds on it. The promises are encoded in the technical and economic properties of the protocol: what the network guarantees to deliver, how reliably it delivers it, and what it will not commit to regardless of what the application layer does. They aren’t in a service level agreement or a prospectus. They are in the architecture.
When an institution routes capital onchain, it accepts those properties as the operating terms of the relationship. That is the engineering contract.
How TradFi's Engineering Contract Compares to Solana's
In traditional markets, the equivalent contracts are explicit. A prime broker commits to settlement terms in writing. DTCC clears at a settlement failure rate of approximately 0.1%. A colocation arrangement specifies, within microseconds, how a firm's instructions reach a matching engine. Forty years of institutional market infrastructure rest on one principle: when a commitment is made, the terms are knowable in advance and enforceable after the fact.
Solana's engineering contract has genuinely strong clauses: Sub-second finality, throughput and cost efficiency. These are the properties behind the $3.62 billion in real-world assets on Solana as of July 2026, and the institutions who arrived did so because the fundamentals held up.
The harder clauses to defend to a risk committee sit elsewhere.
Solana does not guarantee execution ordering beyond basic fee priority. It does not promise that a specific transaction will land in a specific block. It does not separate time-critical transactions from ordinary traffic. At the application layer, approximately one in four real user transactions fails, a success rate of around 76%, against DTCC's 0.1% settlement failure rate.
Solana was built as a general-purpose, high-throughput network where all participants compete for blockspace on equal terms. A tokenised gilt settlement, a keeper liquidating a perp position, and a retail swap operate under identical rules, with no distinction made between a transaction that can tolerate a probabilistic outcome and one that cannot.
For institutional operations, this creates structural constraints regardless of how experienced the operator or how well-designed the strategy:
- Execution at a specific known moment is not available. A mandate with a hard deadline, a scheduled redemption, a payment tied to a quarter-end settlement window: all require that a transaction lands at the moment, not within a window.
- Multi-leg trades cannot be guaranteed to land whole. A simultaneous purchase and sale that must execute as a single unit or not at all is a standard institutional operation. On Solana today, the legs compete for blockspace independently.
- Best execution cannot be evidenced per trade. A trade that cannot be documented with a commitment record and an outcome record per transaction cannot satisfy the oversight obligation many institutional operators carry.
- Non-custodial operation at institutional standards is difficult to achieve. The institutional standard is that capital never becomes a vendor's capital, and any permission granted is narrow, auditable, and revocable. Most onchain execution infrastructure requires granting access that exceeds this standard.
For institutional operations, none of these are edge cases. They are baseline requirements, and the current contract cannot meet them.
How AOT Is Addressing Part of It
Raiku's Ahead-of-Time (AOT) execution reservation is the first live mechanism to begin rewriting these clauses.
AOT replaces bid-and-hope with booking. A client pre-purchases a specific future slot on Solana, at least ten seconds in advance, through a sealed auction at a known price. They receive a signed confirmation before the trade executes. Payment is pre-authorised into escrow the client controls, released when the trade lands, with defined remedies when it does not.
Just-in-Time (JIT) execution handles the reactive end: firm immediate inclusion at approximately 40 milliseconds, with multi-leg trades that land whole or not at all.
Together, AOT and JIT introduce something the current contract cannot offer: a booking system. Guaranteed timing, atomic multi-leg execution, and a per-trade record of commitment and outcome generated by the execution process itself rather than reconstructed after the fact.
Execution at a known moment
Current Solana: Not available
With AOT/JIT: Available (AOT, 10s+ lead time)
Multi-leg atomicity
Current Solana: Not available
With AOT/JIT: Available (JIT)
Per-trade commitment record
Current Solana: Not available
With AOT/JIT: Generated by process
Non-custodial escrow
Current Solana: Not standard
With AOT/JIT: Client-controlled by design
Coverage and Adoption
Every guarantee described above depends on which validator is producing the relevant block. AOT and JIT reservations hold where the validator is running Raiku's execution client.
The client is live on Solana mainnet, currently on Raiku's own validator. Raiku has established validator partnerships with Kiln, Figment, Everstake, Chorus One, and Blockdaemon, and coverage extends as those integrations proceed.
For validators, adding Raiku's client is additive revenue: AOT and JIT transaction flow on top of existing block production, without changes to the core setup. The Jito client's trajectory is the nearest comparison. It reached over 70% of Solana's stake because the economics made participation straightforward to justify and the same logic applies here.
What the Rewritten Contract Makes Possible
The $3.62 billion already on Solana arrived because the core properties are compelling enough for the use cases that work within the current contract. That is a real result.
What it does not yet include is the next tranche: pension allocations, fund settlements, tokenised sovereign debt. Those flows move when the contract covers the use cases that do not currently work, and when an institution's risk committee can sign off on something more specific than a probability.
The question institutions are asking is whether the contract will be complete enough by the time their decision window opens.
This is the first article in Raiku's Engineering Contract series. The next article examines the specific roles within an asset management organisation that feel the current contract most acutely.
FAQ
What is the engineering contract on a blockchain? The engineering contract is the set of implicit technical and economic promises a blockchain makes to every participant who builds on it. Unlike a legal contract, it is not written down -- it is encoded in the protocol's properties: how transactions are ordered, how reliably they land, and what happens under congestion. When an institution routes capital onchain, it accepts these properties as its operating terms.
Why does Solana's 76% application-layer success rate matter for institutions? For retail swaps or short-term trading, a probabilistic success rate is manageable. For institutional operations - scheduled settlements, redemptions, coupon payments with hard deadlines - it is a structural barrier. DTCC's equivalent failure rate is approximately 0.1%. The gap is not a quality failure; it is a design difference that the current contract was not built to close.
What is AOT execution and how does it work? AOT (Ahead-of-Time) allows a client to pre-purchase a specific future block slot on Solana, at least ten seconds in advance, through a sealed auction at a known price. The client receives a signed confirmation before the trade executes. Payment sits in escrow controlled by the client, released only when the transaction lands. If the reserved slot is missed, defined remedies apply. AOT replaces probabilistic inclusion with a booking system.
Does Raiku's execution client work on Solana today? Yes. Raiku's client is live on Solana mainnet, running on Raiku's own validator, with partner rollout underway. The strength of any AOT or JIT reservation scales with validator adoption -- current coverage is publicly trackable. The Jito client reaching over 70% of Solana's stake demonstrates that rapid adoption is achievable once the economic incentive is real.
