Deterministic Block Building: Ending MEV Chaos at the Protocol Level

1. Executive Summary

The blockchain industry stands at a critical juncture, transitioning from an era of “optimistic submission”—where transaction ordering is a probabilistic and exploitable event—to a new paradigm of Deterministic Block Building. For the past decade, the dominant model for block production has relied on the “dictatorship of the builder,” a system where the entity constructing the block possesses unilateral, unchecked authority to reorder, censor, or insert transactions. This architectural choice, while simplifying consensus, has birthed the multi-billion-dollar phenomenon of Maximal Extractable Value (MEV).

The current “MEV chaos” manifests as a predatory tax on users, characterized by sandwich attacks, front-running, and back-running, alongside systemic network instability caused by spam-driven “latency wars.” As decentralized finance (DeFi) attempts to scale to institutional-grade volumes, the unpredictability of the “dark forest” mempool has become a binding constraint. Institutional actors cannot operate in an environment where trade execution is contingent on a bidding war (Priority Gas Auction) with anonymous bots.

This report provides an exhaustive analysis of the emerging solutions aiming to encode transaction ordering directly into the protocol or infrastructure layer. We contrast the two dominant philosophical approaches emerging in 2024-2025: Randomized Determinism (spearheaded by Ethereum’s EIP-7956) and Temporal Determinism (pioneered by Solana’s Raiku and Jito architectures).

Ethereum’s approach seeks to neutralize the builder’s advantage through cryptographic shuffling. By XOR-ing transaction hashes with a beacon chain randomness output, EIP-7956 transforms the “sure bet” of a sandwich attack into a “costly lottery,” statistically eliminating the profitability of reordering attacks while preserving the censorship resistance of the network.1 Conversely, Solana’s ecosystem is moving toward “Ahead-of-Time” (AOT) scheduling. Protocols like Raiku act as “air traffic controllers,” allowing users to reserve specific slots in future blocks. This shifts the market from a chaotic auction at the moment of execution to a predictable futures market for blockspace, enabling “Application-Controlled Execution” (ACE) where developers can enforce custom sequencing logic.2

The analysis further explores the theoretical underpinnings of “Fair Ordering” protocols like Themis and Aequitas, which attempt to mathematically enforce “First-Come-First-Serve” based on network-wide consensus, though often at the cost of significant latency overhead. We conclude that while determinism does not eliminate all forms of value extraction (e.g., arbitrage remains), it successfully converts “toxic” MEV into benign competition, upgrading the blockchain from a speculative casino into a reliable substrate for the global economy.

2. The Anatomy of MEV Chaos: The Status Quo

To understand the necessity of deterministic block building, one must first dissect the failure modes of the current “probabilistic” paradigm. In most permissionless blockchains, the process of converting a user intent (a transaction) into a finalized state change is mediated by a series of actors who operate with significant discretion. This discretion is the root of the chaos.

2.1 The Dictatorship of the Block Builder

In systems like Ethereum and Solana, the entity responsible for constructing the block (the “leader,” “proposer,” or “builder”) acts as a temporary dictator for the duration of their slot. In the absence of protocol-level ordering rules, they possess the absolute right to:

1. Select which transactions to include from the mempool.
2. Order those transactions within the block arbitrarily.
3. Insert their own transactions at any point in the sequence.

This unchecked power creates the conditions for MEV. In a typical scenario, a user submits a transaction to swap a token on a Decentralized Exchange (DEX). This transaction sits in the mempool, visible to all. A “searcher” (an automated bot) simulates the transaction, realizes it will move the price, and constructs a “bundle” of transactions to exploit it.

The builder, who is often distinct from the validator in modern Proposer-Builder Separation (PBS) architectures, effectively auctions off the right to order the block. The searcher who pays the highest “tip” (coinbase transfer) gets their bundle included. The user, unaware of this auction, suffers from manipulated execution prices.

2.2 The Taxonomy of Extraction

The value extracted from this discretion is not monolithic. It falls into distinct categories, each affecting the network differently.

MEV Type	Mechanism	Impact on User	Impact on Network
Sandwich Attack	Attacker buys before user, sells after user.	High slippage; worse execution price.	Toxic; discourages usage.
Front-running	Attacker sees a profitable txn (e.g., liquidation) and copies it with a higher fee.	Missed opportunity (e.g., failed liquidation).	Gas wars; congestion.
Back-running	Attacker executes arbitrage after a large price movement.	Neutral (price impact has already occurred).	Benign/Positive (aligns prices).
Censorship	Builder excludes specific transactions (e.g., OFAC compliance or malicious denial).	Denial of service.	Existential threat to neutrality.

