System Architecture
Architecture Overview
Zoryu Trade is built as a modular, execution-aware system where each layer has a clear responsibility and communicates through explicit data contracts. The architecture is designed to ensure that market data, AI signals, and execution states remain synchronized, minimizing ambiguity between analysis, decision-making, and on-chain settlement.
Rather than coupling all logic into a single monolithic layer, Zoryu separates concerns across frontend interaction, backend state management, intelligence processing, and blockchain execution. This separation allows the system to scale, evolve, and remain auditable without introducing opaque behavior.
At a high level, Zoryu operates as a state coordinator:
The frontend acts as the interaction and visualization layer
The backend maintains authoritative system state
The AI engine generates structured trade intelligence
The blockchain serves as the final execution and settlement layer
Core Components
Web Application (Frontend)
The frontend is built to provide real-time interaction while remaining stateless with respect to critical trading logic.
Responsibilities:
Display real-time market data and charts
Surface AI signals and tracked positions
Initiate trade execution requests
Reflect execution and position updates from the backend
The frontend does not determine trade outcomes or manage position state. It consumes authoritative data from the backend to ensure consistency and prevent divergence between UI and system logic.
API & Backend Services
The backend functions as the system’s state authority.
Responsibilities:
Aggregate and normalize market data
Store and manage signal and position state
Monitor live prices against TP and SL thresholds
Calculate PnL and performance metrics
Coordinate execution requests and responses
By centralizing state management, Zoryu ensures that signals, positions, and metrics remain consistent regardless of client refreshes or session changes.
Database Layer
The database stores all non-custodial system state required for tracking and evaluation.
Stored data includes:
Generated AI signals
Active and historical positions
Entry, exit, TP, and SL parameters
Position status transitions
Performance metrics
No private keys, signing data, or user funds are ever stored. The database exists solely to support tracking, analysis, and transparency.
AI Engine
The AI engine operates as a deterministic intelligence layer, not an autonomous trading agent.
Responsibilities:
Process structured market inputs
Generate signals as strict data objects
Output predefined trade parameters
Attach reasoning context for interpretability
All AI outputs are validated and stored before entering the position lifecycle, ensuring that signals are traceable, reviewable, and measurable.
On-Chain Execution Layer
The blockchain layer represents the final source of truth for trade settlement.
Responsibilities:
Quote liquidity across available venues
Construct executable swap transactions
Allow client-side signing via user wallets
Settle trades directly on-chain
Zoryu does not intermediate execution or custody funds. It coordinates execution while preserving full user control.
Data Flow
Market → Signal → Position → Metrics
Zoryu’s data flow is designed to move linearly from information to measurable outcome.
Market Data Ingestion Live price and volume data are fetched and normalized by the backend.
Signal Generation Market data is passed into the AI engine, which returns structured signals with explicit trade parameters.
Position Creation Each signal becomes a tracked position with defined lifecycle states.
Position Monitoring Live prices are continuously compared against entry, TP, and SL levels.
Metrics Calculation Position outcomes are recorded and aggregated into performance metrics such as win rate and PnL.
This flow ensures that every signal is accountable to an observable outcome.
Execution Flow
Quote → Swap Transaction → Sign → Settle
Execution in Zoryu follows a transparent, non-custodial flow.
Quote Retrieval The backend requests pricing and routing quotes from available on-chain liquidity sources.
Transaction Construction A swap transaction is built based on the selected route and user-defined parameters, including slippage.
Client-Side Signing The transaction is sent to the frontend and signed directly by the user’s connected wallet.
On-Chain Settlement The signed transaction is submitted to the Solana network and settled on-chain.
Execution Confirmation Transaction signatures and results are returned to the system and recorded for verification and tracking.
This flow ensures that execution remains verifiable, user-controlled, and free from custodial risk.
Last updated