How it works

System Architecture

Orderbook.trade uses a Hybrid Architecture designed to solve the "DEX Trilemma" Providing CEX-level performance without sacrificing the non-custodial security of a DEX.

The Problem with Pure Chains

  • On-Chain AMMs: Too slow (block times) and expensive (gas on every action).

  • App Chains: Still limited by consensus overhead for every single order cancellation or modification.

Our Solution:

1. The Execution Layer (Off-Chain)

This is a high-performance Golang-Based Matching Engine hosted on our sequencer nodes.

  • Role: Maintains the Orderbook state, matches buy/sell orders, manages risk checks (margin), and sequences transactions.

  • Performance: Capable of processing 100,000+ orders per second with <5ms latency.

  • Safety: It cannot forge user signatures. It can only match valid orders signed by the user.

2. The Settlement Layer (On-Chain)

This is a set of Smart Contracts deployed on the target blockchain (Arbitrum, Solana, Monad, etc.).

  • Role: Holds user funds (Custody) and verifies the result of the off-chain matching.

  • Process: The engine submits a compressed "Batch" of trades. The contract verifies the math and updates user balances atomically.

3. The Security Model (Self-Custody)

Your funds are never held by the Orderbook.trade company server. They are strictly held in the Smart Contract.

  • Deposit: You call deposit() on the contract.

  • Trade: You sign an intent I want to swap A for B.

  • Withdraw: You can call withdraw() on the contract at any time.

What if the Orderbook goes down ?

We implement an "Escape Hatch" mechanism. If the sequencer goes offline or censors your withdrawal request, you can force a withdrawal directly from the Smart Contract after a timelock, guaranteeing you always have access to your funds.

Last updated