As noted in the analysis of cross-domain MEV, intrinsic-extractable value (the profit available from the state itself) is compounded by time-extractable value (the optionality of when to execute).4 The lack of deterministic rules allows builders to maximize both.

2.3 The Optimistic Fallacy and “Jitter”

Current blockchain interactions are fundamentally optimistic. A user broadcasts a transaction and hopes for inclusion. There is no protocol-level guarantee that a transaction submitted at time $T$ will be executed before a transaction submitted at time $T+1$.

This is particularly acute in high-throughput chains like Solana. Before the advent of deterministic scheduling, the network suffered from “jitter” and spam. Because fees were low and ordering was non-deterministic (often based on chaotic network propagation or simple UDP packet arrival), bots would flood the leader with thousands of duplicate transactions to statistically increase their chance of landing a trade. This “spray and pray” tactic degrades network performance for everyone, leading to the “transaction failure” narratives that have plagued high-performance L1s.5

For institutional actors—banks, payment processors, and traditional trading firms—this lack of determinism is a non-starter. A stock exchange does not permit the matching engine operator to reorder trades for personal profit, nor does it tolerate a 5% transaction failure rate due to spam. The “MEV chaos” renders blockchains unreliable for complex financial products that require strict sequencing, such as cross-margin liquidations or atomic settlements.

3. Theoretical Frameworks of Deterministic Ordering

Deterministic block building shifts the power of ordering from the subjective will of the builder to objective rules enforced by the protocol. Before examining specific implementations like Raiku or EIP-7956, it is essential to understand the theoretical approaches to this problem.

3.1 Defining Determinism in Consensus

In the context of distributed ledgers, deterministic execution usually refers to the property that state transitions are reproducible: given state $S$ and block $B$, every node computes the same resultant state $S’$. However, deterministic ordering goes a step further. It requires that the content and sequence of block $B$ be derived from the set of available transactions according to a fixed public algorithm.

The definition of “determinism” varies based on the goal:

• Fair Ordering: Order reflects the “real-world” arrival time.
• Randomized Ordering: Order is unpredictable but unmanipulable by the builder.
• Market-Based Ordering: Order is determined by an explicit auction or reservation system.

3.2 Fair Ordering Protocols: Aequitas, Themis, and Wendy

The most intuitive form of deterministic ordering is First-Come-First-Serve (FCFS). If the network sees Transaction A before Transaction B, A must execute first. However, in a distributed system, “time” is relative. Node X may see A before B, while Node Y sees B before A due to network topology.

Academic protocols like Themis, Aequitas, and Wendy attempt to solve this by defining “fairness” based on the relative ordering observed by a supermajority of nodes.7

3.2.1 The Condorcet Problem

These protocols often model transaction ordering as a voting problem. If 70% of nodes report seeing A before B, the protocol enforces A < B. However, this can lead to Condorcet Cycles:

• Nodes might vote A < B.
• Nodes might vote B < C.
• Nodes might vote C < A.
  This creates a paradox where there is no linear order. Protocols like Aequitas use “block-lace” structures or graph condensation algorithms to resolve these cycles, ensuring a final output that respects the “receive-order fairness” of the honest majority.8

3.2.2 The Scalability Trade-off

The primary critique of Fair Ordering protocols is performance. To achieve this consensus, nodes must exchange not just blocks, but metadata about when they saw every transaction.

• Message Complexity: Many of these protocols have a message complexity of $O(n^2)$ or higher, where $n$ is the number of nodes.
• Latency: They require an additional “ordering phase” before execution. For a chain like Solana (400ms blocks) or Ethereum (12s slots), the overhead of a widespread fairness vote is currently prohibitive for Layer 1 implementation, though it shows promise for Layer 2 sequencers.10

3.3 Randomized (Shuffled) Ordering

An alternative to establishing “truth” about arrival time is to simply break the builder’s control. If the builder cannot choose the order, they cannot extract MEV.

• Mechanism: Transactions included in a block are sorted based on a pseudo-random value derived from the transaction hash and a protocol-level random seed (e.g., a Beacon Chain random beacon).
• Impact: A builder cannot guarantee that their front-running transaction will land immediately before the victim, nor can they ensure their back-run lands immediately after. This turns the “sure bet” of a sandwich attack into a “costly lottery”.1

