Erik Eremenko

I study markets by simulating them, and I build the software with a team of AI agents.

I co-founded PolySimulator, a paper-trading simulator for Polymarket with 7,000+ registered accounts, and designed its core architecture, trading engine and API. Since May 2026, AI coding agents that I orchestrate have written nearly all of its code. I'm a working student in applied AI at ING Deutschland and study Information Systems at TU Munich.

Email me Download CVGitHub LinkedIn

From particles to prediction markets

I got into simulation through my Computer Science courses at TUM. In the molecular simulation lab course, our team built a molecular dynamics simulator in C++: particles, forces, time steps, and a lot of testing and profiling to make sure the results could be trusted.

At the same time I was writing a seminar paper on online learning for financial time series, and at HackaTUM I took part in IMC's trading challenge. The two interests met there. A market can be simulated too, and the interesting part is what happens when one order meets the order book.

Prediction markets are an unusually clean place to study that. Every contract settles at 0 or 1, the prices read as probabilities, and on Polymarket the full order book is public. That is why we built PolySimulator: anyone can trade these markets with paper money against the real order book, and we can measure how their orders would have filled.

The part I enjoy most is the data: recording every change to the order books, replaying it, and checking the simulator against what really happened.

Building PolySimulator

PolySimulator lets traders and trading software practice on Polymarket's live markets with paper money. I designed its core architecture, trading engine and API. Most of the work is data engineering: keeping a live copy of every order book, filling orders against it correctly, and recording all of it.

Since November 2025, co-founder

PolySimulator

A paper-trading simulator, trading API and public Python SDK for Polymarket's prediction markets, with 7,000+ registered accounts. Built with my co-founder, Wladimir Kirjanovs, and run day to day with AI agents.

polysimulator.com Python SDK The team behind it

PolymarketThe public order-book feed goes two ways.
TradingIt is ingested into a live book cache. The matching engine fills orders against it; orders arrive through the Polymarket-compatible API and SDK, and balances live in a PostgreSQL ledger.
Recording8 recorder processes write hourly Parquet files to a datalake on Cloudflare R2: about 6 billion order-book rows a day, around 2 TB of new data a week.
ReplayThe archive feeds backtests and research through the simulation API.

simulated fills: 409,000+
traders with at least one fill: 3,800+
markets traded: 70,000+
order-book rows written a day: ~6 billion

Trading engine

Market orders walk the live order book level by level and fill at the volume-weighted price. The engine is complement-aware like Polymarket's own: a bid for No at 40¢ is an offer of Yes at 60¢.

A book older than two seconds (750 ms for live sports) is fetched again before anything fills against it. Takers pay Polymarket's fee formula with per-category rates; makers pay nothing.

Limit orders rest and are matched every second, with partial fills. Every balance change is an atomic ledger entry, a repeated order ID returns the original order instead of filling twice, and resolved markets pay $1 or $0 a share.

API and SDK

REST and WebSocket, with routes and channels that follow Polymarket's, so a bot written for Polymarket can point at PolySimulator instead. Orders never reach Polymarket.

API keys are stored hashed and rate-limited per key, in published tiers from 2 to 100 requests a second. It handled 3.3 million API requests in the 24 hours to 22 October 2026.

The Python SDK on PyPI follows the interface of Polymarket's own Python client. A partner API lets other platforms run simulated accounts for their users.

Order-book recorder

8 recorder processes keep about 1,900 WebSocket connections open to Polymarket's public market feed and record every book snapshot, price change and trade, around the clock since 31 July 2026.

Every hour each process writes Parquet files to Cloudflare R2 and reads each upload back to check it. Every frame is numbered, so a gap shows up instead of hiding, and a check compares the recorded layers every 20 minutes.

That is about 6 billion order-book rows a day, around 2 TB of new data a week. An hourly job sorts it by market for replay and backtests.

Backtests
Replay without look-ahead
Backtests replay the recorded order books. Each order can be delayed by a realistic latency (we suggest the 104 ms median we measured in production) and is priced against the book as it stood when it would have arrived. Each fill carries a look-ahead flag computed from the data.
October 2026
Moving production to London
Four days from decision to cutover. The website was in maintenance for 11 minutes 22 seconds; 7,590 user records and 7,867 login identities were copied with matching row counts and checksums, with reverse replication ready for a rollback.

Engine, API and recorder: PolySimulator's code, October 2026. Fills, traders and markets: production database, 22 October 2026. Recorder volume: the recorders' own logs, average of 15 to 21 October 2026. Move figures: production records, 21 October 2026.

How I work

PolySimulator is built and run by a small team of AI agents. I set the direction and design the controls around them. Production releases need my co-founder or me.

MeSet the direction and approve production releases.
Agent sessionsClaude Code and Codex in fixed roles: operations, business and finance, research, websites. They message each other directly.
Shared memoryVersioned notes and lessons, synced across machines every 20 minutes.
Pull request, AI review, stagingAn agent writes the change, most code changes get an AI review, and agents merge into staging.
ProductionReleases need one of us. Alerts go back to the operations session, and I get briefings by email.

Fixed roles
Each agent session owns one area, such as operations, business or a website, and hands work to the others instead of redoing it.
A shared memory
Every session starts from the same versioned notes. When an agent gets something wrong, it writes down what happened and, where it can, turns that into an automatic check.
Review before merging
Most code changes get an AI review before they merge into staging. Production releases need one of us; during an incident, agents act in production under a standing permission from us.
Measured, not assumed
In a one-week sample of 553 merged changes, one in four needed a follow-up fix within 48 hours. Review time, not writing code, became the bottleneck.

