WEEX Alpha Awakens — Submission (R&D Strategy Platform)

TL;DR

• This repo already contains 4 working modules: DRL training/validation, an engineering-grade bot with tests, a production skeleton with risk management + backtesting, and a standalone WEEX API client.
• The official submission can be one, while still containing multiple research branches as a “strategy family” under a single risk layer and unified execution rules.
• The focus is not “a bot with PnL”, but a reproducible R&D pipeline: data → features → training → strict validation (anti-overfit) → backtesting → WEEX API integration.
• Related prior FinRL case study (preliminary): https://github.com/PrometheusAI-Labs/SecureFinAI_Contest_2025

---

0) What’s in this repository (as-is)

Module	Role in the system	What’s already implemented
FinRL_Crypto/	DRL research loop + anti-overfit validation	CryptoEnvCCXT (CCXT), CPCV/KCV/WF optimization (1_optimize_*.py), validation (2_validate.py), backtesting (4_backtest.py)
finrl_rnd_bot/	Engineering loop (package, CLI, tests)	Stable-Baselines3 models + ensemble (src/finrl_trading/models/), CCXT downloader (ccxt_downloader.py), Makefile/tests
RLAttacker/	Production skeleton: risk, monitoring, backtester	RiskManager (stop-loss/take-profit/drawdown/confidence), backtest engine (backtesting.py), data tools + validation, Telegram bot, run artifacts (validation_*.csv/png)
WEEX_INTEGRATION/	WEEX-specific integration	WeexAPIClient (HMAC auth, retry, contract/spot API, symbol/format discovery), logging (weex_api.log)

Core idea: don’t lock into one model forever — keep multiple research directions and compare them under the same validation and risk framework.

---

1) Policy / Strategy Description (one submission, multiple research branches)

1.1. System architecture

One execution + risk loop, with pluggable policies:

1. Data layer: OHLCV + baseline indicators/features (via CCXT/processors).
2. Model layer (strategy family):
   • Branch A (FinRL_Crypto): DRL agents (PPO/A2C/DDPG/TD3/SAC, etc.) + strict CV-style validation.
   • Branch B (finrl_rnd_bot): baseline/enhanced/ensemble SB3 models + engineering tests/CLI.
   • Branch C (RLAttacker): time-series representation via TCN + Dueling DQN (production pipeline prototype).
3. Risk layer: shared entry/exit rules, limits, stops, drawdown control.
4. Execution layer: WEEX adapter (WEEX_INTEGRATION/) + (optionally) CCXT execution.

1.2. Trading logic (rule level)

Entry/exit is defined by risk gates, not “model intuition”:

• Entry is allowed only if risk and confidence constraints pass (see RLAttacker/risk_management.py → check_entry_conditions()).
• Exit is driven by:
  • stop-loss / take-profit,
  • system drawdown controls,
  • daily loss limits (see check_exit_conditions()).

1.3. Risk management (minimum baseline)

The risk layer is a standalone component (reusable with any policy):

• Position sizing limits (calculate_position_size() using volatility/regime/drawdown adjustments).
• Stop-loss / take-profit / max drawdown / daily loss limits.
• Minimum confidence threshold for entry.

Note: the production skeleton defaults to conservative max_leverage=1.0 (see PositionLimits), i.e. no leverage; it can be parameterized to match competition limits (≤ 20x) without changing the architecture.

---

2) AI Participation Description (what AI actually does)

AI/ML is used where purely manual rules tend to break in crypto:

• Learning a trading policy from historical data (DRL agents in FinRL_Crypto/ and SB3 models in finrl_rnd_bot/).
• Capturing temporal dependencies via TCN architectures (RLAttacker/models.py).
• Ensembling to reduce model risk via diversified policies (finrl_rnd_bot/src/finrl_trading/models/ensemble.py).
• Regime-aware adaptation (the production skeleton already supports regime-aware sizing logic in RiskManager).

Crucially, trade permission and risk are enforced independently of the model to avoid gambling-style behavior.

---

3) Validation and anti-overfitting (required R&D loop)

3.1. Strict validation (FinRL_Crypto)

FinRL_Crypto/ provides ready-to-run workflows:

• CPCV: FinRL_Crypto/1_optimize_cpcv.py, FinRL_Crypto/function_CPCV.py
• KCV: FinRL_Crypto/1_optimize_kcv.py
• Walk-forward: FinRL_Crypto/1_optimize_wf.py
• Validation/backtest: FinRL_Crypto/2_validate.py, FinRL_Crypto/4_backtest.py

This helps avoid “nice PnL on one split”.

3.2. Prior FinRL case study (external reference)

As an additional preliminary proof-of-capability, we reference a separate FinRL-based project/case study: https://github.com/PrometheusAI-Labs/SecureFinAI_Contest_2025

3.2. Engineering reproducibility (finrl_rnd_bot)

finrl_rnd_bot/ is structured as a package with a CLI and tests — useful for reproducible experiments and regression checks.

3.3. Production artifacts (RLAttacker)

RLAttacker/ already contains run artifacts suitable for reporting/demo:

• RLAttacker/validation_trades.csv
• RLAttacker/validation_positions.csv
• RLAttacker/validation_results.png

---

4) WEEX integration (what exists and how we plug it in)

WEEX_INTEGRATION/main.py implements a client with:

• HMAC-SHA256 signing + required headers,
• retry/backoff (tenacity),
• separate base URLs for contract/spot APIs,
• connectivity tests and symbol/format auto-discovery (get_available_symbols(), test_symbol_format()).

Integration path (without changing the research code):

1. Train/validate policies offline (FinRL_Crypto and/or finrl_rnd_bot).
2. In the production loop (RLAttacker/), connect WEEX execution via WeexAPIClient (instead of the Binance/WebSocket layer), keeping RiskManager and logging intact.

---

5) How to run (quick, by module)

FinRL_Crypto (R&D: CV/backtest)

cd FinRL_Crypto
python 0_dl_trainval_data.py
python 1_optimize_cpcv.py
python 2_validate.py
python 4_backtest.py

finrl_rnd_bot (engineering: CLI/tests/ensembles)

cd finrl_rnd_bot
make help
make train-ensemble
make test

RLAttacker (production skeleton: risk/bot/backtest)

cd RLAttacker
make help
make train-btc
make backtest
make infer-safe

WEEX_INTEGRATION (WEEX API client)

cd WEEX_INTEGRATION
uv sync
python main.py

---

6) Answer to the key question: can we propose multiple research solutions?

Yes — as one official submission, but as one unified system:

• This repository already contains at least 3 research branches (FinRL_Crypto / finrl_rnd_bot / RLAttacker) plus a shared integration/risk layer.
• The right WEEX packaging is a “strategy family” under shared risk constraints and a unified reporting loop (validation/backtest/logs).

In practice: you describe one architecture, and inside it include multiple policies (baseline/enhanced/ensemble/regime-aware), evaluated consistently and selected/routed by explicit rules.

---

7) What we need to confirm with WEEX (to finalize integration)

• Spot vs contract (or both) and the allowed endpoints for trading/data.
• Required symbol format/prefixes (the client already probes multiple formats).
• Paper trading / sandbox requirements (if any) and rate-limit constraints.
• The set of required trading pairs for final evaluation.