3.4 Encrypted Mempools (Threshold Cryptography)

While strictly a visibility solution rather than an ordering solution, encrypted mempools (like Shutter Network or Ferveo) contribute to determinism by blinding the builder.

• Commit-Reveal: Users submit encrypted transactions. The builder orders these encrypted blobs.
• Decryption: Only after the order is committed and finalized does the distributed key generation (DKG) committee release the decryption key.
• Result: The builder orders transactions without knowing their content. They cannot front-run a trade they cannot see. However, they can still perform “metadata analysis” (e.g., assuming a large transaction from a known whale wallet is a buy) or censor based on IP address.12

4. The Ethereum Paradigm: Randomized Determinism (EIP-7956)

Ethereum’s roadmap has increasingly focused on neutralizing the centralization risks posed by MEV. EIP-7956, titled “Tx Ordering via Block-level Randomness,” represents the leading proposal for embedding deterministic ordering directly into the L1 consensus rules.

4.1 The Mechanism: XOR-Based Shuffling

Currently, Ethereum proposers (or the builders they outsource to via MEV-Boost) can order transactions arbitrarily. EIP-7956 proposes a consensus rule to enforce a canonical sorting mechanism. The core logic is as follows:

1. Candidate Selection: The builder selects a set of transactions $S$ to include in the block. This selection is still driven by economic fees (base fee + priority tip).
2. Randomness Source ($R$): The protocol derives a fresh random value $R$ from the Beacon Chain (specifically, the randao_reveal of the slot). Crucially, this value is unknown to the builder until the slot actually begins.1
3. Sorting Key Generation: For every transaction $Tx \in S$, the protocol computes a sorting key $K$:
   
   $$K_{Tx} = Hash(Tx) \oplus R$$
   
   (Where $\oplus$ denotes the XOR operation).
4. Canonical Ordering: The block is valid if and only if the transactions are arranged in ascending order of their keys $K$.

4.2 Economic Impact: Killing the Sandwich

The primary target of EIP-7956 is the sandwich attack. A successful sandwich requires precise adjacency:

• Position $i$: Attacker Front-run
• Position $i+1$: Victim Transaction
• Position $i+2$: Attacker Back-run

Under EIP-7956, the builder loses control over these positions. The position of any transaction is determined by $Hash(Tx) \oplus R$. Since $R$ is random and uniform, the resulting order is effectively a random shuffle.

• The “Costly Lottery”: For an attacker to successfully sandwich a victim, they would need their transactions to essentially “get lucky” and land in the correct order.
• Inventory Risk: The risk is asymmetric. If the attacker submits the transactions and the random shuffle results in the order Front-run -> Back-run -> Victim, the attacker buys the token and immediately sells it before the victim moves the price. The attacker pays double gas fees and loses the spread/slippage, receiving zero MEV profit. This “poison pill” makes sandwiching expected-value negative (EV-).14

4.3 The Bundle Problem and “Fit-or-Skip”

Strict randomization breaks atomic composability. A user might want to submit a chain of dependent transactions:

1. Approve USDC for swapping.
2. Swap USDC for ETH.
   If these are shuffled randomly, the Swap might occur before the Approve, causing the transaction to revert and the user to lose gas.

To address this, EIP-7956 introduces the concept of Bundles:

• Definition: A bundle is a user-signed list of transactions that must be kept together and executed in sequence.
• Sorting Logic: The bundle is treated as a single “virtual transaction” for the purpose of the XOR sorting. The sorting key is derived from the hash of the entire bundle.
• Fit-or-Skip: A critical consensus rule is “Fit-or-Skip.” If a bundle is selected for inclusion based on its sorting key, but its execution would exceed the block gas limit, the entire bundle is skipped. This prevents “partial execution” attacks where a builder might try to include only the “buy” leg of a strategy but not the “sell” leg.1

4.4 The “Tiers” Debate

Critics of strict randomization argue that it ignores the nuanced needs of financial applications. For example, Oracle updates (e.g., Chainlink posting the price of ETH) are critical infrastructure. If an Oracle update is randomly shuffled to the end of the block, after all the liquidations have failed, the protocol accrues bad debt.

To mitigate this, researchers have proposed Execution Tiers as an augmentation to EIP-7956:

