CQ1 Overview

Why CQ1

Traditional DEX aggregators face three bottlenecks:

1. Stale data: Polling RPC nodes introduces 200-500ms latency
2. Parsing overhead: JSON serialization on every request
3. Sequential routing: Limited path evaluation capacity

CQ1 eliminates all three through architectural redesign rather than incremental optimization.

Architecture

CQ1 operates on three decoupled layers:

graph TB
    subgraph API["API Layer"]
        Gateway["Express Gateway"]
        Controller["Quote Controller"]
    end

    subgraph Core["Core Router"]
        Engine["Parallel Path Engine"]
        Math["Math Core"]
        Adapters["DEX Adapters"]
    end

    subgraph Ingestion["Data Ingestion"]
        gRPC["gRPC Listener"]
        Scheduler["Weight Scheduler"]
    end

    subgraph Storage["State Layer"]
        Redis[("Redis Buffers")]
        Mongo[("MongoDB Topology")]
    end

    Gateway --> Controller
    Controller --> Engine
    Engine --> Math
    Math --> Adapters
    Adapters --> Redis

    gRPC --> Redis
    Scheduler --> Redis
    Scheduler --> Mongo

    style Engine fill:#0d9488,color:#fff
    style Redis fill:#f59e0b,color:#fff
    style gRPC fill:#8b5cf6,color:#fff

Key principle: Read path and write path are completely decoupled. Quote generation never blocks on state updates.

Core Components

Performance

How It Works

1. User requests quote (source, destination, amount)
   1. Routing engine evaluates millions of paths in parallel
      1. Waterfill algorithm optimizes splits across pools
         1. Math core calculates exact output using binary state
            1. Quote returned with route plan and expected output

CARBIUM

Blog Post

The CQ1 Engine Architecture | Carbium Blog

Deliver sub-millisecond quotes on Solana with binary state management and real-time data ingestion.

Read article