Data Layer
-> Feature Engine
-> Prediction Model
-> Strategy Engine
-> Risk Engine
-> Execution Agent
-> Trust & Audit Layer
| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | The Data Layer is responsible for ingesting multi-source data. The Feature Engine transforms raw data into features that can be understood by the model. The Prediction Model identifies market conditions and estimates future probabilities. The Strategy Engine selects the optimal strategy portfolio. The Risk Engine manages position sizing, leverage, and drawdown constraints. The Execution Agent executes actions and adjusts strategy parameters. The Trust & Audit Layer records model versions, data sources, execution environments, and execution results. #### 4.3 Multi-Source Data Inputs The quality of an AI prediction model depends heavily on its data. Relying solely on price data can easily lead to overfitting or incorrect predictions. Therefore, manadia adopts a multi-source data architecture that includes: * CEX market data * CEX order book depth * Trading volume and aggressive buy/sell flow * Perpetual funding rates * DEX on-chain liquidity * AMM pool states * On-chain address behavior * Prediction market probabilities * News events * Social sentiment * Macroeconomic indicators * Project fundamental data * Oracle data Among these, CEX data provides a high-frequency liquidity perspective, DEX data provides insights into on-chain capital flows, prediction market data reflects collective market expectations, news and sentiment data capture event-driven signals, while on-chain data reveals capital movement and behavioral patterns. #### 4.4 Data Pipeline and Real-Time Caching The Trustworthy AI Prediction Model requires a low-latency, multi-market, continuously updated data pipeline. A typical data flow is structured as follows: |CEX WebSocket
DEX WebSocket
Prediction Market WebSocket
Oracle Feeds
News & Sentiment Feeds
-> Normalization
-> Redis / Time-series Storage
-> Feature Engine
-> Prediction & Strategy Engine
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | WebSockets are responsible for real-time data collection. The Normalization layer standardizes incoming data, while Redis or a time-series database provides low-latency caching and short-term state management. The Feature Engine retrieves data from the real-time cache to generate model features. This architecture enables the model to simultaneously process high-frequency market prices, order book changes, prediction market probability shifts, and on-chain events, while preserving structured historical data for future replay and auditing. #### 4.5 Feature Engineering The Feature Engine supports hybrid computation of both real-time and offline features, covering hundreds of factors including momentum, volatility, funding rates, order book imbalance, on-chain capital flows, sentiment intensity, and prediction market probability deviations. By leveraging time-series databases and distributed caching, the system enables low-latency feature retrieval, ensuring millisecond-level inference even during periods of extreme market volatility. Rather than directly reading raw prices and predicting market direction, the AI Prediction Model constructs a comprehensive representation of market conditions through feature engineering. Common features include: * Price momentum features * Volatility features * Trading volume change features * Order book depth features * Buy/sell pressure features * Funding rate features * Basis spread features * On-chain capital flow features * Address behavior features * Prediction market probability change features * News event intensity features * Social sentiment features * Cross-market spread features * Liquidity shock features Through these multi-factor features, the model can recognize different market conditions. For example, trending markets, ranging markets, event-driven markets, liquidity droughts, extreme funding rate environments, and converging prediction market probabilities all require different trading strategies. Example: Raw Data: |{
timestamp: 1234567890,
bid\_price: 45230.5,
ask\_price: 45231.2,
bid\_volume: 5.2,
ask\_volume: 4.8,
last\_trade\_price: 45230.8,
last\_trade\_volume: 0.5
}
| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Computed Features: |# Market Microstructure Features
spread = ask\_price - bid\_price = 0.7
mid\_price = (bid\_price + ask\_price) / 2 = 45230.85
imbalance = (bid\_volume - ask\_volume) / (bid\_volume + ask\_volume) = 0.04
vwap\_5min = ... (5-minute Volume Weighted Average Price)
realized\_vol\_1h = ... (1-hour realized volatility)
# Trend Features
momentum\_5min = price\_now - price\_5min\_ago
momentum\_1h = price\_now - price\_1h\_ago
trend\_strength = ... (trend strength indicator)
# On-chain Features
whale\_activity\_24h = Number of large-value transfers
liquidity\_score\_dex = Current DEX liquidity vs. historical average
large\_transfer\_alert = Presence of abnormal large transfers
# Sentiment Features
social\_sentiment\_score = ... (-1 to 1)
news\_sentiment = ... (-1 to 1)
twitter\_volume\_zscore = ... (number of standard deviations)
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | These features are then fed into the model, allowing it to learn that certain combinations of features typically indicate upward price movement, while others tend to signal downward price movement. #### 4.6 Model Training and Evaluation The training process of the manadia AI Prediction Model may include: * Historical data cleansing * Feature generation * Sample labeling * Training and test set splitting * Rolling-window training * Out-of-sample testing * Multi-strategy backtesting * Parameter stability testing * Stress testing under extreme market conditions * Live trading simulation Evaluation metrics should not focus solely on returns, but should also include: * Monthly performance * Maximum drawdown * Sharpe Ratio * Calmar Ratio * Win rate * Profit-loss ratio * Volatility * Slippage impact * Transaction fee impact * Capital utilization * Strategy capacity * Out-of-sample performance * Performance under extreme market conditions During testing under specific market cycles and strategy combinations, the manadia AI Prediction Model achieved strategy performance exceeding 50% monthly returns. This metric should be interpreted as a demonstration of the model's ability to capture Alpha under specific conditions, rather than as a guarantee of fixed returns. This technical white paper consistently distinguishes between historical strategy performance, model capability validation, and future performance guarantees. #### 4.7 Prediction and Strategy Inference The output of the Trustworthy AI Prediction Model is not simply a bullish or bearish prediction, but a set of structured decision signals, including: * Market state * Trend direction * Volatility expectations * Risk level * Signal confidence * Strategy recommendations * Position recommendations * Stop-loss conditions * Market-making parameters * Hedging parameters * Execution priority The model dynamically selects strategy combinations based on different market conditions. For example, it may employ grid strategies during ranging markets, funding rate strategies during periods of extreme funding rates, volatility strategies during event-driven markets, and arbitrage or hedging strategies when cross-market spreads widen. Model Inference and Decision Flow:observe market\_state
generate prediction\_signal
select strategy\_set
check risk\_constraints
calculate position\_size
execute action
record trace
evaluate result
update strategy weights
| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | #### 4.9 Risk Management System AI prediction models must explicitly acknowledge market risk. The professionalism of Trustworthy AI lies not in avoiding risk, but in structuring, parameterizing, and making risk fully auditable. The risk management system should include: * Per-strategy position limits * Total position limits * Single-market exposure limits * Cross-market exposure limits * Maximum leverage limits * Maximum drawdown limits * Daily loss limits * Volatility circuit breakers * Data anomaly circuit breakers * Suspension under insufficient liquidity * Slippage protection * Strategy degradation mechanisms These risk parameters should be associated with specific model versions and strategy configurations, making them available for review within the auditing system. #### 4.10 TEE Trusted Execution Trusted Execution Environment (TEE) is a critical component of the Trustworthy AI Prediction Model. It provides hardware-level isolated execution environments that protect model weights, strategy parameters, core logic, and sensitive data. TEE is responsible for generating Execution Proofs, anchoring key information—including model hashes, data digests, execution timestamps, and output fingerprints—onto the blockchain. Auditors can verify execution authenticity without accessing the model in plaintext, thereby establishing a trustworthy execution framework in which code cannot be tampered with, execution cannot be forged, and results can be independently verified. Within the system, TEE serves three primary purposes. First, it protects model developers. The parameters, strategy logic, and training outcomes of prediction models are valuable intellectual property. TEE reduces the risk of unauthorized copying or theft during execution. Second, it protects data providers. Certain high-value data sources may contain proprietary information or sensitive factors. TEE minimizes the exposure of such data in plaintext during execution. Third, it enhances execution trustworthiness. By recording model versions, input digests, execution environments, and outputs, the system establishes a reliable foundation for subsequent auditing and replay. TEE does not guarantee prediction accuracy, nor does it eliminate market risk. Its role is to ensure a trustworthy execution environment, protect models and data, and provide verifiable execution records. #### 4.11 Three Pillars of Trust **Why Trace Execution?** Suppose an AI Prediction Model makes the following prediction: "BTC will increase by 3% within the next hour." * The prediction is correct, and users profit → The result is accepted. * The prediction is incorrect, and users incur losses → Questions arise: Was the model incorrect? Was the data flawed? Were the parameters wrong? Or did the implementation fail? Without execution tracing, these questions cannot be answered. With execution tracing, we can: * Replay all input data used at the time to verify whether the model inputs were correct. * Determine which model version was used and review its historical performance. * Inspect the constraints enforced by the risk management module. * Verify whether execution suffered from latency or slippage. * Ultimately determine whether the issue originated from the model itself or from the implementation. **What Is Traced?**| Component | Tracked Information |
| Data Pipeline | Timestamp, value, and version of every sampled data source |
| Feature Engineering | Computation time and source data used for every feature |
| Model Inference | Model version, parameters, inputs, outputs, and confidence score |
| Risk Management | Current positions, VaR, drawdown, and triggered constraints |
| Strategy Selection | Why a strategy was selected and which alternatives were evaluated |
| Execution | Invoked tools, input parameters, and returned results |
| Results | Execution price, slippage, and final P&L |