What Is an Engineering Contract?
An Engineering Contract is a system that lets users reserve or prioritise space in an upcoming block, making blockchain transaction execution more predictable. It is a binding commitment between a blockchain infrastructure provider and its client, guaranteeing specific execution outcomes, including confirmation, timing, and delivery, backed by technical architecture rather than best-effort delivery. Where standard blockchain infrastructure asks you to compete for inclusion, an Engineering Contract lets you book it.
An Engineering Contract is a system that lets users reserve or prioritise space in an upcoming block, making blockchain transaction execution more predictable. It is a binding commitment between a blockchain infrastructure provider and its client, guaranteeing specific execution outcomes, including confirmation, timing, and delivery, backed by technical architecture rather than best-effort delivery. Where standard blockchain infrastructure asks you to compete for inclusion, an Engineering Contract lets you book it.
Where the Term Comes From
Most blockchain infrastructure operates on a simple assumption: submit a transaction, pay a fee, and hope conditions hold. There is no commitment. There is no accountability if the transaction fails. There is just a queue, and the outcome depends on who else is in it.
Robin Nordnes, Raiku’s Founder and CEO developed the Engineering Contract to describe something structurally different, a formal, infrastructure-level commitment to execution outcomes. The term was introduced by Raiku as part of its work building execution certainty infrastructure on Solana. It reflects the view that high-value onchain activity requires the same delivery guarantees that exist in traditional financial infrastructure, and that those guarantees must be architectural, not aspirational.
How Blockchain Transactions Normally Work
On most blockchains, transactions compete for space. Validators pick which ones to include, typically starting with whoever is paying the most. This works well enough when the network is quiet. When it gets busy, fees spike, and the outcome of any given transaction becomes hard to predict.
There is a second problem that gets less attention. On networks where pending transactions can be observed, anyone watching can act first. A well-known tactic called front-running involves another participant inserting their own transaction ahead of yours to profit from the information. It is one form of maximal extractable value (MEV) and can disadvantage protocols and traders operating in decentralised finance.
The result is a system where execution is uncertain, costs are unpredictable, and your transaction is visible to competitors before it lands.
What an Engineering Contract Changes
An Engineering Contract addresses three problems directly.
Execution uncertainty - Some applications depend on precise transaction timing like liquidations in lending protocols, arbitrage strategies, oracle updates, and other time-sensitive operations. Under standard processing, there is no way to guarantee when a transaction will execute, or whether it will execute at all. Reserved blockspace solves this.
MEV exposure - Because an Engineering Contract can commit a transaction to a reserved or prioritised execution path, it reduces the window in which front-running and certain sandwich attacks can occur. A transaction with a committed position in an upcoming block is harder to exploit than one sitting in an open queue.
Cost unpredictability - When blockspace is reserved in advance, execution price can be known before the transaction runs. For institutional participants and protocols handling large volumes, that predictability is important, it makes transaction costs something you can plan for rather than model as a distribution.
AOT and JIT: The Two Execution Models
Engineering Contracts use two approaches to securing blockspace ahead of standard queue processing.
Ahead-of-Time (AOT) execution reserves a specific slot in an upcoming block before it is produced. The transaction's position is committed in advance. By the time the block is being built, the decision to include the transaction has already been made.
Just-in-Time (JIT) execution purchases blockspace immediately before a block is sealed, skipping the open queue without requiring the same lead time as AOT.
Both replace the standard auction model with something that behaves more like a confirmed reservation. AOT goes further: it removes the execution decision from the market entirely, making the outcome a contractual commitment rather than a competitive one.
Raiku's infrastructure operates on the AOT model. That is what allows it to move from predictability to guarantee.
Engineering Contracts vs Priority Fees and MEV
vs Priority Fees
Priority fees are the most common tool for improving transaction reliability. Paying more increases the odds of inclusion, but it doesn’t guarantee it. You are competing against every other transaction submitted at the same time. If every participant raises their fee, the advantage disappears.
An Engineering Contract does not compete in the fee market. It exits it.
vs Auction Mechanisms
Auction mechanisms, including MEV auctions and priority ordering systems, allocate block space to the highest bidder at execution time. They are more sophisticated than simple priority fees but share the same structural limitation: the outcome depends on what others are willing to pay in that moment. If a competitor bids higher, you lose.
How Raiku Delivers Engineering Contracts
Raiku delivers Engineering Contracts through its AOT execution infrastructure on Solana. When a client enters an Engineering Contract with Raiku, the execution commitment is made before the transaction is submitted to the network.
Raiku's infrastructure coordinates with validators in advance, securing inclusion before the conditions that typically cause failure, congestion, leader rotation, fee market volatility, have the chance to interfere. By the time the transaction is due to land, the decision to include it has already been made.
Clients do not monitor for failure, retry on expiry, or model execution timing as a probability. They receive a confirmed outcome within the contracted window.
This is available to protocols and institutional participants with time-sensitive or high-value execution requirements. Speak to the Raiku team for specifics.
Frequently Asked Questions
How is this different from a service level agreement? An SLA typically covers uptime or response time targets, with remedies if missed. An Engineering Contract is a commitment to a specific execution outcome for a specific transaction. The distinction is between promising to try and committing to deliver.
Why does Raiku use the word "guaranteed" when CMC uses "more predictable"? Both are accurate at different levels. The Engineering Contract system makes execution more predictable than standard queue-based processing. Raiku's AOT infrastructure goes further — it makes execution contractually certain, because Raiku coordinates with validators before the execution window opens. Predictability is the category. Guarantee is what Raiku's implementation delivers within it.
Does it work during periods of high network congestion? Yes. The commitment is not contingent on network conditions holding. Raiku's ahead-of-time model makes the execution decision before congestion can become a factor, that is precisely the point.
Who is it for? Developers, trading firms, protocols, and institutional participants who need more predictable or guaranteed transaction execution. Most commercially relevant for high-value or time-critical activity where the cost of failure is material.
Related Concepts
- Guaranteed Transaction Execution — the execution outcome that an Engineering Contract delivers
- The Certainty Economy — the broader infrastructure category built around contractual guarantees
- Solana Infrastructure — the validator and execution layer context in which Engineering Contracts operate
- AOT vs JIT Execution — a deeper comparison of ahead-of-time and just-in-time execution models
