Skip to content

See below for the architecture and core processes of godzilla.dev, an open-source C++/Python infrastructure for self-hosted crypto funding rate arbitrage and market making with an ultra low-latency design.

Architecture Overview

welcome screen

Core Processes

master

The first process to start, responsible for managing the creation of shared memory pages and other processes.

ledger

A process responsible for message passing, including quotes, orders, transactions, etc.

md (Market Data)

  • A process responsible for collecting market data.

  • Developed as an extension, can be in Python or C++.

  • Implements callback methods for subscription messages.

  • Calls the exchange's market data interface to obtain data and writes it to shared memory.

  • Multiple MDs are distinguished by name.

td (Trade Data)

  • A process responsible for handling trades.

  • Developed as an extension, can be in Python or C++.

  • Implements callback methods for order messages.

  • Uses the exchange's trading interface to obtain order statuses and writes them to shared memory.

  • Multiple TDs are distinguished by name.

strategy

  • The strategy process is responsible for implementing the complete trading strategy logic.

  • Can be in Python or C++, with C++ requiring compilation into an executable.

  • By implementing callback methods like pre_start, on_quote, on_order, on_trade, and pre_stop, it retrieves data from MD, places orders through TD, and gets order statuses.

  • The current platform still lacks saving/querying of intermediate states, requiring the strategy itself to maintain them.

  • Strategies can choose to subscribe to multiple quotes from different MDs, as well as place orders and obtain transaction statuses from multiple TDs.

Measured performance

The md → strategy → td path described above was measured end-to-end on a single host: a run-level median of 121–135 µs and a p99 of 435–662 µs, from a market-data event entering the journal to a local order report being generated. Because the path is journal-based, the timestamps are extracted from the framework's own persistent event records after the run rather than from instrumentation sitting inside the measured interval.

The methodology, scripts, raw per-event records, and the exact commit are published, along with what the measurement deliberately excludes — network transport, exchange gateways, matching, acknowledgements and fills. See the latency benchmark.