• Mechanism: Users can tag transactions with a “Tier” (e.g., Tier 0, Tier 1).
• Logic: The block is sorted primarily by Tier (Tier 0 first), and then by the random XOR key within each Tier.
• Implication: This reintroduces a fee market. Users (or Oracles) can pay a premium to be in Tier 0, guaranteeing they execute before Tier 1 trades. This preserves the anti-sandwich properties (randomness within the tier) while allowing for critical dependency management.15

5. The Solana Paradigm: Temporal Determinism (Raiku & Jito)

While Ethereum focuses on randomness to combat centralization, Solana focuses on performance and predictability. The high throughput of Solana (400ms blocks) makes “jitter” a massive problem. If a market maker cannot be sure when their trade will land, they must quote wider spreads to account for the risk.

5.1 The Failure of FCFS in Solana

Solana’s default behavior is often described as First-Come-First-Serve (FCFS) based on arrival at the leader. However, in practice, this leads to spam wars.

• The Attack: To ensure a transaction lands in block $N$ rather than $N+1$, bots spam the leader with thousands of copies of the same transaction via UDP.
• Result: This floods the network bandwidth, causing ingress congestion. Legitimate user transactions are dropped because the leader’s network buffer is full of spam. This phenomenon is often misidentified as “Solana is down,” when in reality, it is suffering from a lack of deterministic admission control.5

5.2 Raiku: The “Air Traffic Control” Layer

Raiku has emerged as a middleware solution to this problem. It introduces Ahead-of-Time (AOT) block building.

• Validator Sidecars: Raiku operates as a “sidecar” software that runs alongside standard Solana validators. It does not replace the consensus but augments the block-building process.
• Slot Reservations: Raiku effectively creates a futures market for blockspace. Users (or “blockspace brokers”) can reserve specific indices in future blocks.

• Example: A user can buy “Index 0 to 10 in Slot 25,000,000.”

• Ackermann Nodes: These are the coordination nodes in the Raiku network that manage the state of reservations. They ensure that a slot is not double-sold and issue cryptographic receipts to the buyers.2

5.3 Warrantied Inclusion and Receipts

The key innovation of Raiku is the Receipt.

• Concept: A receipt is a cryptographic promise signed by the Raiku network (and backed by validator stake) that a specific transaction hash will be included in a specific position.
• Elimination of Jitter: For a high-frequency trading firm, this is revolutionary. They no longer need to spam. They simply buy the slot, submit the transaction once, and hold the receipt. If the validator (running Raiku) fails to include it, the receipt serves as fraud proof, and the validator can be penalized (slashed) or banned from the Raiku network.6
• Robin Nordnes (CEO) Insight: In interviews, Nordnes describes Raiku as “air traffic control.” It doesn’t fly the planes (validators do that), but it ensures they have a reserved runway. He emphasizes that for “normal users,” transaction failure is a probabilistic annoyance, but for institutions, it is a disqualifying risk. Raiku turns probabilistic “hope” into deterministic “warranty”.6

5.4 Jito’s Block Assembly Marketplace (BAM)

Raiku is not alone. Jito, the dominant liquid staking and MEV provider on Solana, has launched the Block Assembly Marketplace (BAM).

• Mechanism: BAM moves the auction for blockspace off-chain and ahead of time. It allows “BAM Validators” to sell rights to build portions of the block.
• Comparison: While Jito’s current “Bundles” focus on atomic inclusion (similar to Flashbots), BAM is evolving toward the same AOT model as Raiku, recognizing that the “just-in-time” auction creates too much latency overhead. BAM utilizes “Plugins” to allow developers to create custom transaction sequencing logic, enabling Application-Controlled Execution (ACE).17

5.5 “First-Come-First-Serve” vs. “Auction” in Raiku

Within the reserved slots, what is the ordering rule?

• The Marketplace: Raiku utilizes a marketplace (likely an auction) to sell the slots. The highest bidder gets the best slots (earliest in the block).
• Within a Batch: If a single entity reserves a batch of slots, they determine the order. This effectively delegates the ordering right from the validator to the reservation holder.
• Implication: This doesn’t eliminate MEV; it privatizes it. If a DEX reserves the top 100 slots of every block, they can enforce “Fair Ordering” (FCFS) for their users, or they can run their own internal auction. The key is that the rule is known and enforced by the receipt, not hidden in the validator’s private code.3

