Gateway config files use the TOML format.
All gateways include a template config file installed to
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.
[symbols] 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.
[accounts] [accounts.my_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.
These are the permissions for each client (trading strategy) allowed to connect to the gateway.
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.
[users] [users.user_one] password = "some_secret_password" accounts = [ "my_account" ] symbols = [ "some_symbol" ] [users.drop_copy_user] password = "some_secret_password" drop_copy = true
The gateway will log all unauthorized attempts.
The user will receive an
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.
create_ordersection can be reference from
modify_ordersection can be reference from
cancel_ordersection can be reference from
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
Second level is on of
Third level is a user-defined label.
Fourth level is a list of key-value pairs with interpretation defined by the gateway.
[templates] [templates.create_order] [templates.create_order.ET] self_trade_prevention_mode = "EXPIRE_TAKER" [templates.create_order.EM] self_trade_prevention_mode = "EXPIRE_MAKER" [templates.create_order.EB] self_trade_prevention_mode = "EXPIRE_BOTH" [templates.cancel_order] [templates.cancel_order.ON] cancel_restrictions = "ONLY_NEW" [templates.cancel_order.OPF] cancel_restrictions = "ONLY_PARTIALLY_FILLED"
This section contains custom rate limiters.
Each rate limiter has the following fields
accounts(regex, default is “all”)
users(regex, default is “all”)
aggregate(boolean, default is false)
type of the rate limiter can be
CREATE_ORDER (create order,
ORDER_ACTION (any order action).
Only one of
users should be specified.
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).
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.
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.
[rate_limits] # all order actions # across all user and accounts [rate_limits.global] type = "ORDER_ACTION" aggregate = true request_limit = 100 monitor_period = "10s" ban_period = "5m" # create order, only # apply individually to any account named "A.*" [rate_limits.A] type = "CREATE_ORDER" accounts = "A.*" request_limit = 30 monitor_period = "1s" ban_period = "5m" # create order, only # apply to the user named "trader" [rate_limits.market_maker] 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
secretkey 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
[accounts] [accounts.A1] login = "some_username" [accounts.A2] login = "another_username" secret = "another_secret"
Then the secret for
some_secret (looked up in the secrets
file) and the secret for
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.
[deribit-1] A1 = "some_secret" A2 = "another_secret" [deribit-2] A1 = "also_secret"