Core System Architecture

The architecture follows a hybrid model - combining off-chain computation for performance and on-chain settlement for security and transparency.

Application Layer

This layer serves as the interface between the user and the encrypted execution domain

Trade requests originate from client applications (web, mobile, or Telegram bot) and are immediately encapsulated within a secure communication tunnel.

Session keys are derived using elliptic-curve Diffie-Hellman handshakes, ensuring per-session entropy and preventing replay attacks.

Key functions:

• Trade request parsing & validation

• Client-side encryption via ephemeral session keys

• TLS + ED25519 signed order envelopes

Encryption & Gateway Layer

The Encryption Gateway is the first component of the backend responsible for the cryptographic normalization of incoming trade data.

It transforms raw user input into Private Orders, encrypting payloads with user-derived session keys and injecting nonces for anti-replay protection.

Every order is timestamped and sequenced via a decentralized relay network (peer-to-peer message propagation, verified through BLS signatures).

This ensures temporal consistency before the order enters the execution enclave.

Execution Layer

The Execution Layer is subdivided into two tightly coupled submodules:

(a) Dark Pool Relayer (TEE)

The Dark Pool Relayer operates within a Trusted Execution Environment (TEE), specifically AWS Nitro Enclaves, where encrypted orders are decrypted, matched, and re-encrypted for downstream settlement.

TEE boundaries provide hardware-enforced memory isolation, making it computationally infeasible for an external actor to access plaintext data.

Each enclave generates a remote attestation certificate, allowing other components (or validators) to cryptographically confirm that the computation occurred within a verified environment.

Inside the enclave:

• Orders are batch-matched every Δt milliseconds (configurable, default 500ms)

• Matching logic executes using deterministic priority queues (price-time fairness)

• Execution proofs are constructed using a custom SNARK circuit verifying order pairing correctness and conservation of balances

(b) Aggregation Router

Post-matching, the Aggregation Router optimizes routing of the resulting trades through integrated DEX sources (Jupiter, Hyperliquid, Aster, Lighter).

It computes the minimal slippage path using a multi-DEX graph search algorithm with real-time pricing input from on-chain oracles.

Each routing decision is accompanied by an execution hash, proving deterministic behavior of the pathfinding logic.

Settlement Layer

All verified batches are forwarded to the Settlement Contract deployed on Solana.

The contract performs final atomic swaps using Solana’s parallel runtime, guaranteeing that all state transitions are single-transaction atomic — either all trades execute, or none.

This module handles:

• eToken minting and burn events

• Settlement reconciliation

• Fee distribution logic

• PnL aggregation and position management

To ensure auditability, each settlement emits structured logs that can be verified off-chain via deterministic replay.

Data & Analytics Layer

All off-chain events, including execution proofs, TEE attestations, and ZK verification outcomes, are streamed into InfluxDB for time-series analytics.

This allows for real-time dashboards displaying performance metrics, latency histograms, and proof validity ratios.

Historical data can be reproduced by replaying order batches against archived enclave attestations.