Flint

Flint is an autonomous ES futures trading terminal built on a decade of S&P 500 data. Toaster v1.0 already backtests profitably. Get early access to trade like a quant and compound while you sleep.

Comment 1

Flint is an autonomous ES futures trading terminal built by a team that blends institutional ML experience, software engineering, and active discretionary trading.

Inspiration

Our team of 4 spans two finance heads, two computer science students, one of which is an incoming medical student and the other a profitable ES day trader. We asked a simple question: if large institutions rely on machine learning to trade the S&P 500, why can’t a small, focused team build an equivalent edge for individual traders?

We chose the name Flint because flint and steel turn potential energy into a spark. The product is designed to do the same: convert raw ES order flow and price history into actionable, statistically grounded trade signals. The companion model name, Toaster, emerged from an internal joke and stuck because it fits the metaphor: Flint provides the spark; Toaster “cooks” structured signals out of noisy data.

Because the hackathon included a Solana track, we decided to make every signal auditable. Flint writes entry and exit intents on-chain, providing a verifiable record that the system produced specific signals at specific times, rather than curve-fitting ex post.

What Flint does

Flint is a desktop trading terminal focused on the E-mini S&P 500 (ES). The core idea is simple:

  • Ingest decade-scale ES data
  • Forecast near-term price dynamics with a sequence model
  • Translate those forecasts into discrete trade decisions
  • Execute those decisions in a controlled, repeatable way

Toaster v1.0 is an LSTM-based model trained on one-minute ES data from January 2016 through January 2026. Even with approximately thirty minutes of training, Toaster v1.0 achieves profitable backtests over the full ten-year sample, which includes multiple regimes: low-volatility bull markets, the COVID crash and recovery, and the post-2020 rate cycle.

In practice, Flint can be used in two modes:

  • Autonomous mode: the agent takes simulated trades on ES contracts based on its forecasts and an RL decision layer, producing PnL and risk metrics with no human intervention.
  • Signals mode: discretionary traders use Flint’s entries, exits, and confidence scores as confirmation, overlaying the signals on their own charting and ICT-style context.

Because the hackathon runs over a weekend, the live ES market is closed. Instead of approximating live trading with stale data, we built a rigorous backtest and replay environment:

  • Price history is streamed into the environment bar by bar.
  • At each decision point the agent only sees information available at that time, plus its forecast of the next hour.
  • The environment evaluates decisions against the true future path, exactly as if orders had been placed live.

This design makes it straightforward to switch to actual live trading later by swapping the historical data feed for a broker or data provider API.

How we built it

Flint has three primary components:

  1. Marketing site
  • Built with TypeScript, React, and Tailwind CSS, with GSAP used sparingly for micro-interactions.
  • The goal is clarity rather than spectacle: a concise explanation of Flint’s edge, a product screenshot, and a single call to action to download the terminal.
  1. Desktop terminal
  • Implemented as a React + TypeScript application running inside Electron to provide a first-class desktop experience.
  • Uses TradingView’s open-source lightweight-charts library to render high-performance candlestick charts and overlays.
  • The UI follows a “professional desk” layout: left sidebar for modes, top bar for instrument/timeframe, central chart and order ticket, right rail for live signals and the Strategy Lab.
  1. Machine learning and simulation stack
  • Historical ES futures data is sourced from Databento at one-minute resolution for the last ten years.
  • A preprocessing pipeline aggregates raw trade data into OHLCV candles, then up-samples to higher timeframes (5m, 15m, 30m, 1h, 4h, daily, weekly) as needed.
  • A seq2seq LSTM forecaster predicts the next hour of ES prices from historical windows.
  • On top of this, an RL-style decision agent observes:
    • the recent price path
    • the model’s next-hour forecast
    • its current position and PnL
      and chooses among {buy, sell, hold, flatten} within a one-hour trading horizon.
  • A Python simulation environment handles bar-by-bar stepping, position management, and PnL calculation, exposing a simple API that the Electron frontend can call.

Challenges we ran into

Machine learning and environment design