Sources: our pull-request records. Review coverage: the 30 days to 16 October 2026. Follow-up fixes: 553 pull requests merged between 29 August and 4 September 2026. More on bavariance.com

Software we built for the agents

Coding agents out of the box forget what they learned, get in each other's way and can see whatever is in their terminal. The tooling around them is our own, about 70 scripts and 11,000 lines, and several pieces exist because something went wrong.

Shared memory: One memory store per project, kept in git and synced between two machines every 20 minutes. Its index is generated to stay within the agents' context limit, after an index that had grown too large was silently cut off.
Assignment queue: Every request becomes a file with its status kept in place. Built after requests were lost when a session's context was compacted.
Prior-work check: Before starting, a session checks whether the work already exists. Built after two sessions rebuilt the same thing on the same day.
Session registry: Stable names, roles and message receipts for every session, plus watchers that keep running when a session ends.
Secret guard: Rewrites commands so credentials are masked in their output, blocks reads of key files, and sweeps the transcripts every night.
Review gate: Runs a Codex review on a pull request and posts it with the model, commit and transcript hash. It refuses to post without the reviewer's final message, after a full disk once made it report zero findings.
Alerts and mail: Grafana alerts land in the assignment queue every five minutes, and every email the agents send me is logged word for word.

Size: the agent tooling repository, counted on 22 October 2026.

Eleven months in the repository

The repository started on 17 November 2025. Until March 2026 we committed straight to the main branch (803 commits against 6 merged pull requests), so the commits show those months best. Since May 2026, agents have written nearly all of the code.

7,448commits under my name, by me and, since May 2026, mostly by my agents; 773 of them before March

Monthly totals as a table

Month	My commits
November 2025	8
December 2025	176
January 2026	191
February 2026	398
March 2026	277
April 2026	196
May 2026	1,681
June 2026	1,159
July 2026	73
August 2026	979
September 2026	1,602
October 2026	708

Source: git history of PolySimulator's main repository, commits without merges and without bot commits, by author and UTC date; fetched 22 October 2026. Period: 17 Nov 2025 to 21 Oct 2026.

Studies and hackathons

October 2025 to February 2026, TUM lab course
Molecular dynamics simulator
A team-built simulator in C++ with the Lennard-Jones potential and the linked-cell algorithm, parallelized with OpenMP and checked with GoogleTest, sanitizers and Valgrind.
Code on GitHub
Winter semester 2025/26, TUM seminar
Online learning for time-series forecasting
A seminar paper with Sam Muller comparing online SNARIMAX, a ternary classifier and batch ARIMA on S&P 500 data, with the theory behind them: regret minimization, the online Newton step, catastrophic forgetting.
Paper (PDF)Code
November 2025, HackaTUM
IMC Trading Challenge
A trading bot with exchange API integration, automated order management and an ensemble model for price prediction, built as team Bavariance.
Devpost Code
March 2025, TUM Venture Labs
Robo.Innovate hackathon
On the BMW team: an on-premise server setup, and training and fine-tuning of robot policies by imitation learning with LeRobot.
Project page

Experience and education

Experience

Nov 2025 – now
Co-founderPolySimulator, Munich
Product, architecture and the agent system that builds and runs it.
Jul – Dec 2026
Working Student, AI Workplace AssistanceING Deutschland, COO Digital Office
Applied AI and automation for teams across the bank, including internal software built with AI coding agents.

Education

Since Oct 2026
B.Sc. Information SystemsTechnical University of Munich (Wirtschaftsinformatik)
Oct 2023 – Oct 2026
B.Sc. Computer ScienceTechnical University of Munich (Informatik), six semesters
2015 – 2023
Abitur, final grade 1.2Königin-Luise-Gymnasium Erfurt
2022 – 2023
Data Science Bootcamp; Applied Edge AIHasso Plattner Institute, certificates

Skills

AI engineering: Claude Code and Codex CLI, multi-agent orchestration, agent memory and context design, review gates, MCP servers
Software: Python (FastAPI), TypeScript, React and Next.js, SQL and PostgreSQL, Redis, WebSockets, C++ with OpenMP; also C, Java and OCaml
Operations: Docker, GitHub Actions, Cloudflare (R2, Workers), AWS, Grafana, Prometheus and Loki, database migrations, incident analysis
Data and ML: Real-time capture pipelines, NumPy, pandas, Matplotlib, online learning, imitation learning with LeRobot
Languages: German and Russian (native), English (C1), French (DELF B1)

Contact

Email is the quickest way to reach me.

erik@eremenko.io

CV (English, PDF)Lebenslauf (Deutsch, PDF)LinkedIn GitHub Kaggle

Erik Eremenko, Munich, 2026

Erik Eremenko

From particles to prediction markets

Building PolySimulator

PolySimulator

Trading engine

API and SDK

Order-book recorder

Replay without look-ahead

Moving production to London

How I work

Fixed roles

A shared memory

Review before merging

Measured, not assumed

Software we built for the agents

Eleven months in the repository

Studies and hackathons

Molecular dynamics simulator

Online learning for time-series forecasting

IMC Trading Challenge

Robo.Innovate hackathon

Experience and education

Experience

Education

Skills

Contact