Summary

Eureka Labs (Mar 2026) introduces a framework of four builder-layer primitives that expand what searchers and DeFi strategies can accomplish within a single block. These primitives operate within the existing MEV-Boost / builder architecture and do not require protocol changes, but they represent a significant expansion of block-time capabilities. The core claim: by moving expensive computation and external data resolution into the builder’s simulation environment, strategies can access tera-scale compute (10¹² gas-equivalent) vs. the ~60M gas available on-chain today.

The Four Primitives

1. Intra-Block Loans

What: Uncollateralized capital for the duration of a block, available across multiple transactions.

How: Builder lends assets at bundle start → strategy uses capital across multiple transactions in the same block → repayment enforced at sequencing time (if repayment fails, builder excludes the bundle).

Difference from flash loans: Flash loans are atomic within a single transaction. Intra-block loans are available across multiple transactions within the same block, enabling complex strategies that can’t fit in one call.

Example: $10M of ETH/USDC idle in a Uniswap v2 pool while a large swap will hit a v3 pool later in the same block. Borrow capital, insert it into the v3 pool immediately before the swap to capture fees, unwind and repay — all within one block.

2. Builder Execution Extension (BEX)

What: Heavy computation at block-time, minimal execution on-chain. Splits strategies into preCompute() (heavy, off-chain in builder simulation) and execute(output) (minimal, on-chain).

How: Builder runs preCompute() against exact mid-block state during block construction → returns compact ABI result → chain executes only execute(output).

Effective compute scale: ~10¹² gas-equivalent during builder construction vs. 60M gas on-chain today (and ~1B gas in the EF’s 2029 target). This is:

  • ~16,000× today’s on-chain compute
  • ~1,000× the EF’s 1-Giga-gas target

Example: End-of-block DEX rebalancing. Builder evaluates thousands of multi-hop permutations after earlier trades, finds the optimal rebalancing set, chain executes only the final trades. Losing alternatives never hit the chain.

Relationship to ePBS: Under ePBS, the builder commits to a payload hash before the block is finalized. BEX computations happen during construction, before the commit — so they’re compatible with ePBS timing.

3. Builder Execution Oracle (BEO)

What: Fresh off-chain data injected deterministically at block-time.

How: Builder queries live external sources during block construction — CEX prices, RFQ quotes, cross-chain state, secure randomness, off-chain risk models — and injects results into the execute() leg.

Problem solved: Quote staleness (the “stale context” problem). A transaction that fetches an external price may execute against a world that has already moved. BEO provides fresh context at the exact moment of settlement.

Examples:

  • Secure randomness injected into auctions and games at block time
  • CEX vs. DEX price comparisons resolved atomically
  • Risk model pricing feeding final execution parameters

Relationship to PropAMMs: BEO is a generalization of the oracle-first ordering requirement that PropAMMs need. Instead of requiring protocol-level ordering guarantees, BEO achieves oracle freshness through builder-level injection.

4. Deterministic Block Placement

What: Bundle declared dependencies → builder places bundle only after those dependencies have been satisfied during block construction.

How: Bundle declares watchedAddresses or state transitions it depends on. Builder places the bundle only after those touches have occurred — not earlier.

Problem solved: Ordering uncertainty. Today, strategies rely on mempool racing or overpayment to land in the right position. Deterministic placement removes the race.

Example: Run an arbitrage only after a specific pool reserve update and an oracle change in the same block. Builder guarantees the bundle runs in that exact state context, or not at all.

Relationship to FOCIL: FOCIL ensures transactions are included. Deterministic placement ensures they’re included in the right relative order. These are orthogonal properties.

Architecture: Builder as Execution Environment

The four primitives together turn the block from a passive container (list of transactions) into an active execution environment where:

  • Capital is mobile across the block (intra-block loans)
  • Computation is unbounded off-chain but settled cheaply on-chain (BEX)
  • External state is fresh at execution time (BEO)
  • Ordering is deterministic relative to declared dependencies (placement)

Critical Assessment

Centralization concern: These primitives require a specialized builder to implement. They deepen the dependency on builder infrastructure and may favor builders who invest in the required compute/oracle infrastructure.

Confidence disclosure: Eureka Labs is a startup (self-published blog post, Mar 2026). The primitives are described conceptually; production implementation details, security audits, and live deployment are not yet documented.

Relationship to SUAVE: These are builder-side implementations of some SUAVE vision elements — expressiveness beyond simple transaction ordering. SUAVE envisions a universal decentralized environment for these computations; BEX/BEO are centralized-builder-specific implementations of the same concept.

Key Sources

  • Introducing Eureka Labs: A New Execution Environment for Ethereum (Eureka Labs, Mar 15, 2026) — Intra-block loans; BEX; BEO; deterministic placement