The main learning challenge was designing an agent that actually trades, rather than gaming the reward structure.

  • Early training runs discovered a degenerate strategy: the agent would hold flat throughout the episode and achieve zero PnL, which the reward function treated as acceptable.
  • Introducing a uniform penalty on holding encouraged trades but also biased the agent toward low-quality early entries.
  • We iterated toward a shaped reward that lightly penalizes prolonged inactivity, rewards realized PnL, and does not punish waiting for a high-conviction setup late in the episode.

We also had to engineer a clean forecasting API:

  • For any timestamp T between January 2016 and January 2026, the system must:
    • build the appropriate context window
    • produce a one-hour forecast from T to T + 60 minutes
    • export both the forecast and the realized path to CSV for analysis and visualization
  • This required modularising dataset construction and inference into dedicated scripts rather than leaving them in notebooks, so the trading environment and frontend could request forecasts on demand.

Finally, we investigated artifacts in the LSTM forecasts, such as initial dips at the start of some prediction windows, and tuned the preprocessing and model architecture to reduce those pathologies.

Frontend architecture and UX

On the UI side, we had to move from “AI-generated template” to something that feels like a real brokerage application:

  • The initial Electron skeleton had too many competing modules, inconsistent colors, and unclear navigation.
  • We consolidated the layout into a small set of panels and defined a strict design system (Flint palette, typography, spacing, reusable panel and button components).
  • Integrating lightweight-charts required careful attention to data shape, timestamps, and container sizing before any candles appeared correctly on screen.
  • Converting raw CME ES data into 1-minute candles, and then into higher-timeframe candles, required precise handling of timestamps and session logic.

We also ran into the usual engineering friction: version mismatches across machines, dependency conflicts, and the complexity of coordinating React, Electron, FastAPI, and the Python ML stack within a 24-hour window.

Accomplishments we are proud of

  • Profitable model in 30 minutes of training: Toaster v1.0 achieves profitable backtests over a decade of ES data after a short training run, indicating that even a relatively simple LSTM architecture can extract usable structure from the ES time series.
  • End-to-end system in 24 hours: In a single hackathon we shipped a marketing site, a desktop terminal, a simulation environment, and a working ML pipeline tied to real market data, rather than a static prototype.
  • Genuine trading edge: Flint is not a cosmetic UI on top of random signals; it integrates quantitative forecasting with disciplined execution logic to create a reproducible, testable trading process.
  • Effective teamwork: We structured the group intentionally: three engineers focused on frontend and integration, two contributed to backend and data plumbing, and one focused on ML. Regular check-ins every one to two hours kept everyone unblocked and aligned on priorities.

What we learned

From a technical perspective, we learned how important it is to:

  • Define a clean interface between forecasting, decision-making, and execution.
  • Design reward structures that avoid trivial strategies and reflect realistic trading objectives.
  • Treat design tokens, layout primitives, and component libraries as first-class artifacts so the UI stays coherent under time pressure.

From a process perspective, we confirmed that:

  • A small team with shared conviction and clear direction can ship a surprisingly ambitious system in 24 hours.
  • Frequent, short check-ins and explicit task ownership reduce downtime and keep energy high.
  • Coordinating sleep and work in planned blocks is essential for maintaining decision quality during a long hack.

What is next for Flint

Flint is structured to extend beyond the hackathon:

  • Stronger models: Toaster v1.0 is a baseline. We can add richer architectures (transformers, regime-switching models, volatility forecasting) and more features (order book signals, session-aware context, macro variables) to improve risk-adjusted returns.
  • Live trading: The simulation environment already mirrors live conditions. Connecting to a brokerage API such as Interactive Brokers or a CME-connected FCM is a straightforward next step, initially on a demo account and later on funded capital.
  • Robust infrastructure: With CI, monitoring, and risk controls, Flint can evolve into a production-grade trading system rather than a research prototype.
  • Selective distribution: Long term, Flint can be offered as a managed signals product or fully automated trading service for qualified clients who want systematic ES exposure without building an in-house quant stack.

The S&P 500 is not going away, and neither is automation. Flint aims to sit at that intersection: a focused, ML-driven ES terminal that gives individual traders access to the sort of quantitative edge that has historically been reserved for larger institutions.

Built With

Share this project:

Updates