DRADIS PolyMarket & Kalshi Trading Automation

Skill: DRADIS Tactical Command (v1.5.1)

Full-featured autonomous supervisor for the DRADIS high-frequency prediction market execution engine.

What's new in v1.5.1

• Corrected PATCH contract. Config PATCH bodies are a flat partial object, not a wrapped updates object. A wrapped body is silently ignored and still returns 200 OK — see Applying config changes for the mandatory verification step.
• Corrected squadron ids. Ids are {asset}-{cadence} (e.g. btc-hourly), never a bare asset name. Always read them from list_squadrons.
• patch_dynamic_config no longer affects trading. Strategy execution reads squadron-scoped config exclusively; the global endpoint now only governs the LLM advisor. Use patch_squadron_config for anything that changes trading behaviour.
• New read tools: get_viper_status (why isn't it trading?), get_llm_actions + approve/reject (the AI action queue), get_telemetry, get_telemetry_history, get_telemetry_assets, get_logs, get_latency, get_taxonomy_raptors, get_taxonomy_vipers, get_available_markets, get_deployments, get_deployment_region.
• Documented DRADIS_READ_ONLY (403 on writes), public vs. protected routes, query-param defaults and clamps, and per-venue endpoint availability.

About DRADIS

DRADIS is an open-source, low-latency Rust trading engine for crypto prediction markets. It features a Viper strategy engine, real-time equity curve, dynamic config hot-reloading, and a built-in LLM advisor.

Project repository: https://github.com/mbordash/DRADIS

Venues

DRADIS builds against exactly one venue at a time (mutually exclusive Cargo features):

The agent cannot tell which build is running from the venue name alone — call get_deployment_region to find out. This matters because a few endpoints are build-specific (noted per tool below).

Architecture the agent should understand

• A CAG (Commander Air Group) runs one or more Squadrons, one per market.
• Each Squadron owns Raptors (signal feeds) and Vipers (strategies), plus its own DynamicConfig.
• Squadron config is the only config that affects trading. The global /api/config object is a separate, legacy-scope record that now only feeds the LLM advisor.

Publisher Note (Addressing ClawScan Findings)

ClawScan has flagged two medium-risk items (as expected for any live-trading integration):

• Ability to PATCH live strategy parameters
• Forwarding of a sensitive DRADIS_API_KEY

These are intentional and documented. The skill never applies config changes without explicit human confirmation.

This skill is monitoring and configuration only, by design. It deliberately exposes no tool that opens, closes, or settles a position, and none that deploys a squadron. The engine's API does offer such endpoints (DELETE /api/positions/{token_id}, POST /api/positions/manual-exit, POST /api/positions/sync, POST /api/squadrons/deploy) — they are omitted here so that no agent turn can spend money or flatten a position. Perform those actions in the Control Tower UI.

I strongly recommend using a dedicated, least-privilege API key and only running this skill against your own trusted DRADIS instance.

Authentication

DRADIS supports optional API key authentication via the X-API-Key header.

• Set DRADIS_API_KEY in your OpenClaw configuration.
• The skill automatically adds the header to every request.
• Local use works without a key; remote/production use strongly recommends it.

Public vs. protected routes. check_engine_status (/api/health) and list_assets (/api/assets) are intentionally unauthenticated so that container health checks and load balancers can probe them. Every other tool requires the key when DRADIS_API_KEY is set. A healthy /api/health alongside 401s elsewhere means the key is wrong, not that the engine is down — report it that way.

Error codes the agent must distinguish

Safety & Usage Guidelines (Critical)

This skill controls a live trading system with real money at risk. The agent must follow these guardrails at all times:

• Never apply any configuration change without first explicitly confirming the exact update with the human user and receiving clear approval.
• Always call get_config_schema before proposing a patch, to validate the field name, type, unit, and min/max bounds.
• Never construct a squadron id. Read ids from list_squadrons and use them verbatim.
• Only call tools when the user's request directly relates to monitoring or configuration.
• When reporting numbers, carry the engine's own caveats through: prices_live: false in get_portfolio_value means positions are marked with stale prices, and get_viper_status rows older than 120 seconds mean the evaluation loop is not reporting.

Applying config changes

The PATCH body is a flat JSON object containing only the fields to change. It is not wrapped in an updates key.

// CORRECT
{"time_decay_position_size_usdc": "8.0", "enable_basis": false}

// WRONG — silently ignored, still returns 200 OK with the UNCHANGED config
{"updates": {"time_decay_position_size_usdc": "8.0"}}

The engine merges the body over the current config and ignores keys it does not recognise. A misspelled field, or a wrapped body, therefore produces a successful-looking response in which nothing changed.

Mandatory verification step: a 200 OK does not mean the change was applied. Both PATCH endpoints return the full resulting config. After every patch, read back the specific field you changed from the response body and confirm it holds the new value. Report success only if it does; if it does not, tell the user the patch was rejected as an unknown field and did not take effect.

Which config endpoint to use

patch_dynamic_config writes the global config record, which no squadron reads. Strategy execution loops read a per-squadron config handle, and newly deployed squadrons seed from compile-time defaults rather than the global record. Patching global config to change trading behaviour will appear to succeed and will change nothing. If the user asks to change a strategy parameter without naming a squadron, list the squadrons and ask which one — do not fall back to the global endpoint.

Example Natural Language Commands

• "What's the current status of DRADIS?"
• "Why isn't DRADIS trading right now?"
• "Show me open positions and session P&L"
• "What markets is each strategy currently trading?"
• "List the last 10 trades"
• "What does the LLM advisor recommend right now?"
• "Are there any AI config changes waiting for my approval?"
• "Show me the last 200 log lines"
• "What's our current latency to the venue?"
• "List my squadrons and their P&L"
• "Show me the btc-hourly squadron's config"
• "What's my total portfolio value right now?"
• "Show pending vs confirmed positions for ETH"
• "Can you increase the adverse block threshold on btc-hourly? Show me the current value first and confirm before patching."

Configuration

• DRADIS_API_URL: Base URL for the engine API (Default: http://localhost:9000/api)
• DRADIS_API_KEY: API key for authentication (optional locally, recommended for remote/production)

---

Tools

All tools send X-API-Key: {{DRADIS_API_KEY}}.

Engine health & inventory

1. check_engine_status

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/health
• Response: the literal text ok
• Note: Public — succeeds without an API key. Use it to separate "engine down" from "key wrong".

2. list_assets

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/assets
• Response: JSON array of asset symbols with an initialised database, e.g. ["btc", "eth", "sol"]
• Note: Public. Includes venue-only databases (e.g. "kalshi") that carry no raptor signal data; get_telemetry_assets returns the narrower set that does.

3. get_deployment_region

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/deployment/region
• Response: {"region": "intl" | "us" | "kalshi", "available_types": ["politics", "sports", "crypto"]}
• Note: Call this first when a venue-specific behaviour matters.

4. get_strategy_status

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/status
• Response: {"strategy_markets": {…}, "session_started_at": "…", "raptors": {…}} — the strategy→market mapping, the current session id, and per-asset raptor connection health.

5. get_viper_status

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/vipers/status
• Query Param: asset (optional, e.g. btc; omit for all squadrons)
• Response: JSON array of {asset, strategy, last_eval_at, last_eval_secs_ago, last_outcome, last_reason, last_reason_secs_ago, last_signal_at, last_signal_secs_ago}
• Note: This is the correct tool for "why isn't DRADIS trading?" last_outcome is one of signal | no_signal | error | timeout. last_reason is the named gate that vetoed the most recent entry attempt ("edge below required", "cooldown active"); only instrumented vipers populate it, so null means "reports liveness only", not "no veto". Interpretation rules:
  • All vipers evaluating recently with named reasons → the engine is healthy and correctly sitting out. Say so; do not imply a fault.
  • last_eval_secs_ago > 120 → the evaluation loop is not reporting. Flag as a probable fault.
  • last_outcome of error or timeout → flag as a fault regardless of age.
  • The registry is in-memory and empty after a restart, so an absent viper means "not yet evaluated", not "never trades".

Positions & performance

6. get_open_positions

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/positions
• Query Param: asset (optional, e.g. btc)
• Response: JSON array of all open position records (pending + confirmed)

7. get_pending_positions

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/positions/pending
• Query Param: asset (optional)
• Response: JSON array of positions placed but not yet confirmed on-chain

8. get_confirmed_positions

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/positions/confirmed
• Query Param: asset (optional)
• Response: JSON array of confirmed open positions

9. get_portfolio_value

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/portfolio
• Response: {"collateral", "positions_value", "total_value", "unrealized_pnl", "position_count", "prices_live"} (decimal values as strings)
• Note: On intl builds, collateral is probed live on-chain. On us and kalshi builds there is no wallet probe, so it falls back to the database-tracked snapshot. If prices_live is false, positions are marked at stale prices — say so when quoting total_value or unrealized_pnl.

10. check_session_pnl

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/pnl/history
• Query Params: asset (optional), limit (optional, default 200, clamped 1–1000)
• Response: JSON array of equity snapshots
• Note: Omitting asset returns the aggregated curve across all assets, not the primary asset's. Pass asset explicitly whenever the user asks about one asset.

11. get_recent_trades

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/trades
• Query Params: asset (optional), limit (optional, default 100, clamped 1–500)
• Note: A limit above 500 is silently clamped; never claim more trades were returned than the array contains.

Squadrons

12. list_squadrons

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/squadrons
• Response: JSON array of squadron summaries (id, asset, market class, state, market names, active raptors/vipers)
• Note: The only valid source of squadron ids. Ids are {asset}-{cadence}, e.g. btc-hourly, btc-open. Call this before any other squadron tool.

13. get_squadron

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/squadrons/{id}
• Path Param: id — a squadron id from list_squadrons, e.g. btc-hourly
• Response: JSON squadron summary, or 404 if unknown

14. get_squadron_config

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/squadrons/{id}/config
• Path Param: id, e.g. btc-hourly
• Response: flat JSON object of the squadron's DynamicConfig, or 404 if no config row exists for that id
• Note: A 404 here means the id is wrong or the squadron has never been deployed — not that config is unavailable.

15. patch_squadron_config

• Method: PATCH
• Endpoint: {{DRADIS_API_URL}}/squadrons/{id}/config
• Path Param: id, e.g. btc-hourly
• Payload Type: application/json
• Body: a flat partial object of only the fields to change, e.g. {"time_decay_position_size_usdc": "8.0"}
• Response: the full resulting config
• Safety Note: Requires explicit user confirmation before executing. Validate field names and bounds with get_config_schema first. Unknown keys are ignored and still return 200 — read the changed field back out of the response and confirm it before reporting success. Applied changes reach the patrol loop on its next tick.
• This is the tool that changes trading behaviour.

Global config (LLM advisor scope)

16. get_current_config

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/config
• Response: flat JSON object of the global DynamicConfig
• Note: This is the global record, not any squadron's live config. To report what a strategy is actually running, use get_squadron_config.

17. patch_dynamic_config

• Method: PATCH
• Endpoint: {{DRADIS_API_URL}}/config
• Payload Type: application/json
• Body: a flat partial object, e.g. {"llm_autonomy_tier": 1}
• Response: the full resulting config
• Safety Note: Requires explicit user confirmation before executing. Same unknown-key caveat and same mandatory read-back as patch_squadron_config.
• Scope warning: This affects the LLM advisor only. No squadron reads this record, so it will not change how any strategy trades. Do not use it as a fallback when a squadron id is unknown — ask the user which squadron instead.

18. get_config_schema

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/config/schema
• Response: JSON array describing every editable field: {key, group, enable_key, label, type, unit, min, max, step, advanced}
• Note: key is exactly what a PATCH body expects. type is one of usd | price | pct | decimal | secs | bool. Use before any PATCH to validate the field name and bounds.

LLM advisor

19. get_llm_recommendations

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/llm/recommendations
• Query Params: asset (optional), limit (optional, default 10, clamped 1–50)

20. get_llm_actions

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/llm/actions
• Query Param: limit (optional, default 100, clamped 1–500)
• Response: JSON array of the AI action audit trail, newest first: {id, batch_id, ts, expires_at, model, tier, ghost_mode, field, from_value, to_value, clamped, delta_pct, reason, status, status_detail, …}
• Note: status is one of proposed | approved | applied | rejected | expired | reverted | failed. Rows with status: "proposed" are awaiting human approval. Depending on the configured autonomy tier the engine may have already applied changes on its own (status: "applied") — surface those when the user asks what changed. Reads the primary database only; the asset param is ignored here.

21. approve_llm_action

• Method: POST
• Endpoint: {{DRADIS_API_URL}}/llm/actions/{id}/approve
• Path Param: id — the numeric action id from get_llm_actions
• Safety Note: This applies a live config change. Requires explicit user confirmation, quoting the field, the from→to values, and the LLM's stated reason. The engine revalidates the proposal against the current config at approval time and returns 409 if it is no longer valid — report that as "the proposal went stale", not as an error to retry.
• Scope warning: Approval applies through the global config path, which carries the same scope limitation as patch_dynamic_config.

22. reject_llm_action

• Method: POST
• Endpoint: {{DRADIS_API_URL}}/llm/actions/{id}/reject
• Path Param: id
• Note: Only proposed actions can be rejected (409 otherwise). Rejections feed the model's negative-example corpus.

Telemetry & diagnostics

23. get_telemetry

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/telemetry
• Response: live raptor signal snapshot keyed by asset — connection flags plus oracle_price, velocity_5s, velocity_1s, acceleration, drift_60m, drift_10m, funding_rate

24. get_telemetry_history

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/telemetry/history
• Query Params: asset (optional, defaults to the primary asset), limit (optional, defaults to the full retained window ≈ 1 hour)
• Response: JSON array of telemetry samples, oldest → newest

25. get_telemetry_assets

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/telemetry/assets
• Response: JSON array of assets that actually have raptor telemetry — a narrower set than list_assets

26. get_logs

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/logs
• Query Param: tail (optional, default 500, clamped 1–2000)
• Response: {"count": n, "lines": [...]} from the in-memory ring buffer, oldest first
• Note: Log lines print in US/Eastern. They may contain market names and order details; quote only what is relevant.

27. get_latency

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/latency
• Response: rolling round-trip latency from the engine host to the trading venue

Taxonomy & deployment inventory (read-only)

28. get_taxonomy_raptors

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/taxonomy/raptors
• Query Param: market_class (required, e.g. crypto, sports, politics)
• Response: JSON array of {id, display, implemented}

29. get_taxonomy_vipers

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/taxonomy/vipers
• Query Param: market_class (required)
• Response: JSON array of {id, display, venue_agnostic}

30. get_available_markets

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/markets/available
• Query Params: market_type (required: crypto | sports | politics), expiry_window (optional: 1h | 4h | 24h | 7d; default varies by type — 24h sports, 30d crypto, 90d politics), min_liquidity (optional, default 500)
• Response: {"markets": [...]} — candidate markets for deployment
• Note: Informational only. This skill exposes no deployment tool; deploy from the Control Tower UI.

31. get_deployments

• Method: GET
• Endpoint: {{DRADIS_API_URL}}/deployments
• Response: JSON array of deployment requests with status: {id, market_id, market_type, raptors, vipers, status, squadron_id, error, created_at}

---

Endpoints deliberately NOT exposed

These exist on the engine API and are omitted on purpose. If a user asks for them, explain that the skill is monitoring-and-configuration only and direct them to the Control Tower UI.