Roq Trading Solutions is a suite of software solutions allowing you to implement and deploy your own bespoke algorithmic trading system

  • GitHub (open source)

    • APIs

    • Samples

    • Deployment (Ansible, Vagrant)

    • Tools and utilities

  • Conda (binaries)

    • Gateways

    • Simulators

    • Adapters (ClickHouse, Redis)


The core principles guiding our product offering

  • Deliver software solutions allowing algorithmic traders to own and control the entire software stack: from research and simulation to live trading.

  • Increase transparancy by offering open sourced solutions. Avoid lock-ins for licensed solutions.

  • Promote cost effectiveness by reduced complexity and by offering free tools for testing, deployment and monitoring.

  • The software must never get in the way of live trading performance: achieve by always designing for stable and low latency. Performance should be close to best in class.


Support all major crypto exchanges: cryptocurrency and derivatives.


Traditional exchanges should be supported, but not currently prioritized.


Full Control

Everything is designed so one person can deploy and manage the entire software stack.

  • A single gateway can easily be configured to run from the command line.

  • Ansible playbook can help you install and configure a server deployment.

  • Full automation is possible using e.g. systemd scripts.

Cost Effective

You do not need a team to implement and manage the deployment.

  • Install scripts are available from GitHub and free to use.

  • Built-in support for free third-party services: Prometheus, Redis, ClickHouse, …

  • A very competetive license model without lock-ins.


You choose to deploy only the components you need.

  • Gateways are designed like microservices, each with a singular purpose.

  • There is built-in support for your own choice of monitoring solution, time-series database, publish/subscribe transport, etc.

  • Open APIs allowing anyone to implement additional services.


All critical software components have been designed for best possible performance.

  • Internal latency is close to best in class (low single digit microseconds).

  • Uncertainties should only arise from external factors: how close your server is to the exchange, quality of the network, what other processes are executing on your server, etc.


Performance will not suffer if you choose to connect to more markets and/or deploy more trading strategies.

  • Messages can be published once by the gateway using a shared memory broadcast design thereby fully leveraging cache coherency (hardware).

  • A gateway can allow different trading strategies to access distinct symbols thereby multiplexing (and re-using) a single exchange login (connection).

Event Logging

The gateways can automatically persist all events to a storage media.

  • Event logging has no (zero!) impact on gateway latency.

  • Adapters for popular open-source time-series databases are supported out of the box.

  • Allows for near-realtime investigations.

  • Fully integrated with simulation.


In-process simulation is very performant: you can typically replay a full trading session in seconds.

  • Event logs (files) are used directly avoiding the need for an intermediary database solution.

  • Replay can leverage kernel prefetching for optimal speed.

  • Repeated simulation on the same host is optimal since the kernel will keep the file content in cache memory.


There are no arbitrary translation layers between gateway and simulation: you should trust that simulation is very close to live trading.

  • The event log is designed to capture all messages seen by a gateway: a complete representation of each message with correct ordering and associated metadata (e.g. timestamps).

  • The exact same programming interface is being used for simulation as for live trading.


Simulation can in fact never match live trading: there are external factors such as varying latency and market impact.


The gateway can protect you from unintended behaviour without getting in the way during normal operation.

  • Each trading strategy can be configured with a maximum expected number of order messages over a rolling window of time. Violation will result in the gateway banning the trading strategy from trading for a configured period of time.

  • A continuously reconnecting trading strategy will also trigger a ban.

  • Violations can be accessed by external monitoring solutions so alerts can be emitted.


The gateways only implement rudimentary checks unrelated to current net position and/or accumulated profit/loss. An external risk management system would be needed for that.


The design is that of microservices: there is built-in support for restarting individual components.

  • Connecting trading strategy to a gateway will automatically fetch (download) a snapshot of its own data (orders, trades, positions) and all subscribed symbols (reference data, market status, order book, etc.).

  • Restarting a gateway will cause clients to automatically reconnect and download snapshot data. The gateway will only allow client connections once it has itself downloaded data from the exchange.

Easy to Use

Although the software solutions have primarily been designed for low latency, there are configurations catering to non latency sensitive applications.

  • Gateways do not have to busy poll: an optional configuration allows the gateway to yield control back to the kernel. This results in lower resource requirements (CPUs) at the cost of higher latency.

  • Samples to get you started.

High Frequence Trading (HFT)

The software solutions have been designed with this use case in mind.

  • Shared memory to communicate between trading strategy and gateways.

  • Busy polling on either side to avoid latency caused by thread wake-up time.

  • Support for kernel bypass (as long as the solution supports the Linux epoll interface).


Every important metric is available for inspection!

  • Metrics can be scraped using Prometheus.

  • Sample dashboard using Grafana.


Having a system architecture is not a requirement: this setup is trivial (and used extensively in the samples)

However, a possible reference architecture for low latency algorithmic trading could look like this

Zone 1

Very latency sensitive. Components should be scheduled to execute on distinct CPU cores using thread affinity and CPU isolation. Threads are expected to busy poll and never be interrupted.

Zone 2

Not very latency sensitive. Components should be installed on same host as Zone 1 normally with no special concern to CPU scheduling.

Zone 3

No sensitivity to latency and not required to even be installed on same host. Only requirement is that there is network access to zone 1 and 2.

This reference architecture can easily be installed on your server, if you use the Ansible playbook available from GitHub.


Trading Strategy

Your own implementation of a trading strategy. The program can operate in one of two modes: simulation or live trading.

Market Gateway

A service providing a bridge between an exchange and trading strategies. All gateways implement exactly the same client facing interface.

Auxiliary Services

Third-party solutions allowing you to monitor software and system internals. Although not a requirement, we promote and support popular open-source solutions, whenever possible.


Various utilities to help you configure, deploy and monitor a production environment. You can audit and modify according to your individual requirements.


Source code demonstrating basic features required to implement a trading strategy.