Overview

Builder Execution Oracle extends Builder Execution Extension (BEX) by allowing contracts to access builder-side capabilities that are impractical or impossible to perform on-chain.

While BEX already enables expensive computation to run off-chain before execution, the Builder Execution Oracle focuses on specialized sources of information and computation, such as:

• external data sources

• complex optimization routines

• numerical solvers and derivative calculations

• external market signals

These capabilities allow strategies to incorporate information that exists outside the EVM or requires heavy computation, while still executing safely and atomically on-chain.

---

A simple example

Consider a strategy that wants to trade on a decentralized exchange only if the price differs from the price on Binance.

A contract alone cannot access Binance data. With Builder Execution Oracle:

1. During the compute phase, a built-in method retrieves the Binance price.

2. The compute function compares that price with the DEX price.

3. If a profitable opportunity exists, the compute step returns the trade parameters.

4. The execute step performs the swap on-chain while enforcing safety constraints.

The external data is used to determine the opportunity, but the final trade still executes deterministically on-chain.

---

How it works

The Builder Execution Oracle operates during the BEX compute phase.

When the builder simulates the compute call, it can resolve built-in methods that run inside the builder runtime. These methods may:

• fetch external resources (for example, a CEX orderbook or RFQ quote)

• run numerical optimization or mathematical solvers

• perform large search or simulation workloads

• aggregate external market information

The result of these operations is returned to the compute function as ABI-encoded bytes.

The builder then continues the standard BEX flow:

1. The compute function returns its final value.

2. The builder appends that value to the execute calldata prefix.

3. The resulting transaction is simulated.

4. If it succeeds and is profitable, it may be included in the block.

From the contract’s perspective, the oracle behaves like a normal function call during the compute phase. The heavy work happens inside the builder runtime, and only the minimal result required for execution is passed on-chain.

The execute step remains the source of truth. Contracts must verify constraints and ensure safety conditions are met before applying any oracle-derived result.

---

What the Builder Execution Oracle enables

The Builder Execution Oracle allows strategies to incorporate external information and sophisticated computation that cannot reasonably exist on-chain.

External market data

Many strategies depend on prices or liquidity from centralized exchanges or other off-chain venues.

During the compute phase, the builder can retrieve and normalize external market data and use it to determine execution parameters.

Example uses include:

• comparing CEX prices with DEX pools

• validating arbitrage opportunities

• anchoring trades to off-chain market signals

---

RFQ and off-chain liquidity

Some protocols rely on off-chain quoting systems or liquidity providers.

During compute, the builder may request quotes from external providers and evaluate them alongside on-chain liquidity.

This enables strategies that:

• request RFQ quotes

• compare them with DEX routes

• execute the best option on-chain

---

Numerical optimization

Certain strategies require solving mathematical problems that are inefficient to implement in Solidity.

Examples include:

• derivative-based optimization of AMM trades

• solving equations for optimal trade size

• numerical root finding or gradient-based optimization

These algorithms can run inside the builder runtime during compute, returning optimal parameters for on-chain execution.

---

Large search or simulation workloads

Some strategies require exploring large search spaces or running simulations that would be prohibitively expensive on-chain.

Examples include:

• evaluating many arbitrage routes

• optimizing trade allocation across venues

• computing portfolio rebalancing strategies

The builder performs the exploration during compute and returns only the final parameters required for execution.

---

Design philosophy

Builder Execution Oracle follows a simple principle:

Expensive or external computation happens in the builder. Minimal verification and execution happens on-chain.

This approach keeps on-chain logic compact and deterministic while allowing strategies to incorporate sophisticated off-chain reasoning.

---

Security and trust model

Builder Execution Oracle does not introduce new cryptographic guarantees.

Builder-side computation is not proven on-chain. Instead, correctness is enforced through the execute path:

• the contract verifies safety constraints

• execution succeeds only if those constraints are satisfied

• otherwise the transaction reverts

Because of this model:

• oracle results must be treated as untrusted inputs

• execute paths should enforce price bounds, slippage limits, or other invariants

• strategies should remain safe even if oracle outputs are incorrect or stale

External-resource built-ins may also be subject to builder policy and operational limits.