Configuration¶

Basics Concepts¶

There are lots of settings inside gryphon that can be tweaked between runs. Some of these are engine set-up parameters, like whether or not to log errors to a 3rd party service, some are these are specific numeric parameters to strategies, like a lookback window for a bollinger band signal, and some are obscure. To tweak these settings between runs of the strategy engine, Gryphon uses a format called .conf files.

Conf files are simple lists of key-value pairs, sometimes grouped under a section heading. Here’s an example:

[platform]
audit: no
emerald: no

[strategy]
tick_sleep: 4
base_volume: BTC 0.002
spread: 0.002

[bitstamp_btc_usd]
market_order_fee: 2.00
emerald: no

Gryphon will try to parse the values of these parameters into python types intelligently, and if no appropriate type can be found, the value is loaded as a string. Here are the supported value formats in order of parsing order:

Python type	String Format	Example
Boolean	“yes” or “no”	yes
Money	“[currency code] [numeric amount]”	BTC 2.35
Decimal	“[numeric amount]”	0.22147
String	Anything else	bitstamp_btc_usd

Gryphon can also handle comma separated list values, but this must be done explicitly by the strategy writer.

Note that this type of configuration has nothing to do with secret credentials, which are handled in .env files.

A given configuration is associated with a strategy, and is loaded by the engine at runtime. The engine by default loads the configuration from a file named after the strategy with the .conf suffix. You can provide a path to a different location by passing the parameter -c/--config_file to the engine.

Three components of Gryphon are configurable: the target strategy, the exchange integrations, and the engine itself.

Strategy Configuration¶

You will very likely want to write strategies with parameters that can be changed between executions, like a spread width, or a lookback time, etc. These parameters can be placed under a section [strategy] in the .conf file, and they will be passed to your strategy class on start-up.

To write your strategy to accept a configuration parameter, here are the steps:

Define the property with a default in the constructor, or with a None value to require it from the user.
Implement the function configure(self, strat_config), being sure to call the superclass implementation as the first line of this function.
Inside configure, call this self.init_configurable([name], strat_config) for each property you want to be configurable.

Here is an exceprt of the SimpleMarketMaking builtin strategy that shows how this all fits together.

class SimpleMarketMaking(Strategy):
    def __init__(self, db, harness, strategy_configuration):
        super(SimpleMarketMaking, self).__init__(db, harness)

        # Configurable properties with defaults.
        self.spread = Decimal('0.01')
        self.base_volume = Money('0.005', 'BTC')
        self.exchange = None

        self.configure(strategy_configuration)

    def configure(self, strategy_configuration):
        super(SimpleMarketMaking, self).configure(strategy_configuration)

        self.init_configurable('spread', strategy_configuration)
        self.init_configurable('base_volume', strategy_configuration)
        self.init_configurable('exchange', strategy_configuration)

Feel free to do any other custom configuration work in your configure() function.

Engine Configuration¶

The engine can be configured in a section of the config file headed “platform”. Here are the current supported engine config settings with example (but not default) settings:

[platform]
audit: no
audit_tick: 100
audit_types: ledger, volume_balance
sentry: no
emerald: no

Note that all of these can be set or overridden at the command line as well by prefacing the parameter name with two dashes.

Here’s a short explanation of each parameter:

audit - Whether to turn on auditing.
audit_tick - Audit every n ticks.
audit_types - Comma separated list of audit types to perform.
emerald - Whether to use fast market data from GDS or perform market data IO operations in the same thread as the trading code (the default).
sentry - Whether to send log messages and errors to the 3rd party logging service sentry, requires it’s own setup.

Exchange Pair Configuration¶

There are many parameters to exchange accounts that can change over time or be different between users. The most obvious is fee levels, which are usually a function of a user’s recent volume on that exchange, but there are other parameters like minimum order sizes that are important to set accurately too.

The strategy engine loads configuration information for each exchange pair from a section in the config file labelled with the pair’s name, like bitstamp_btc_usd. You can add a section for each pair that you plan to trade with using the strategy.

Here’s a fully filled out section for coinbase btcusd:

[coinbase_btc_usd]
market_order_fee: 0.003
limit_order_fee: 0.001
max_tick_speed: 2
fiat_balance_tolerance: USD 0.01
volume_balance_tolerance: BTC 0.00000001
use_cached_orderbook: no

Each pair has defaults for each of these parameters, but you should override them as necessary. volume/fiat_balance_tolerance are only relevant if you are using auditing in the engine, and use_cached_orderbook is only relevant if you are running GDS in parallel to your strategies.