Project 03 / Market research · Execution systems
Market Microstructure & Arbitrage Research Lab
Independent research
Three investigations into small-capital trading economics. I built collection, replay, and verification tools, then tested whether apparent opportunities survived execution costs, latency, and funding constraints. A repeatable income opportunity was not established.
01 / overview
Could a small operation find a repeatable edge?
The ambition was to build a trading operation that could produce meaningful, repeatable income with limited capital.
I investigated cross-venue event-contract arbitrage, Kalshi market incentives, and CoW Protocol quotation economics. These became three related labs: mode-a-arbitrage, kalshi-edge-lab, and cow-solver-lab. The first contained the most substantial execution tooling; the others tested adjacent opportunities.
The work did not establish a repeatable, executable income opportunity. It did produce a collection of research tools and a clearer account of where apparent opportunities failed under practical constraints.
Independent research and software development: data acquisition, settlement checks, historical replay, paper-execution modeling, and economic feasibility analysis. No real orders were placed.
02 / approach
Make the assumptions part of the system.
In mode-a-arbitrage, historical replay and live paper processing share a strategy and order-state engine, with separate input adapters. This makes it possible to compare decisions on identical normalized inputs while keeping the limitations of historical data visible.
- 01 · CollectPreserve the inputs
Record market observations and retain source evidence for later inspection.
- 02 · VerifyCheck the contract
Review settlement compatibility before treating two legs as an exact hedge.
- 03 · ReplayModel execution
Track modeled latency, partial baskets, transaction costs, and funded capital.
- 04 · DecideTest the economics
Compare scenarios and identify assumptions that determine whether to continue.
The Kalshi lab records bounded sessions and replays them through the same engine used during collection. Parity checks detect changed events, altered source versions, missing recording footers, and final-state discrepancies. These checks establish reproducibility of the simulation, not profitability.
03 / experiments
Three investigations, different stopping points.
01 / mode-a-arbitrage
Cross-venue event contracts
Compared settlement-compatible ForecastEx and CME contracts. The tooling includes historical and live data adapters, paper execution, partial-basket handling, capital recycling, and latency sensitivity analysis.
Corrected replays exposed a large gap between idealized opportunity and modeled capture. Slower execution and incomplete hedges weakened the economics at the intended account size.
02 / kalshi-edge-lab
Market structure and incentives
Built public-data collection, deterministic replay, execution scenarios, and economic screens. A bounded follow-up recording compared three selected markets.
All three were low priority within that sample. The result did not establish a profitable strategy or justify a live test; a short recording also cannot rule out opportunities across the venue.
03 / cow-solver-lab
Quotation economics before a solver
Archived public evidence and examined competition, reward capacity, operating costs, and access requirements for selected wrapped-native/stablecoin order segments on Ethereum, Base, and BNB.
The sampled Base and BNB segments failed the initial economic screen. Ethereum remained blocked by unresolved eligibility, accounting, and access evidence. No solver prototype was built.
04 / results
The income thesis did not clear the evidence bar.
The cross-venue project was shelved when modeled capture and latency sensitivity made the opportunity unattractive for the intended small-capital setup. The other investigations did not provide enough evidence to justify live trading or solver implementation.
The concrete engineering result was reusable collection and replay tooling, explicit execution assumptions, and reproducible analyses. The business result was a decision to stop without claiming that the research had produced an operating trading system.
05 / lessons
The most useful result was knowing where to stop.
- A price discrepancy is only the beginning. Settlement compatibility, fill uncertainty, fees, latency, and funding determine whether it can be captured.
- Reproducible simulations still depend on assumptions. Replay parity helps diagnose the software; it cannot turn inferred fills into real trades.
- Feasibility can come before implementation. The CoW screen identified unresolved economics before investing in a solver.
- A stopping decision needs evidence too. Preserving the inputs, limitations, and reasons for stopping makes the work useful if the conditions change.
I would revisit these ideas with better execution evidence or materially different access and cost conditions. More infrastructure alone would not resolve the gaps identified here.
06 / Resources
What remains from the research.
The labs retain their source code, experiment configurations, replay checks, and decision reports. This article summarizes the October 2026 findings; the underlying repositories and raw recordings are not published here.
Research & development
Arjen Singh · Independent project, October 2026
Tools & methods
Python · Market-data APIs · Event-driven simulation · Deterministic replay · Economic modeling
Next story / 01