godzilla.dev is an open-source C++/Python framework for self-hosted crypto funding rate arbitrage and ultra low-latency market making, with enterprise private deployment. Unlike cloud bot platforms, strategies, API keys, and execution all run on your own infrastructure. Python for strategy logic, C++ for the execution path. Install via pip (godzilla.dev on PyPI), extend with your own signals, deploy anywhere. In production use at institutional trading desks.
No reviews yetBe the first to leave a review for godzilla.dev
Maker
📌
Hi Product Hunt! I'm kx, builder of godzilla.dev.
I built this because I kept hitting the same wall: cloud-based trading bot platforms are great for getting started, but once real capital is involved, you don't want your API keys and strategy logic living on someone else's servers — and you can't fix latency you don't control.
godzilla.dev is fully self-hosted. The execution path is C++ for ultra low-latency market making; the strategy layer is Python so iteration stays fast. The main use cases are funding rate arbitrage on perpetuals and market making, and it's been running in production at a top-10 derivatives exchange for three years across liquidity provision and hedging.
It's open source — pip install godzilla.dev gets you started. Happy to answer anything about the architecture or the funding rate arb strategy design.
Report
Have you considered adding built-in support for funding rate forecasting models out of the box, maybe something like a simple LSTM or linear regression wrapper that plugs into the Python strategy layer? Would save a lot of boilerplate for anyone coming in fresh and wanting to test signal ideas quickly.
Report
Maker
@ensar33961 Interesting idea. My instinct is to keep forecasting models out of core — signal research styles vary too much and I don't want to bless one approach — but a clean interface where any predictor plugs into the Python strategy layer, plus a linear-regression reference implementation as a template, feels right. Boilerplate reduction without opinion lock-in. Would that cover what you had in mind?
Report
Congrats on the launch, running strategies on your own infra is a big deal for anyone worried about custody. One thing that would help adoption is a built-in backtest harness that replays historical funding rates and order book snapshots against the same C++ execution path, so you can validate signal changes without touching live capital. Would also make new strategy onboarding way less stressful.
Report
Maker
@turgay76925 Thanks! You and Serhat independently landed on the same request, which tells me the priority. Same execution path for backtest and live is exactly the right constraint — otherwise the backtest lies to you.
Have you considered adding built-in support for funding rate forecasting models out of the box, maybe something like a simple LSTM or linear regression wrapper that plugs into the Python strategy layer? Would save a lot of boilerplate for anyone coming in fresh and wanting to test signal ideas quickly.
@ensar33961 Interesting idea. My instinct is to keep forecasting models out of core — signal research styles vary too much and I don't want to bless one approach — but a clean interface where any predictor plugs into the Python strategy layer, plus a linear-regression reference implementation as a template, feels right. Boilerplate reduction without opinion lock-in. Would that cover what you had in mind?
Congrats on the launch, running strategies on your own infra is a big deal for anyone worried about custody. One thing that would help adoption is a built-in backtest harness that replays historical funding rates and order book snapshots against the same C++ execution path, so you can validate signal changes without touching live capital. Would also make new strategy onboarding way less stressful.
@turgay76925 Thanks! You and Serhat independently landed on the same request, which tells me the priority. Same execution path for backtest and live is exactly the right constraint — otherwise the backtest lies to you.