Hyper Alpha Arena: letting language models trade perpetuals on two exchanges

A fork of the Alpha Arena idea, pointed at two perpetual exchanges

The README describes Hyper Alpha Arena as a platform where large language models autonomously execute cryptocurrency trading strategies, and it credits nof1's Alpha Arena as the inspiration. It names GPT-5, Claude and Deepseek as models that can be pointed at it, and states that they make decisions from real-time market data and execute trades automatically. The official site is akooi.com, and the documentation lives at akooi.com/docs with a Chinese version at a parallel path. The repository itself is Apache-2.0 licensed and ships a NOTICE file alongside the LICENSE.

The supported venues are specific. Hyperliquid testnet is offered as risk-free paper trading with real market mechanics, free test funds and no KYC. Hyperliquid mainnet is the decentralised perpetual exchange with margin from 1 to 50x and wallet-based authentication. Binance Futures covers USDT-M perpetuals authenticated by API key.

Two design decisions follow from that split. First, the testnet is a first-class target rather than a simulation bolted on, which means a strategy can be exercised against live order book behaviour before real funds are involved. Second, the two mainnet venues authenticate differently: Hyperliquid needs a wallet signature, Binance needs an API key. Any script that assumes one model will break on the other.

The README offers a table of who the project is for, which is worth reading because it is unusually candid about the audience split: non-technical traders who configure through conversation, quantitative researchers who want the factor library and expression engine, Hyperliquid and Binance users, and people who simply want to watch different models compete.

Two execution modes, and the difference is who makes the decision

The platform separates execution into an AI Trader and a Program Trader, and the distinction is about decision authority rather than about model quality.

The AI Trader takes a strategy described in natural language and lets the model analyse and decide in real time. Its stated use case is strategies that need market understanding, which the README lists as news, sentiment and complex judgement. The practical implication is that this mode's behaviour is only as predictable as the model behind it, and the project is candid that you can run the same strategy on different models and watch them diverge.

The Program Trader takes the opposite approach. You define rules in Python, backtest them on historical data, and the README describes execution as millisecond-level. Its stated use case is fixed-rule strategies, specifically technical indicators and price levels, which is where a written rule is both faster and more auditable than a prompt.

That split is the sensible design for this problem. Anything a language model is genuinely better at, such as reading a headline and judging whether it matters, belongs in the AI Trader. Anything where being slightly slower and completely repeatable is worth more belongs in Program Trader. Running a technical indicator strategy through a model because it is available is how automation projects end up unpredictable.

86 factors scored by IC, ICIR and decay half-life

The factor library is described as AI that builds its own alpha, and the mechanics are more interesting than the marketing phrase suggests. There are 86 built-in factors spread across Momentum, Trend, Volatility, Volume and Microstructure categories. Each one is scored with what the README calls institutional-grade metrics: information coefficient, ICIR, win rate and decay half-life.

Those four numbers answer questions that a factor library usually leaves open. IC measures how strongly a factor's ranking correlates with what happened next, which tells you whether it carries signal at all. ICIR is that correlation divided by its variability, which tells you whether the signal is stable enough to trade. Decay half-life tells you how quickly the edge goes stale, which is the number that decides whether you retrain on a schedule or leave it alone.

On top of the built-ins there is a custom expression engine with 69 functions, so a factor can be composed rather than only selected. The README describes three ways to consume a factor: as a signal trigger, as data injected into an AI Trader prompt, or programmatically from Program Trader code. Having all three matters, because it lets you keep the deterministic parts deterministic.

There is also an AI-driven factor mining loop. Hyper AI is described as searching the web for recent quantitative research, extracting factor ideas from academic papers, and then validating them against live data before building strategies around the ones that hold up. An LLM proposing a candidate and a statistical test rejecting it is a better division of labour than either step alone, though the README does not say how many candidates are typically tried or what acceptance threshold is applied.

Market flow triggers that only fire when structure shifts

The second half of the signal layer is market flow monitoring, which the README frames as a way to avoid watching charts around the clock. It monitors order flow imbalance, surges in open interest, and extremes in funding rates, and it activates trading only when one of those indicates the market structure has changed.

That is a different philosophy from the AI Trader's. Instead of asking a model to form an opinion every time a tick arrives, the flow monitor reduces the decision to a trigger, and the trigger fires on a measurable change in positioning. Any factor from the library can also serve as a trigger condition, and the README says the distributions are real percentiles from P5 to P95, which is what you need to set a threshold rather than guess one.

Percentile-based thresholds are the detail that makes this usable. Open interest or funding rate do not have a natural absolute level, so a fixed number means something different on Monday than it does on the day of a squeeze. Expressing the trigger in percentile terms ties the threshold to the recent distribution of that factor and makes it portable across symbols.

The fourth feature area is trade attribution analytics, which breaks performance down by symbol, trigger type, time period and factor. The README describes a By Factor dimension for attributing results. For an automated system, that is the difference between a bot that lost money and a bot that lost money for one identifiable reason, and it is the feature most likely to change how you configure the rest.

Docker deployment with two PostgreSQL databases and a generated key

Deployment is the part where this repository is most concrete, and the root tree shows what you get: a `Dockerfile`, `docker-compose.yml`, an `init-db.sh`, `.env.example`, `backend/`, `frontend/`, a pnpm workspace with `pnpm-lock.yaml` and `pnpm-workspace.yaml`, and a `screenshots/` directory.

