Architecture

Fermi DEX has a hybrid architecture - continuum sequencing, offchain orderbooks, and onchain verification and settlement

Fermi DEX Architecture

Fermi DEX is built as a three-layer system that combines centralized-exchange speed with on-chain trust & verifiability guarantees. Each layer is autonomous yet tightly linked through cryptographic proofs, so the whole pipeline stays verifiable even when parts of the stack run off-chain.

1 · Continuum Sequencing Layer — “Who goes first?”

  • Every incoming transaction is immediately hashed and committed to Continuum’s verifiable delay function (VDF) pipeline.

  • The sequencer emits a rolling Merkle root and a Wesolowski proof that fixes the exact time-order of the commitments.

  • Anyone—client, relayer, or smart contract—can verify that the sequence number you received is immutable and censorship-free.

Why it matters: final order is decided before fees are visible, so bidding wars and gas auctions cannot reorder trades.

How to access: connect to the public WebSocket endpoint or run a lightweight follower node that mirrors proofs in real time.

2 · Off-Chain Orderbook & Matching Engine — “Where trades meet”

  • A Rust-native matching engine keeps the full limit-order book in memory and updates it in sub-millisecond cycles.

  • When two orders cross, the match is written to an event queue—a compact log that will later settle on Solana unchanged.

Why it matters: matching off-chain removes the per-trade cost and block-time latency that limit on-chain order books, without giving up determinism.

3 · On-Chain Verification & Settlement — “Make it final”

  • Cranker bots read the event queue, attach the relevant Continuum proof, and submit a SettleEvents transaction to the Solana program.

  • The program re-checks the Merkle branch, confirms the sequence numbers are contiguous, and executes the state changes (balance debits/credits, fee rebates).

  • Because settlement is atomic, partial updates are impossible; either the entire batch lands, or it reverts and can be resubmitted.

Why it matters: settlement lives inside Solana’s consensus, so once finalised, trades inherit the same liveness and irreversibility as any SPL transfer.

Gas model: takers pay the on-chain fee inside the batch; makers usually net a rebate, mirroring the CEX economic model.

The settlement process is split into two phases for greater efficiency and flexibility:

Phase 1: Verification and Trade Registration (update_trades)

  1. Accepts a batch of matched trades from a whitelisted sequencer

  2. Verifies signatures of all participants

  3. Validates execution prices are within acceptable ranges

  4. Confirms trade quantities don't exceed order amounts

  5. Confirms no replay by validating user nounce.

  6. Adds verified trades to the PendingTradesAccount

  7. Emits events signaling trade validation and registration

This phase can only be executed by a whitelisted sequencer

Phase 2: Trade Execution (execute_trade or execute_trades_batch)

  1. Loads specified trades from the PendingTradesAccount

  2. Transfers tokens between counterparties - call FermiVault if needed

  3. Marks trades as executed in the PendingTradesAccount

  4. Updates statistics (pending trade count, etc.)

  5. Emits events signaling successful execution

This phase can be executed by any user

Key Benefits

  • Separation of Concerns: Verification is handled separately from execution

  • Gas Efficiency: No need to re-verify signatures or constraints during execution

  • Batch Processing: Multiple trades can be verified and executed in batches

  • High Performance: Zero-copy implementation with direct memory access for large arrays

  • Storage Efficiency: Single account stores up to 1000 trades without serialization overhead

  • Memory Safety: Carefully designed unsafe blocks with proper access patterns and bounds checking

  • Cost Reduction: Users don't pay rent for individual trade accounts

  • Scalability: System can handle higher trade volumes with lower overhead

4 · Observability & Risk Controls

  • Prometheus endpoints track latency at each hop (client → sequencer, sequencer → match, match → settlement).

  • SDK hooks expose cancel-on-disconnect timers, kill-switches tied to price bands, and maximum notional exposure limits—executed locally before an order ever leaves the trader’s machine.

6 · Putting It All Together

 Trader → Relayer → Continuum → Matching Engine → Event Queue → Cranker → Solana Program
          (proof)         (FIFO match)          (batch)        (verify+settle)

  1. The trader signs an order and time-stamps it through Continuum.

  2. The matching engine respects that order when updating the off-chain book.

  3. Matched events, bundled with their proofs, are settled on Solana in a single CPI call.

  4. Balances update, fees clear, and a new Merkle root anchors the next round.

The result is an exchange that feels as instantaneous as a centralized venue yet produces on-chain evidence for every step of the lifecycle. You can run latency-arbitrage or market-making strategies without worrying that higher gas or miner proximity will front-run you, and you can audit the entire flow long after the fact. Welcome to fast, fair, and final trading.

PreviousFeaturesNextProgramable Liquidity

Last updated