6. Application-Controlled Execution (ACE) & Asynchronous Market Queues (AMQ)

The evolution of deterministic infrastructure enables a new design pattern: Application-Controlled Execution (ACE). Instead of the blockchain enforcing a global rule (like “all blocks must be random”), the blockchain provides the primitives (reserved slots), and the application defines the logic.

6.1 Asynchronous Market Queues (AMQs)

In traditional finance, exchanges use matching engines with specific rules (e.g., Price-Time Priority). On blockchains, AMQs attempt to replicate this.

• Mechanism: A Solana program (smart contract) can implement an AMQ. Users submit “Asynchronous Instructions” (like limit orders) that are added to an on-chain priority queue.
• Execution: A “crank” (automation bot) processes this queue.
• The Role of Raiku: Without deterministic block building, the “crank” transaction might fail or be delayed, causing the queue to stall. With Raiku, the application can reserve the “crank slot” at the end of every block, guaranteeing that the market clears every 400ms without fail.3

6.2 The “On-Chain NASDAQ” Vision

This stack—Solana L1 + Raiku/BAM + AMQ Logic—enables the “On-Chain NASDAQ.”

• Requirements:

1. High Throughput: (Solana L1).
2. Guaranteed Timing: (Raiku AOT Slots).
3. Complex Matching Logic: (AMQ Smart Contracts).

• Compliance: This structure is critical for regulatory compliance. A regulated exchange must be able to prove why a trade was executed at a specific price. If the ordering is deterministic and recorded on-chain via an AMQ processed in a reserved slot, the audit trail is perfect. It eliminates the “black box” of the validator’s mempool.17

7. Economic Implications: From Gas Wars to Latency Wars

The shift to determinism fundamentally alters the game theory of the network. If participants cannot bribe the builder to reorder transactions, how do they compete?

7.1 The Return of Latency Wars

In a system that enforces “First-Come-First-Serve” (either strictly or via Fair Ordering protocols), the competition shifts to latency.

• The Race: To be “first,” a trader must send their transaction to the validator faster than anyone else.
• Infrastructure Arms Race: This incentivizes “co-location.” Traders will place their servers in the same data center as the leader. This mirrors the evolution of High-Frequency Trading (HFT) in equities (e.g., the spread networks between Chicago and NY).
• Centralization Risk: This is a negative externality. Physical co-location is expensive and creates a “geographic moat.” Large, capitalized firms can afford the fastest fiber lines; distributed retail users cannot. Thus, “Fair Ordering” might actually increase the centralization of the searcher market.4

7.2 The “Costly Lottery” of Randomization

Ethereum’s EIP-7956 avoids the latency war but introduces a Spam War.

• The Strategy: If ordering is random, a trader can increase their probability of being “first” by submitting $N$ copies of the transaction.
• The Defense: EIP-1559 and base fees. If every transaction costs $5 to submit, sending 1,000 copies costs $5,000.
• Equilibrium: This turns the “sure bet” of MEV into a statistical gamble. Searchers will only spam if the expected profit exceeds the guaranteed cost of the spam. This effectively filters out “low value” MEV (like small sandwiches) while potentially still allowing massive arbitrages (where the profit is millions) to be fought over via spam.14

7.3 Inventory Risk and the Death of “Risk-Free” MEV

The most profound economic change is the introduction of Inventory Risk.

• Status Quo: A sandwich attacker knows they will buy at $P$ and sell at $P+ \delta$. It is atomic and risk-free.
• Deterministic Future: Whether through randomness or FCFS, the attacker can no longer guarantee atomicity of the sequence. They might buy the token, but fail to sell it immediately. They are now holding volatile inventory.
• Result: This pushes MEV actors away from predatory extraction (which relies on risk-free mechanics) and toward statistical arbitrage, which is generally healthier for market efficiency.

8. Alternative Approaches and Comparative Analysis

While EIP-7956 and Raiku represent the mainstream approaches on the two largest chains, other innovations exist.

8.1 DAG-Based Randomness (Hathor)

The Hathor Network utilizes a Directed Acyclic Graph (DAG) structure combined with a variation of randomized ordering.

• Mechanism: It uses a modified Kahn’s algorithm for topological sorting, seeded by the block hash.
• Outcome: Similar to EIP-7956, it ensures that all nodes derive the same order from the DAG structure, preventing the miner from imposing an arbitrary sequence. This proves that randomized determinism is viable in non-linear blockchain architectures.20

