Gateway config files use the TOML format.

All gateways include a template config file installed to $PREFIX/share/<name>/config.toml. For example, you can copy the template like this, if you have installed the Deribit gateway to your conda environment

cp $CONDA_PREFIX/share/roq-deribit/config.toml deribit.toml


These are the include/exclude regex filters for reference and market data.

include = [ "some_symbol", "some_prefix-.*" ]
exclude = [ ".*without_this.*" ]

This may be simplified.

symbols = ".*"
symbols = [ "some_symbol", "some_prefix-.*" ]


These are the exchange logins.

The master account is the one being used for subscribing e.g. reference and market data. There can only be one master account.

Each table contains the authentication details for an account.


  login = "some_username"
  secret = "some_secret"
  symbols = [ "some_symbol", "some_prefix-.*" ]
  master = true

Symbols can be a single symbol or regex, or a list of such.

A margin-mode can optionally be specified, e.g.


  login = "some_username"
  secret = "some_secret"
  symbols = [ "some_symbol", "some_prefix-.*" ]
  margin_mode = "portfolio"


These are the permissions for each client (trading strategy) allowed to connect to the gateway.

Permissions include

  • List of accounts that can be used for order routing.

  • List of symbols that can be traded.

  • Drop-copy mode allowed?

Each table contains the authentication details of a user.


  password = "some_secret_password"
  accounts = [ "my_account" ]
  symbols = [ "some_symbol" ]

  password = "some_secret_password"
  drop_copy = true


The gateway will log all unauthorized attempts. The user will receive an OrderAck with status=REJECTED and error=NOT_AUTHORIZED, when not permissioned.


This section is optional, requires gateway support, and may contain a list of exchange-specific order request fields that are not otherwise available at the API level.


Please refer to the reference documentation of the relevant gateway.

The templates are separated into the following groups and identified by a user defined label.

Each of these request clasess have a request_template field (optional) which should match a corresponding label from the gateway configuration.

Each template has the following structure

  • First level is templates.

  • Second level is on of create_order, modify_order and cancel_order.

  • Third level is a user-defined label.

  • Fourth level is a list of key-value pairs with interpretation defined by the gateway.

Example (Binance)



    self_trade_prevention_mode = "EXPIRE_TAKER"

    self_trade_prevention_mode = "EXPIRE_MAKER"

    self_trade_prevention_mode = "EXPIRE_BOTH"


    cancel_restrictions = "ONLY_NEW"

    cancel_restrictions = "ONLY_PARTIALLY_FILLED"

Rate Limits#

This section contains custom rate limiters.

Each rate limiter has the following fields

  • type (string)

  • accounts (regex, default is “all”)

  • users (regex, default is “all”)

  • aggregate (boolean, default is false)

  • request_limit (integer)

  • monitor_period (period)

  • ban_period (period)

  • high_water_mark (integer, optional)

  • low_water_mark (integer, optional)

The type of the rate limiter can be CREATE_ORDER (create order, only) or ORDER_ACTION (any order action).

Only one of accounts or users should be specified.

The aggregate flag us used to indicate if the rate limiter should work in aggregate across all matching users or accounts (true), or be individually applied to each matching user or account (false).

The request_limit is the number of allowed events per monitor_period (rolling window). Order actions will automatically be rejected for ban_period, if a rate limiter has been triggered.

The high_water_mark and low_water_mark fields are used if both are non-zero (default value is zero). This relation must hold true when the fields are specified 0 < low_water_mark < high_water_mark < request_limit.


  # all order actions
  # across all user and accounts
  type = "ORDER_ACTION"
  aggregate = true
  request_limit = 100
  monitor_period = "10s"
  ban_period = "5m"

  # create order, only
  # apply individually to any account named "A.*"
  type = "CREATE_ORDER"
  accounts = "A.*"
  request_limit = 30
  monitor_period = "1s"
  ban_period = "5m"

  # create order, only
  # apply to the user named "trader"
  type = "CREATE_ORDER"
  users = [ "trader" ]
  request_limit = 20
  monitor_period = "200ms"
  ban_period = "5m"
  high_water_mark = 15
  low_water_mark = 10


It may be useful to exclude secrets from the general config file.

A secrets file is a simple key-value map like this

A1 = "some_secret"
A2 = "some_other_secret"

When the general config file is being parsed for an account and

  • the secret key is not found, and

  • a secrets file has been specified on the command-line, then

the secret will be looked up from the secrets file.


The inverse is not true: If the config file has the secret key specified for an account, it will be used.

Assume this is part of the config file


  login = "some_username"

  login = "another_username"
  secret = "another_secret"

Then the secret for A1 is some_secret (looked up in the secrets file) and the secret for A2 is another_secret (from config file).

Another option is to define all your secrets in a single file and group them by service name, e.g.

A1 = "some_secret"
A2 = "another_secret"

A1 = "also_secret"