Open-source research engine · Rust

A deterministic mid-frequency research and paper-trading engine, with one event loop for backtest and live.

It replays recorded Hyperliquid prices, Kalshi strike ladders and Jev-scored Hacker News posts through the same code path that runs live on paper, with reasoning signals that can only brake and a risk layer that fails closed.

View source How it works

This page replays recorded data. Paper only: the engine has no order code and sent no orders.

What the engine does

Measured on the live feed and the recorded replay. Every number below is read from the exported run.

From data to a trade: the pipeline

Point-in-time data becomes features, features become two alpha signals, overlays can only cut them, the portfolio layer sizes and risk-checks the target, and execution is paper. The same code replays history, and every idea goes through the ledger before it counts.

1
Data
point-in-time
Hyperliquid trades and book tops · Kalshi hourly and Polymarket daily strike ladders · Hacker News posts · top-100 trader positions · funding rates. Every record is stamped with when it became knowable and merged into one time-ordered stream.
feed.rs kalshi.rs polymarket.rs pollers.rs event.rs
2
Features
1-minute bars and 60-minute volatility · implied P(close > spot) from each prediction-market ladder · post direction and relevance scored by a reasoning classifier · crowd long share · funding-rate ranks.
bars.rs prediction.rs text.rs positioning.rs
3
Signals
alpha
Momentum: return z-score, volatility-normalised: 5-minute (v1–v3) and 24-hour on hourly bars (v5, lower turnover). Carry: cross-sectional funding rank across 30 perps (v4). These are the only two things that can open a position.
strategy.rs carry.rs
4
Overlays
can only cut
Prediction-market agreement (Kalshi; in v2b Kalshi and Polymarket must both agree) · news caution · crowd positioning. Each is a multiplier in [0, 1]: it can shrink or veto a target, never add to or flip it.
engine.rs (gates)
5
Portfolio & risk
Target dollars per coin → target minus position = order intent. Every risk rule must approve (max position, max order, daily loss, stale data); a missing input or an error means no trade.
engine.rs risk.rs
6
Execution
paper
Simulated fill with fees and slippage, P&L, and every decision logged with the inputs that produced it. No order code exists in the repo.
execution.rs paper.rs
7
Feedback
research loop
Replay runs the same code on history. Each idea is written to a hash-chained ledger before it is tested, judged once on sealed data, then kept or killed.
experiment.rs ledger.rs verify.rs

No combination layer, by design: one alpha source per strategy keeps each test clean. Combining signals into a weighted composite under risk constraints would be the next layer.

Replay: price, decisions and the Kalshi implied band

Each marker is a decision the engine made on recorded data. Switch coin or strategy; hover for the inputs behind each decision.

price (1m close) Kalshi implied 25 to 75% at the hourly close implied median buy sell risk block
Hover the chart for the inputs behind each decision.

Scored posts

Real Hacker News stories and comments, scored by Jev. Each dot is placed when the score became available to the engine (publication, plus a 60 s poll delay, plus scoring time). Colour is the direction Jev assigned for the selected coin; size is how relevant Jev judged it. Hover for the text; click to zoom the chart there.

Baseline strategies: what the engine measured

These are deliberately simple baselines whose job is to exercise the engine end to end: one alpha signal, overlays that can only cut, real costs. Each was written down before its first run. The finding the engine surfaced is about turnover: 5-minute momentum trades the book about 300 times in three and a half days, so even its sign flipped (+$35 before costs) cannot pay $163 of costs. Overlays cut trading roughly in half (v2b) but do not pick better trades. On this sample nothing survives costs, and the engine reports that instead of tuning it away; the next test was a lower-turnover signal, pre-registered and run forward on paper. That is v5 (last three rows): the same momentum family at a 24-hour horizon on hourly bars, over the 208 days of hourly history the exchange keeps. It trades about 1/47th as much per day as v1 and made +$270 after costs, but lost $55 in the first half, so its pre-registered rule (positive on the full window and in both halves) killed it. It now runs forward on paper, live.

v1 momentum v2 reasoning-gated v2b Kalshi and Polymarket agree

Strategy v4: funding carry across Hyperliquid perps

Pre-registered, sealed out-of-sample

Hyperliquid perpetuals settle funding every hour: when the rate is positive, longs pay shorts that share of position value. v4 ranks a fixed universe of liquid perps by their trailing funding once a day, shorts the coins whose longs pay the most, buys the coins whose longs pay the least, and stays dollar-neutral. It earns funding every hour and pays fees and slippage on every rebalance. The risk is the price leg: crowded longs are often in coins that keep rising.

v4 in-sample (design window) v4 sealed out-of-sample buy and hold BTC perp, same notional

Research ledger: every idea, kept or killed

Every idea run through mft-engine experiment is appended to a hash-chained log. Each entry carries the hash of the one before it, so a result cannot be edited or dropped without breaking the chain. An idea is kept only if its second-half (holdout) PnL after costs is positive and beats the baseline (v5, which stands alone: only if it is positive on the full window and in both halves). Killed ideas stay on the record.

Crowd positioning on Hyperliquid, recorded live

What the 100 best recent traders on Hyperliquid's public leaderboard (by 30-day PnL, account value at least $100k) hold in each coin, read from public wallet state and aggregated: the share of their gross position value that is long. Hyperliquid only exposes current positions, so this exists only where it was recorded live; there is no backfill. Strategy v3 enters only when more than 60% of that value is on its side. No addresses are stored.

The Hyperliquid universe

Decisions and risk blocks

Every fill and every blocked order for the coin and strategy selected in the replay above, with its reason.

Measured latency

Timed on a live paper run against the Hyperliquid websocket feed.

Design rules

  1. One event type. Trades, book tops, 1-minute bars, Kalshi ladders, scored posts, top-wallet positioning and detected gaps all become one Rust enum, in time order.
  2. One code path. The same Engine::on_event runs in this replay and live on paper. Only the event source and the clock differ.
  3. The signal. v1 is preregistered 5-minute momentum on 1-minute bars (enter at 2 standard deviations, $1,000 per coin). v2 takes the same entries only when the Kalshi hourly ladder says the price is more likely to close above spot (for a long) or below it (for a short), and lets opposing Jev-scored posts shrink or veto a position. v2b also needs Polymarket's daily "above" ladder to lean the same way: pre-registered, run once, half the trades of v2, still a loss. v3 takes the same entries only when the top Hyperliquid wallets hold more than 60% of their position value on the same side. v5 is the same rules on 1-hour bars at a 24-hour horizon (enter at 1 standard deviation, exit on a sign change or after 72 hours), to cut turnover.
  4. Reasoning features can only brake. All gates are multipliers between 0 and 1, and a check blocks any order the gates made larger or flipped.
  5. Risk fails closed. Max position, max order, max daily loss, stale data. A rule that errors blocks the order. Every block is logged with its reason.
  6. Honest results. Both strategies lose money after costs on this sample. The sample is a few days, so none of this is evidence of an edge.