8.2 Slippage Analysis: Adversarial vs. Collision

Research into DEX slippage categorizes user loss into Adversarial Slippage (MEV) and Collision Slippage (benign competition).

• Finding: On current systems, a significant portion of slippage is adversarial.
• Prediction: Deterministic systems will eliminate adversarial slippage but may increase collision slippage (as users race for the same price point without the ability to bribe for priority). However, private RPCs and “Flow” auctions (like Flashbots Protect) are already mitigating adversarial slippage effectively, suggesting that the protocol-level changes of EIP-7956 might be the “final nail” in the coffin for toxic MEV.21

9. Challenges and Criticisms

The transition to determinism is not without its critics.

9.1 The “Spam” Vector in Randomization

As noted, randomized ordering theoretically encourages spam. While fees mitigate this, in times of extreme volatility (e.g., a stablecoin de-peg), the value of being first might exceed any reasonable gas fee, potentially leading to chain bloating.

9.2 The “Centralization” Vector in AOT Scheduling

Raiku and BAM rely on complex “sidecar” software.

• Risk: If 90% of Solana validators run the Raiku client, Raiku effectively becomes the consensus protocol. If Raiku has a bug or a centralized failure in its “Ackermann Nodes,” the entire Solana network’s liveness could be impacted.
• Mitigation: Raiku aims to decentralize the Ackermann nodes, but bootstrapping a decentralized middleware network is arguably as hard as bootstrapping the L1 itself.

9.3 The “Institutional” vs. “Degen” Divide

Institutional requirements (determinism, KYC hooks, receipts) are often at odds with the permissionless, chaotic ethos of “degen” DeFi. ACE and AMQs allow these two worlds to coexist: a permissioned, deterministic “Pro” pool can exist alongside a chaotic, FCFS “Degen” pool on the same L1, separated by the application logic.3

10. Conclusion

The chaotic era of probabilistic block building—where transaction ordering was a “dark art” practiced by bribes and bots—is drawing to a close. The industry is converging on Deterministic Block Building as the inescapable solution to the MEV crisis.

This transition is taking two distinct paths, reflecting the differing philosophies of their respective ecosystems:

1. The Solana Path (Temporal Determinism): Utilizing time-based reservations and AOT scheduling (Raiku, BAM) to create high-certainty, industrial-grade pipelines. This transforms blockspace into a tradable commodity with strict SLAs, enabling the “On-Chain NASDAQ.”
2. The Ethereum Path (Randomized Determinism): Utilizing cryptographic randomness (EIP-7956) to dissolve the power of the builder. This focuses on neutrality and censorship resistance, converting MEV from a predatory tax into a statistical game.

Both paths achieve the same fundamental goal: they strip the block builder of their unilateral power to play god with transaction order. By embedding the rules of ordering into the protocol—whether through the roll of a cryptographic die or the purchase of a cryptographic reservation—blockchains are evolving from experimental substrates into reliable, fair, and scalable financial infrastructure. The “Dark Forest” is being paved.

Key Takeaways

• MEV is an Ordering Problem: It exists solely because builders have unconstrained discretion. Protocol-level determinism removes this discretion.
• Raiku/Solana = Certainty: By selling “Receipts” for future slots, Raiku allows institutions to hedge execution risk, eliminating the “spray and pray” spam dynamics of the current network.
• EIP-7956/Ethereum = Neutrality: By XOR-shuffling transactions, Ethereum aims to make sandwich attacks mathematically unviable (“EV-“), preserving the user experience without requiring a centralized sequencer.
• The Rise of ACE: Application-Controlled Execution represents the future where ordering logic moves up the stack to the smart contract, enabled by the deterministic guarantees of the layer below.

Analysis conducted by Senior Cryptoeconomic Researcher.

Sources utilized:.1

Works cited

