/superior-trade

name: superior-trade
description: "Use when a user wants to start trading with Superior Trade and does not have everything set up yet — getting an API key, creating and funding a trading account, choosing a venue or strategy, running a first backtest, or going live. Start here, then hand off to the venue skill. Covers Hyperliquid, Polymarket, Lighter, and Aerodrome."
license: see LICENSE
metadata:
  version: 1.0.0
  updated: 2026-08-12
  homepage: https://account.superior.trade
  source: https://github.com/Superior-Trade
  primaryEnv: SUPERIOR_TRADE_API_KEY
  auth:
    type: api_key
    env: SUPERIOR_TRADE_API_KEY
    header: x-api-key
    scope: "Read the user's Unified account, managed wallet, and venue context; manage backtests and deployments; and perform only contract-supported wallet or execution writes after explicit confirmation. Cannot export private keys or access other users' data."
  env:
    - name: SUPERIOR_TRADE_API_KEY
      required: true
      description: "Superior Trade API key, sent as the x-api-key header. Covers every venue."
      type: api_key
  openclaw:
    requires:
      env:
        - SUPERIOR_TRADE_API_KEY
    primaryEnv: SUPERIOR_TRADE_API_KEY
    envVars:
      - name: SUPERIOR_TRADE_API_KEY
        required: true
        description: Superior Trade API key, sent as the x-api-key header.

Superior Trade — Start Here

Getting a user from nothing to a running strategy. This skill owns the path; each venue skill owns the venue.

**Base URL:** `https://api.superior.trade` **Auth:** `x-api-key` header on every protected endpoint **Account UI:** `https://account.superior.trade`

Read [`../../references/unified-runtime.md`](../../references/unified-runtime.md) before constructing an API request. Use only routes published by `GET /openapi.json`; do not fall back to a versioned API.

The path

Work through these in order. Skip a step only after an API call confirms it is already done — never on assumption.

• [ ] **1. Credentials** — is `SUPERIOR_TRADE_API_KEY` set?
• [ ] **2. Trading account** — does the user have a trading wallet?
• [ ] **3. Funds** — is there capital on the venue the strategy will trade?
• [ ] **4. Strategy** — what are they trying to do, and which template fits?
• [ ] **5. Backtest** — does the idea survive contact with historical data?
• [ ] **6. Deploy** — confirm explicitly, then start.
• [ ] **7. Monitor** — status and logs, and how to stop.

1. Credentials

One key covers every venue. `SUPERIOR_TRADE_API_KEY` authenticates Hyperliquid, Polymarket, Lighter and Aerodrome alike — the API validates the key against the user, not against a product, so there is no per-venue credential to obtain.

If it is already in the environment, use it and move on — do not ask the user for it.

If it is missing, ask for the email address that should receive an OTP, then:

curl -sS https://api.superior.trade/account/register \
  -X POST -H 'Content-Type: application/json' \
  -d '{"email":"user@example.com"}'

Exchange the OTP with `POST /account/verify`, then tell the user to store the returned key as `SUPERIOR_TRADE_API_KEY` in their agent's environment or credential manager. Users can also create a key from account settings at https://account.superior.trade.

Verify it works before going further:

curl -sS https://api.superior.trade/wallet -H "x-api-key: $SUPERIOR_TRADE_API_KEY"

A `401`/`403` means the key is wrong or truncated — ask the user to re-copy the full key from the latest email. The email is verified by the first successful authenticated call, so this doubles as activation.

Never paste the key into chat, files, logs, or examples. If a user pastes theirs, treat it as a secret and do not repeat it back.

2. Trading account

Fetch `GET /wallet`. It returns the authenticated account's managed wallet, deposit details, balances, and available readiness information. The user does not need to expose a private key. Also read `GET /context/venues` and stop if the selected venue is not currently supported or ready.

If the current OpenAPI contract does not expose a required venue bootstrap, report that limitation. Do not invent a write operation for the wallet route.

3. Funds

The user funds the managed wallet with their own capital using the deposit details returned by `GET /wallet`. Confirm deposits with `GET /wallet/deposits`; do not treat that history route as a transfer action. Venue-specific bridges or wrapping flows may be used only when they appear in the current Unified OpenAPI contract.

If the user needs help getting funds into the platform wallet, use the `deposit-qr` skill for a payment QR or wallet URI, or `external-deposit` for a bridge from an external wallet.

Moving funds is a real money movement. State the amount, source, and destination and get an explicit yes before any supported transfer or withdrawal call.

4. Strategy

Ask what the user is trying to capture before writing any code. If they have a thesis but no structure, use the `trade-thesis` skill to turn it into bull/bear cases, invalidation criteria, and a sizing rationale.

Then match the idea to a template rather than writing from scratch — the templates carry backtest evidence and known failure modes:

| They want | Skill | | --- | --- | | Buy on a schedule, accumulate | `dca-weekly` | | Buy dips, sell rallies in a range | `grid-trading`, `mean-reversion`, `bollinger-reverter-4h` | | Ride a trend or breakout | `breakout`, `donchian-strong-regime` | | Get paid to hold a perp | `funding-rate-arbitrage`, `funding-squeeze`, `basis-arb` | | Fast in and out | `scalping` | | "What's moving right now?" | `intelligence` | | Prediction markets | `polymarket` plus its archetype skills |

Compose primitives onto whatever they pick: `regime-overlay` to gate a directional strategy, `dsl-exit-engine` for exits, `fees-optimizations` when turnover is high enough that costs decide the outcome.

5. Backtest

Never offer a live deploymen