The Ambient Finance team lay out their plans for implementing dual frequency batch auctions on their upcoming perps DEX.

This is a guest post from the team at Ambient, the premier perps DEX building on Fogo.

We're introducing Dual Flow Batch Auctions (DFBA) as the execution mechanism for Ambient on Fogo. DFBA blends the precision of a central limit order book (CLOB) with the fairness of automated market makers (AMMs). Instead of continuous matching, trades are batched and cleared at block end using oracle prices. This design reduces MEV, shifts competition from speed to price, and creates opportunities for price improvement. With Fogo's Solana Virtual Machine (SVM) architecture, we can run DFBA natively in smart contracts with low compute costs, no consensus-layer changes required.

The team at Jump Crypto recently published their thesis on DFBA, something we've been building at since inception.

Why DFBA?

On-chain trading today mostly relies on AMMs or continuous CLOBs. Each has tradeoffs:

• AMMs are simple and accessible but often inefficient for precise quoting.

• CLOBs enable tight spreads and deep liquidity but are vulnerable to latency arbitrage and MEV.

DFBA takes the best of both. By clearing trades in batches tied to an oracle, it removes speed advantages, makes trading fairer, and deepens liquidity. Instead of racing to be first, participants compete on price.

How It Works in Ambient

Here's the flow for DFBA on Ambient:

1. Order Submission
   Traders submit orders with a defined slippage tolerance (in basis points relative to the auction price). That tolerance sets the limit for acceptable execution.

2. Batch Accumulation
   Orders collect during the block. We separate them into "maker" (liquidity-providing) and "taker" (liquidity-consuming) flows. Unlike continuous matching, nothing clears until the block ends.

3. Auction Execution
   At block close, we run a batch auction using an oracle price (e.g. Pyth). One clearing price is set for each side (buy/sell). Since all orders clear at the same time, competition focuses on price, not speed.

4. Fill and Settlement
   Trades execute at the clearing price, with the possibility of price improvement. For example: if you placed a buy order and the market dropped during the block, competitive participants adjust quotes atomically, so you get a better price, without needing to race.

All of this is written as standard Solana programs on Fogo. The SVM's high throughput and cheap compute units let us run auctions every block without breaking efficiency.

Advantages

DFBA is designed to address long-standing pain points in on-chain trading:

• MEV Reduction
  Since the final auction price is tied to an unpredictable oracle and happens after a "quiet period," front-running is extremely difficult.

• Price Improvement and Fairness
  Clearing at a single price means market movements benefit traders, not low-latency snipers. Limit orders can actually fill at better prices when conditions shift during the batch.

• Oracle Risk Management
  If the oracle lags, we can extend the auction delay. If it fails outright, oracle-pegged liquidity deactivates, and makers fall back to quoting fixed prices. Markets stay live, just with less depth.

• Protection from Latency Arbitrage
  Continuous models still leave room for reordering attacks. DFBA's dual-flow design blocks this, ensuring tighter spreads without speed-based exploitation.

The result is a structure that's stronger than pure AMMs and more fair than continuous CLOBs.

Practical Considerations

A few common questions we've seen from the community:

• What if slippage is set too tight?
  Your order won't execute. That's by design---it protects you. The trade-off is balancing protection with fill probability.

• Who competes in the auction?
  External solvers and market makers can submit competitive bids, similar to CoW Swap's solver model, but integrated directly into the batch process.

• Who pays for price improvement?
  Improvements come from competitive quoting, not extraction. Makers/takers absorb the cost through tighter pricing, rather than value being siphoned off by MEV bots.

• What happens in volatile markets?
  The system prioritizes continuity. Even if oracles are stressed, we degrade gracefully, markets don't freeze, though liquidity may thin.

Conclusion

DFBA on Fogo is a new market structure for Ambient: batching orders, anchoring them to oracle prices, and forcing competition on price instead of speed. This design cuts down on MEV, creates fairer fills, and keeps trading resilient even under stress.

By building directly on Fogo's SVM, we can implement this entirely in smart contracts, something that wouldn't be practical on less performant chains.

We see DFBA as a foundation for a fairer on-chain trading environment, with plenty of room to refine oracle integrations, slippage dynamics, and solver participation over time.