DRADIS

Requirements

• Rust 1.95+ (or Docker)
• A Polygon wallet with USDC and MATIC
• A paid Polygon RPC endpoint (required for auto-settlement) — See RPC Configuration below
• Telegram bot token (optional, see Notifications)
• X developer credentials (optional, see Notifications)

2. Deploy (builds Rust engine + Control Tower, starts Ollama, pulls model)

chmod +x deploy-multi.sh && ./deploy-multi.sh

After ~5 minutes the stack is live:

| Service | URL |
|---|---|
| **Control Tower** | `http://<host>:3002` |
| **DRADIS REST API** | `http://<host>:9000/api/health` |
| **Ollama** | `http://<host>:11434/api/tags` (internal) |

**Verify Ollama is healthy** (run from your local machine):

Prerequisites: Docker on the remote host, Rust 1.95+ only needed for local builds. See the Control Tower section for dashboard setup and the Setup section for all tunable parameters.

---

Setup

Production Deployment (Docker)

Open these ports in your AWS Security Group first:

Both containers share a private Docker network (dradis-net) — the UI calls the API via internal DNS (http://dradis-btc:9000) so port 9000 never needs to be public-facing.

./deploy-multi.sh

This will: 1. SCP all source files to your server 2. Build the DRADIS Rust image on the server (cross-compiles natively) 3. Build the Control Tower Next.js image (3-stage: deps → build → minimal runner) 4. Start both containers with --restart unless-stopped 5. Tail the BTC engine logs

After deploy: - Dashboard: http://YOUR_SERVER_IP:3002 (login with CT_USERNAME / CT_PASSWORD from .env) - API Health: http://YOUR_SERVER_IP:9000/api/health

Check container logs remotely:

ssh -i ~/.ssh/your-key.pem ubuntu@YOUR_SERVER_IP "docker logs -f dradis-btc --tail 50"
ssh -i ~/.ssh/your-key.pem ubuntu@YOUR_SERVER_IP "docker logs control-tower --tail 50"

---

Medium-term (deployment profiles)

• Static deployment profiles (profiles.toml) — named configurations that each bind a market, a viper subset, capital allocation, and risk overrides; the current config.rs becomes the implicit "default" profile with zero behavior change
• Per-profile P&L tracking — DB and API namespaced by profile_id so A/B tests across viper combinations have independent ledgers
• Profile selector in Control Tower — top-level switcher so the dashboard shows the active profile's vipers, P&L curve, and trade log
• LLM live config changes — extend the LLM Advisor from recommendations-only to optionally applying approved DynamicConfig patches via a Telegram approval gate (reply YES to apply)

⚡ Quick Start

```bash

Strategy Segregation (Example Profile)

---

1. Clone and configure

git clone https://github.com/youruser/dradis.git && cd dradis cp .env.example .env # fill in POLYMARKET_PRIVATE_KEY, POLYGON_RPC_URL, TELEGRAM tokens, etc. cp deploy-multi.sh.example deploy-multi.sh # fill in HOST, USER, KEY

Live Config Editing

Every parameter shown in the Viper cards maps directly to the runtime DynamicConfig. Editing a value and pressing Enter (or toggling the switch) sends a PATCH /api/config request to the DRADIS engine — no restart required. Changes take effect on the next 50ms tick.

.env (production)

CT_USERNAME=starbuck CT_PASSWORD=your-strong-password

Configuration

// src/config.rs
pub const ENABLE_LLM_ADVISOR: bool = true;          // master switch (default: false)
pub const LLM_ADVISOR_INTERVAL_SECS: u64 = 1800;   // how often to run (30 min default)
pub const LLM_ADVISOR_TRADES_LOOKBACK: i64 = 20;   // trades per analysis window
pub const LLM_OLLAMA_URL: &str = "http://localhost:11434";  // Ollama base URL
pub const LLM_OLLAMA_MODEL: &str = "llama3.2";     // model name

Override the URL and model at runtime without rebuilding:

```bash

.env or server environment

OLLAMA_URL=http://192.168.1.10:11434 # remote Ollama instance (GPU box, etc.) OLLAMA_MODEL=mistral # any model installed in your Ollama ```

The advisor requires the same TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID env vars already used for trade alerts. If Telegram credentials are absent, the full analysis is written to the engine log instead.

RPC Configuration

The auto-settlement feature (merging/redeeming positions after market resolution) requires a reliable, paid Polygon (EVM) RPC endpoint. Free public RPCs (polygon-rpc.com, Ankr, PublicNode) are unsuitable — they will fail with API key or nonce errors during settlement.

⚠️ Helius is a Solana-only RPC — do not use it for DRADIS. Using a Solana endpoint will result in "Method not found" errors.

Recommended providers (all with free tiers, all support Polygon): - Alchemy — recommended; excellent free tier, easy Polygon mainnet setup - QuickNode — reliable, industry standard - Infura — simple setup, generous free tier

Once you have an API key, add it to .env: ```bash

Configuration Profiles

src/config.rs is NOT included in this repository. It is your personal trading configuration and is intentionally gitignored so your own tuning stays private.

Three ready-to-use starting profiles are provided. You must copy one to src/config.rs before you can build.

```bash

.env or server environment

TELEGRAM_BOT_TOKEN=123456789:AABBCCdd... TELEGRAM_CHAT_ID=-100123456789

---

.env

DRADIS_API_KEY=replace-with-a-strong-random-secret

**How it works end-to-end:**

The Control Tower proxy (`/api/[...path]/route.ts`) reads `DRADIS_API_KEY` as a **server-side env var** and forwards it automatically — the key never appears in the browser JS bundle. Local development with no `DRADIS_API_KEY` set works exactly as before with no login prompt.

Generate a strong key:

#### Example Cloudflare Tunnel setup

Alchemy: POLYGON_RPC_URL=https://polygon-mainnet.g.alchemy.com/v2/YOUR_API_KEY

Infura: POLYGON_RPC_URL=https://polygon-mainnet.infura.io/v3/YOUR_API_KEY

POLYGON_RPC_URL=https://polygon-mainnet.g.alchemy.com/v2/YOUR_API_KEY ```

The startup will fail with a clear error if POLYGON_RPC_URL is not set.

Integrations

OpenClaw Integration (Live Natural-Language Control)

OpenClaw is a personal AI assistant that executes tasks from plain English via WhatsApp, Telegram, or any chat app. Because DRADIS exposes a clean REST API, it can be registered as an OpenClaw skill — giving you full voice/text control of your trading bot from your phone, no dashboard required.

openclaw skills install dradis-tactical-command

Once installed, OpenClaw maps natural language to DRADIS API calls automatically:

Prerequisites

OpenClaw needs to reach your DRADIS API over the internet. Port 9000 is internal by default — expose it securely using one of:

• Cloudflare Tunnel (cloudflared tunnel) — zero open inbound ports, free tier available, recommended
• Nginx reverse proxy with TLS on your server
• AWS Security Group — open port 9000 to a specific IP only (your phone's egress)

API Key Authentication

DRADIS has built-in optional API key enforcement. Set DRADIS_API_KEY in your .env file and every request to the engine must include a matching X-API-Key header:

```bash

FAQ

Why Rust instead of Python?

Rust provides fearless concurrency. Evaluating five strategies concurrently every 50ms requires a multi-threaded runtime without a Global Interpreter Lock (GIL) or unpredictable Garbage Collection (GC) pauses.

Why isn't the bot trading?

Check in order: 1. Is GHOST_MODE true? 2. Fees: Taker strategies skip high-fee (1000 bps) markets. 3. Thresholds: Check your thresholds in config.rs. Momentum and Basis require specific volatility/skew to fire. 4. Venue: Maker/Arb/Basis require a Window or Daily market to be active.

I see Momentum and Maker trading the same token — is that a bug?

No. Each strategy has its own independent position book. They can "co-habitate" on the same token without collision.

How do I adjust risk?

Edit the per-strategy constants in src/config.rs, specifically the _MAX_EXPOSURE_USDC values.

How can I optimize my host for maximum performance?

See docs/PERFORMANCE_TUNING.md for a full guide covering kernel sysctl tuning, CPU frequency governor, CPU/IRQ affinity pinning, Docker ulimits, and instance selection tips for AWS and OCI.

Why doesn't DRADIS include a backtesting framework?

Short answer: Ghost mode running against live markets is a better substitute than it first appears, and a traditional backtester would introduce more problems than it solves for prediction-market trading.

Here's why:

The recommended workflow instead:

1. Set GHOST_MODE = true in config.rs and run overnight or across a full session.
2. Download your session.file and run tools/session_parser.py (see tools/README.md) for a per-trade breakdown with market context.
3. Identify loss patterns → tune config.rs constants → run another ghost session.
4. Repeat until the strategy shows consistent positive expectancy in ghost mode before enabling live execution.

This loop uses real market data, real strategy logic, and zero capital risk — which is exactly what a backtester promises but rarely delivers cleanly for illiquid, event-driven prediction markets.

I pulled an update and GBoost is producing garbage predictions / the model won't load.

The GBoost model is incompatible across feature vector changes. The model file name in GBOOST_MODEL_PATH is intentionally versioned (e.g. gboost_model_v14f.json) so that a stale on-disk model with the wrong input dimension is never silently loaded against code expecting a different one.

If you pull an update and NUM_FEATURES in src/strategies/gboost_impl.rs has changed, you must:

1. Check whether the suffix in GBOOST_MODEL_PATH (in src/config.rs / your example profile) matches the new feature count. 2. If it doesn't — or if the old model file still exists under the old name — delete the old file and let the bot retrain from scratch:

   rm -f logs/gboost_model_*.json
   

The safe pattern when adding a new feature: bump the suffix in GBOOST_MODEL_PATH (e.g. v14f → v15f). The old file is ignored, no manual cleanup needed.

How do I tune strategy parameters without restarting?

Use the Control Tower dashboard (http://localhost:3002 locally, or your server IP in production). Click any parameter value in a Viper card to edit it inline — changes are applied live via PATCH /api/config on the next engine tick. Toggle switches enable/disable strategies instantly. No rebuild or restart needed.

The Control Tower shows "Offline".

The UI polls GET /api/health every 5 seconds. "Offline" means the DRADIS engine isn't reachable. Check: 1. Is DRADIS running? (ps aux | grep dradis or docker ps) 2. Is the API port open? (curl http://localhost:9000/api/health) 3. In Docker — is the Control Tower container on the same dradis-net network as dradis-btc?

How do I enable the LLM Advisor?

1. Install Ollama and pull a model: ollama pull llama3.2
2. In src/config.rs, set ENABLE_LLM_ADVISOR: bool = true
3. Rebuild: cargo build --release
4. Make sure TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID are set in your .env (same as trade alerts)
5. Optionally set OLLAMA_URL if your Ollama instance is on a different host

The advisor will fire after the first interval (LLM_ADVISOR_INTERVAL_SECS, default 30 min) once at least one trade has been recorded. If Telegram creds are absent, the full analysis is written to the engine log instead.

The LLM Advisor isn't sending messages.

Check in order: 1. Is ENABLE_LLM_ADVISOR = true in config.rs? (default is false) 2. Is Ollama running and reachable? curl http://localhost:11434/api/tags 3. Is the model installed? ollama list — if not, ollama pull llama3.2 4. Are TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID set? If not, check the engine log — the analysis is printed there instead. 5. Have enough trades completed? The advisor skips cycles where the DB has no completed trades yet. 6. Has the first interval elapsed? The advisor skips the first tick at startup and waits one full LLM_ADVISOR_INTERVAL_SECS before the first analysis.

Can the LLM Advisor apply config changes automatically?

Not yet — recommendations are advisory only. The automatic apply path (Telegram approval gate → PATCH /api/config) is on the roadmap. For now, take the suggestions and apply them manually via the Control Tower UI or by editing src/config.rs.