1. 7956: Tx Ordering via Block-level Randomness – EIPs Insights, accessed on December 21, 2025, https://eipsinsight.com/eips/eip-7956
2. Raiku | Fast, Predictable Solana Transactions, accessed on December 21, 2025, https://www.raiku.com/
3. Colosseum Codex: Cypherpunk Hackathon, Project RFPs, Prediction Markets, accessed on December 21, 2025, https://blog.colosseum.com/cypherpunk-hackathon-project-rfps-prediction-markets/
4. Cross-Domain MEV – arXiv, accessed on December 21, 2025, https://arxiv.org/pdf/2308.04159
5. Raiku: Equipping Solana with a “Deterministic Engine” to Prevent Transaction Failures | Bitget News, accessed on December 21, 2025, https://www.bitget.com/news/detail/12560605052725
6. Solana Traders Hit 90% Failure Rates at Congestion — Raiku’s Fix Explained – CCN.com, accessed on December 21, 2025, https://www.ccn.com/education/crypto/solana-traders-90-percent-transaction-failures-robin-nordnes-raiku-solution/
7. Maximal Extractable Value (MEV) in DeFi – Emergent Mind, accessed on December 21, 2025, https://www.emergentmind.com/topics/maximal-extractable-value-mev
8. Quick Order Fairness: Implementation and Evaluation – arXiv, accessed on December 21, 2025, https://arxiv.org/html/2312.13107v1
9. SoK: Consensus for Fair Message Ordering – arXiv, accessed on December 21, 2025, https://arxiv.org/html/2411.09981v3
10. Data-Dependent Order-Fairness – Rashnu – VLDB Endowment, accessed on December 21, 2025, https://www.vldb.org/pvldb/vol17/p2335-amiri.pdf
11. AOAB: Optimal and Fair Ordering of Financial Transactions – DSN 2024, accessed on December 21, 2025, https://dsn2024uq.github.io/Proceedings/pdfs/DSN2024-6rvE3SSpzFYmysif75Dkid/410500a377/410500a377.pdf
12. Fair Transaction Ordering – GitHub Pages, accessed on December 21, 2025, https://lucaspfingsten.github.io/my_website/
13. EIP-7956: Tx Ordering via Block-Level Randomness – Ethereum Magicians, accessed on December 21, 2025, https://ethereum-magicians.org/t/eip-7956-tx-ordering-via-block-level-randomness/24084
14. EIP-7956: Tx Ordering via Block-Level Randomness – #4 by aryaethn – Ethereum Magicians, accessed on December 21, 2025, https://ethereum-magicians.org/t/eip-7956-tx-ordering-via-block-level-randomness/24084/4
15. EIP-7956: Tx Ordering via Block-Level Randomness – Ethereum Magicians, accessed on December 21, 2025, https://ethereum-magicians.org/t/eip-7956-tx-ordering-via-block-level-randomness/24084/6
16. Inevitable Ideathon track by Raiku | Superteam Earn Listing, accessed on December 21, 2025, https://earn.superteam.fun/listing/raiku
17. Solana’s vision to become the Onchain NASDAQ is strengthened as it acquires essential blockchain infrastructure | Bitget News, accessed on December 21, 2025, https://www.bitget.com/news/detail/12560604989711
18. Why Offchain Compute Matters on Solana – Raiku – Ghost, accessed on December 21, 2025, https://raiku.ghost.io/why-offchain-compute-matters-on-solana/
19. Maximum Extractable Value (MEV) Mitigation Approaches in Ethereum and Layer-2 Chains: A Comprehensive Survey – Espace ÉTS, accessed on December 21, 2025, https://espace2.etsmtl.ca/id/eprint/30326/1/Zhang-K-2024-30326.pdf
20. Hathor Network, the only MEV-proof blockchain | by Trond Bjorøy, accessed on December 21, 2025, https://blog.hathor.network/hathor-the-only-mev-proof-blockchain-712172f8ac0a
21. Don’t Let MEV Slip: The Costs of Swapping on the Uniswap ProtocolThis work was made possible by mempool data made available to the authors by Blocknative (https://www.blocknative.com) and BloXroute (https://bloxroute.com). We are tremendously grateful for their generosity. – arXiv, accessed on December 21, 2025, https://arxiv.org/html/2309.13648v2
22. Latest Insights and News from the World of … – Blockdaemon Blog, accessed on December 21, 2025, https://www.blockdaemon.com/blog?926e469d_page=3
23. What is Deterministic Execution? Blockchain determinism explained – Cube Exchange, accessed on December 21, 2025, https://www.cube.exchange/what-is/deterministic-execution
24. Solana MEV Report: Trends, Insights, and Challenges – Helius, accessed on December 21, 2025, https://www.helius.dev/blog/solana-mev-report
25. Solfate Podcast – Interviews with blockchain founders/builders on Solana – Transistor, accessed on December 21, 2025, https://feeds.transistor.fm/solfate