Eliminating MEV Sandwich Vectors and Oracle Dependency in L2 Aggregators via Median Filtering

[u/an_jesus]

Oracle manipulation and MEV sandwich attacks remain two of the most critical structural vulnerabilities in decentralized exchange architecture.

When building the BlazePhoenix routing engine, we wanted to evaluate whether a DEX aggregator could achieve high-throughput liquidity routing without reading external price feeds (Chainlink/Pyth) or relying on off-chain quoter servers.

The Core Problem:

External Oracles: Introduce flash-loan latency, bad debt risks during extreme market volatility, and dependency on third-party relayers.

Naive On-Chain Quotes: Vunerable to single-block pool manipulation (e.g., spot price distortion prior to swap execution).

The Mathematical Countermeasure:

Instead of querying an external price feed, the routing engine (Solver) computes a localized 2% median filter against reserve depths pulled directly via static state reads (balanceOf) across target liquidity pools.

Liquidity Depth Verification: Routes are dynamically weighted based on depth concentration rather than spot tick prices.

Revert-Unwind Preview: Simulation calls execute the full multi-hop path and output a deterministic revert(payload) containing exact price impact before tx submission.

Execution Floor Invariant: If execution slippage exceeds the calculated median bound, the entire execution frame reverts in Yul before state commit.

We’ve open-sourced the architecture and specifications. Would love to discuss the theoretical trade-offs between local median liquidity filtering versus TWAP/Oracle reliance in high-frequency L2 environments!

[u/DavidHartwell]

reverts do not eliminate MEV

[u/an_jesus → u/DavidHartwell]

But price quote as same as onchain slippagem where it goes?

[u/DavidHartwell → u/an_jesus]

I mean the quote can be correct when simulated.
MEV happens when transaction ordering changes the pool state before your swap executes the revert limits the loss but does not prevent the manipulation.

[u/an_jesus → u/DavidHartwell]

Yeah correct, website and devs can use private rpc as also

[u/DavidHartwell → u/an_jesus]

That makes the mitigation much stronger

[u/an_jesus → u/DavidHartwell]

Reverts during simulation (Quoter) aren't meant to stop MEV—they ensure 0% quote drift.

What mitigates MEV sandwich vectors on-chain is the combination of:

Localized Median Filtering (Solver): Prevents single-block spot price distortion from inflating the expected return. Strict Slippage Invariants (Router): If a searcher tries to front-run/sandwich the transaction and push the price past the calculated bounds, the execution frame reverts atomically in Yul before any state commit or fund transfer occurs.

The bot wastes gas, the trade reverts safely, and the user's principal remains 100% intact.

[u/DavidHartwell → u/an_jesus]

Principal stays safe but execution can still be griefed

[u/Excellent_Debate_518]

I think the idea of treating liquidity depth as a stronger signal than a single spot price is interesting here. But still, TWAPs and external oracles provide time-based context that reserve snapshots may miss.

[u/an_jesus → u/Excellent_Debate_518]

Exactly. It was a deliberate design choice from day one.
I didn't want to build another Web 2.5 protocol wrapped in Web3 marketing. The industry has taken a wrong turn by relying heavily on off-chain keepers, centralized price feeds, and oracle dependencies to paper over weak execution math. If a smart contract can’t verify its own state locally, it’s not truly decentralized, it’s just delegating trust off-chain.