Skip to main content

​
Data layer

Market data is held in Polars frames. Bundles are stored as Delta Lake tables (plain Parquet before 2.10.3), and the asset database is SQLite under ~/.ziplime by default. Everything a strategy reads from data.current and data.history is a polars.DataFrame.

​
Async runtime

The engine is asyncio end to end. Asset lookups, data reads and order calls are coroutines, which is why a strategy awaits them. The same runtime drives backtests and live trading, so the strategy code doesn’t change between the two.
A missing await does not raise. The call returns a coroutine that never runs, and the strategy silently places no orders — which looks like a strategy that found no signal.

​
Event-driven and vectorized

The vectorized kernel is Ziplime’s own. Install ziplime[numba] to compile its inner loop; without it the same loop runs interpreted. A sweep’s winner is replayed through the event-driven ledger. See Vectorized Signals.

​
Fill model

  • An order fills on the bar after the decision in the CLI and the MCP server. run_simulation takes same_bar_execution explicitly — see Orders.
  • The fill price is one bar field — close by default, or open, high, low.
  • No fill happens on a bar with no volume, and fills are capped at a share of the bar’s volume by the slippage model.
  • Commission reaches the cost basis and realised P&L, not only cash.

​
Venues and calendars

The simulation runs on one clock calendar, but each listing is judged by its own venue’s trading hours (since 2.11.0). See Venues & Calendars.

​
Parameters

Strategy parameters can live in a typed config class and a JSON file, separate from the strategy logic, so they can be tuned without touching the code. See Algorithm File.

​
No restriction on strategy type

Portfolio strategies, pairs, momentum, futures rolls, option structures — all run on the same engine and the same ledger.