Config¶
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
Symbols¶
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-.*" ]
Accounts¶
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.
A margin-mode can optionally be specified, e.g.
[accounts]
[accounts.my_account]
login = "some_username"
secret = "some_secret"
symbols = [ "some_symbol", "some_prefix-.*" ]
margin_mode = "portfolio"
Users¶
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.
[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
Note
The gateway will log all unauthorized attempts.
The user will receive an OrderAck
with status=REJECTED
and
error=NOT_AUTHORIZED
, when not permissioned.
Templates¶
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.
Note
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.
The
create_order
section can be reference fromroq::CreateOrder
.The
modify_order
section can be reference fromroq::ModifyOrder
.The
cancel_order
section can be reference fromroq::CancelOrder
.
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
andcancel_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)
[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"
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
.
[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
Secrets¶
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, anda secrets file has been specified on the command-line, then
the secret will be looked up from the secrets file.
Note
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 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.
[deribit-1]
A1 = "some_secret"
A2 = "another_secret"
[deribit-2]
A1 = "also_secret"