Choose the integration boundary that matches the desk’s latency budget,
existing implementation, and desired runtime ownership.
Native Chronix Rust modules
| Best when | The strategy belongs directly inside the live trading backend and needs the tightest integration path. |
|---|
| Latency boundary | None. There is no FFI boundary, extra serialization layer, or bridge overhead between strategy logic and the execution path. |
|---|
| Runtime ownership | Chronix hosts the strategy with the live trading runtime. |
|---|
FFI modules callable from Rust
| Best when | The desk wants to retain an existing implementation while connecting it to Chronix through a high-speed boundary. |
|---|
| Latency boundary | A native interoperability boundary, suitable for C, C++, Python native bindings, Go, Java/JVM through JNI, and .NET/C# through native interop. |
|---|
| Runtime ownership | The desk retains the implementation; Chronix provides the integration boundary. |
|---|
External strategy engines through Chronix APIs
| Best when | The desk wants to run its own strategy engine separately from the trading runtime. |
|---|
| Latency boundary | The strategy consumes Chronix market data and sends order intent to the trading adapter through Chronix APIs. |
|---|
| Runtime ownership | The external engine retains execution of its strategy while Chronix supplies order, fill, position, account-state, and exposure/risk interfaces. |
|---|