The compose file defines two services. PostgreSQL runs `postgres:14` in a container named hyper-arena-postgres with its data on a named volume, `init-db.sh` mounted read-only into the container entrypoint directory, and a healthcheck running `pg_isready` every ten seconds. Two databases are configured, one for the application and one for snapshots:

DATABASE_URL: postgresql://alpha_user:alpha_pass@postgres:5432/alpha_arena
SNAPSHOT_DATABASE_URL: postgresql://alpha_user:alpha_pass@postgres:5432/alpha_snapshots

The app service builds from the root Dockerfile and passes host proxy variables in as build args, which matters in regions where a package registry is only reachable through a proxy. It then explicitly clears every proxy variable inside the container, including `NO_PROXY`, so that outbound exchange traffic is not silently routed through a build-time proxy.

The Dockerfile is a two-stage build. A `node:18-alpine` stage installs pnpm and builds the frontend, a `python:3.12-slim` stage installs curl, copies `backend/`, installs the Python package in editable mode, and copies the built frontend into the backend's static directory. The backend install step is one line:

WORKDIR /app/backend
RUN pip install --no-cache-dir -e .

The start command is where a security decision sits. Because Hyperliquid authenticates with a wallet private key, the container generates a Fernet key on first run, writes it to `/app/data/.encryption_key`, exports it as `HYPERLIQUID_ENCRYPTION_KEY`, and only then runs database initialisation and migration steps before starting uvicorn on port 8802. The key persists in the data directory, so a volume you back up contains both your database and the key that decrypts your credentials.

Defaults in .env.example do not match the README's headline numbers

The environment template is where the concrete risk settings live, and it is worth reading against the README's marketing because the two do not agree.

The README advertises Hyperliquid mainnet with margin from 1 to 50x. The template ships these defaults:

HYPERLIQUID_MAX_LEVERAGE=10
HYPERLIQUID_MIN_ORDER_VALUE=10.0
HYPERLIQUID_MAX_POSITION_VALUE_PER_ORDER=1000.0

A 10x default against a 50x headline figure, and a 1000 unit cap per order, tells you something the feature list does not: the shipped configuration is meant to be conservative and meant to be raised deliberately per account. The template's own comment says Hyperliquid defaults are optional and can be configured per account in the interface.

The compose file adds three more values that describe the commercial relationship rather than the technical one. `HYPERLIQUID_BUILDER_ADDRESS` points at a fixed address and `HYPERLIQUID_BUILDER_FEE` is set to 30, which is a builder fee charged on Hyperliquid volume, and `BINANCE_BROKER_ID` identifies the broker on Binance. Anyone deploying this should decide for themselves whether they want their volume routed through a builder referral, and if so, that is revenue for the project operator. It is disclosed in a compose file, which is the right place for it, but it is the kind of setting that is easy to accept without reading.

The optional AI keys are listed as commented examples for OpenAI, Anthropic and Deepseek, each of which can also be set per account in the interface. One more detail deserves attention: the Hyper Insight integration is login-based and reuses a Casdoor account session already synced from the platform after sign-in, so its base URL is the only value usually needed. A single sign-on session shared between a trading platform and an analytics service is a trust boundary worth naming before you connect them.

A development script that admits the backend build step does not exist

The root `package.json` is a small pnpm workspace with one dev dependency, `concurrently`, and a pinned package manager at pnpm 8.15.5. Most of its scripts are orchestration: `dev` runs the backend and frontend together, `install:all` installs the frontend workspace and syncs the Python environment with uv, and `build` chains a frontend build into a backend build.

That last pair is where the repository contradicts its own description. The backend build script is a single command that echoes `Backend build step not yet implemented`. The README calls the platform production-ready, and the Dockerfile and compose file are thorough enough to make that plausible for the Docker path, but the local build path has no backend build step to run. Anyone expecting `pnpm run build` to produce a deployable backend artifact will get a message instead of one.

The development port is also worth noting. `dev:backend` syncs the Python environment with uv and runs uvicorn with reload on port 5611 bound to 0.0.0.0, while the Dockerfile and compose configuration serve on port 8802. Two different ports for development and deployment is normal, and it is the kind of detail that catches someone whose firewall rules were written for the wrong one.

Maintenance status is straightforward to state: the repository is not archived, its last push was on 2026-05-13, and it publishes no GitHub releases, so there is no version history to check against the container you are running.

Editorial conclusion

The factor library and the trigger design are the parts of this project worth borrowing conceptually, because scoring a signal by IC, ICIR and decay half-life before letting it fire is a discipline most retail automation skips. The trading itself is where caution belongs: this is real capital against perpetual futures contracts, the mainnet path needs a wallet with no withdrawal limits configured, and the README's own caution about backup phrases applies before any deployment. Two repository details deserve a look before you start. The compose file binds PostgreSQL and the app to 127.0.0.1 only, so a remote deployment needs a reverse proxy you add yourself, and the default margin setting in `.env.example` is 10 while the README advertises up to 50x on Hyperliquid mainnet. Point it at Hyperliquid testnet first, where the README says no KYC and free test funds are involved.

Frequently asked questions

Official sources

1. HammerGPT/Hyper-Alpha-Arena on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README