Skip to content

Configure the bot

Freqtrade has many configurable features and possibilities. By default, these settings are configured via the configuration file (see below).

The Freqtrade configuration file

The bot uses a set of configuration parameters during its operation that all together conform the bot configuration. It normally reads its configuration from a file (Freqtrade configuration file).

Per default, the bot loads the configuration from the config.json file, located in the current working directory.

You can specify a different configuration file used by the bot with the -c/--config command line option.

In some advanced use cases, multiple configuration files can be specified and used by the bot or the bot can read its configuration parameters from the process standard input stream.

If you used the Quick start method for installing the bot, the installation script should have already created the default configuration file (config.json) for you.

If default configuration file is not created we recommend you to copy and use the config.json.example as a template for your bot configuration.

The Freqtrade configuration file is to be written in the JSON format.

Additionally to the standard JSON syntax, you may use one-line // ... and multi-line /* ... */ comments in your configuration files and trailing commas in the lists of parameters.

Do not worry if you are not familiar with JSON format -- simply open the configuration file with an editor of your choice, make some changes to the parameters you need, save your changes and, finally, restart the bot or, if it was previously stopped, run it again with the changes you made to the configuration. The bot validates syntax of the configuration file at startup and will warn you if you made any errors editing it, pointing out problematic lines.

Configuration parameters

The table below will list all configuration parameters available.

Freqtrade can also load many options via command line (CLI) arguments (check out the commands --help output for details). The prevelance for all Options is as follows:

  • CLI arguments override any other option
  • Configuration files are used in sequence (last file wins), and override Strategy configurations.
  • Strategy configurations are only used if they are not set via configuration or via command line arguments. These options are marked with Strategy Override in the below table.

Mandatory parameters are marked as Required, which means that they are required to be set in one of the possible ways.

Parameter Description
max_open_trades Required. Number of open trades your bot is allowed to have. Only one open trade per pair is possible, so the length of your pairlist is another limitation which can apply. If -1 then it is ignored (i.e. potentially unlimited open trades, limited by the pairlist). More information below.
Datatype: Positive integer or -1.
stake_currency Required. Crypto-currency used for trading. Strategy Override.
Datatype: String
stake_amount Required. Amount of crypto-currency your bot will use for each trade. Set it to "unlimited" to allow the bot to use all available balance. More information below. Strategy Override.
Datatype: Positive float or "unlimited".
tradable_balance_ratio Ratio of the total account balance the bot is allowed to trade. More information below.
Defaults to 0.99 99%).
Datatype: Positive float between 0.1 and 1.0.
amend_last_stake_amount Use reduced last stake amount if necessary. More information below.
Defaults to false.
Datatype: Boolean
last_stake_amount_min_ratio Defines minimum stake amount that has to be left and executed. Applies only to the last stake amount when it's amended to a reduced value (i.e. if amend_last_stake_amount is set to true). More information below.
Defaults to 0.5.
Datatype: Float (as ratio)
amount_reserve_percent Reserve some amount in min pair stake amount. The bot will reserve amount_reserve_percent + stoploss value when calculating min pair stake amount in order to avoid possible trade refusals.
Defaults to 0.05 (5%).
Datatype: Positive Float as ratio.
timeframe The timeframe (former ticker interval) to use (e.g 1m, 5m, 15m, 30m, 1h ...). Strategy Override.
Datatype: String
fiat_display_currency Fiat currency used to show your profits. More information below.
Datatype: String
dry_run Required. Define if the bot must be in Dry Run or production mode.
Defaults to true.
Datatype: Boolean
dry_run_wallet Define the starting amount in stake currency for the simulated wallet used by the bot running in the Dry Run mode.
Defaults to 1000.
Datatype: Float
cancel_open_orders_on_exit Cancel open orders when the /stop RPC command is issued, Ctrl+C is pressed or the bot dies unexpectedly. When set to true, this allows you to use /stop to cancel unfilled and partially filled orders in the event of a market crash. It does not impact open positions.
Defaults to false.
Datatype: Boolean
process_only_new_candles Enable processing of indicators only when new candles arrive. If false each loop populates the indicators, this will mean the same candle is processed many times creating system load but can be useful of your strategy depends on tick data not only candle. Strategy Override.
Defaults to false.
Datatype: Boolean
minimal_roi Required. Set the threshold as ratio the bot will use to sell a trade. More information below. Strategy Override.
Datatype: Dict
stoploss Required. Value as ratio of the stoploss used by the bot. More details in the stoploss documentation. Strategy Override.
Datatype: Float (as ratio)
trailing_stop Enables trailing stoploss (based on stoploss in either configuration or strategy file). More details in the stoploss documentation. Strategy Override.
Datatype: Boolean
trailing_stop_positive Changes stoploss once profit has been reached. More details in the stoploss documentation. Strategy Override.
Datatype: Float
trailing_stop_positive_offset Offset on when to apply trailing_stop_positive. Percentage value which should be positive. More details in the stoploss documentation. Strategy Override.
Defaults to 0.0 (no offset).
Datatype: Float
trailing_only_offset_is_reached Only apply trailing stoploss when the offset is reached. stoploss documentation. Strategy Override.
Defaults to false.
Datatype: Boolean
unfilledtimeout.buy Required. How long (in minutes) the bot will wait for an unfilled buy order to complete, after which the order will be cancelled and repeated at current (new) price, as long as there is a signal. Strategy Override.
Datatype: Integer
unfilledtimeout.sell Required. How long (in minutes) the bot will wait for an unfilled sell order to complete, after which the order will be cancelled and repeated at current (new) price, as long as there is a signal. Strategy Override.
Datatype: Integer
bid_strategy.price_side Select the side of the spread the bot should look at to get the buy rate. More information below.
Defaults to bid.
Datatype: String (either ask or bid).
bid_strategy.ask_last_balance Required. Set the bidding price. More information below.
bid_strategy.use_order_book Enable buying using the rates in Order Book Bids.
Datatype: Boolean
bid_strategy.order_book_top Bot will use the top N rate in Order Book Bids to buy. I.e. a value of 2 will allow the bot to pick the 2nd bid rate in Order Book Bids.
Defaults to 1.
Datatype: Positive Integer
bid_strategy. check_depth_of_market.enabled Do not buy if the difference of buy orders and sell orders is met in Order Book. Check market depth.
Defaults to false.
Datatype: Boolean
bid_strategy. check_depth_of_market.bids_to_ask_delta The difference ratio of buy orders and sell orders found in Order Book. A value below 1 means sell order size is greater, while value greater than 1 means buy order size is higher. Check market depth
Defaults to 0.
Datatype: Float (as ratio)
ask_strategy.price_side Select the side of the spread the bot should look at to get the sell rate. More information below.
Defaults to ask.
Datatype: String (either ask or bid).
ask_strategy.use_order_book Enable selling of open trades using Order Book Asks.
Datatype: Boolean
ask_strategy.order_book_min Bot will scan from the top min to max Order Book Asks searching for a profitable rate.
Defaults to 1.
Datatype: Positive Integer
ask_strategy.order_book_max Bot will scan from the top min to max Order Book Asks searching for a profitable rate.
Defaults to 1.
Datatype: Positive Integer
ask_strategy.use_sell_signal Use sell signals produced by the strategy in addition to the minimal_roi. Strategy Override.
Defaults to true.
Datatype: Boolean
ask_strategy.sell_profit_only Wait until the bot reaches ask_strategy.sell_profit_offset before taking a sell decision. Strategy Override.
Defaults to false.
Datatype: Boolean
ask_strategy.sell_profit_offset Sell-signal is only active above this value. Strategy Override.
Defaults to 0.0.
Datatype: Float (as ratio)
ask_strategy.ignore_roi_if_buy_signal Do not sell if the buy signal is still active. This setting takes preference over minimal_roi and use_sell_signal. Strategy Override.
Defaults to false.
Datatype: Boolean
ask_strategy.ignore_buying_expired_candle_after Specifies the number of seconds until a buy signal is no longer used.
Datatype: Integer
order_types Configure order-types depending on the action ("buy", "sell", "stoploss", "stoploss_on_exchange"). More information below. Strategy Override.
Datatype: Dict
order_time_in_force Configure time in force for buy and sell orders. More information below. Strategy Override.
Datatype: Dict
exchange.name Required. Name of the exchange class to use. List below.
Datatype: String
exchange.sandbox Use the 'sandbox' version of the exchange, where the exchange provides a sandbox for risk-free integration. See here in more details.
Datatype: Boolean
exchange.key API key to use for the exchange. Only required when you are in production mode.
Keep it in secret, do not disclose publicly.
Datatype: String
exchange.secret API secret to use for the exchange. Only required when you are in production mode.
Keep it in secret, do not disclose publicly.
Datatype: String
exchange.password API password to use for the exchange. Only required when you are in production mode and for exchanges that use password for API requests.
Keep it in secret, do not disclose publicly.
Datatype: String
exchange.pair_whitelist List of pairs to use by the bot for trading and to check for potential trades during backtesting. Supports regex pairs as .*/BTC. Not used by VolumePairList (see below).
Datatype: List
exchange.pair_blacklist List of pairs the bot must absolutely avoid for trading and backtesting (see below).
Datatype: List
exchange.ccxt_config Additional CCXT parameters passed to both ccxt instances (sync and async). This is usually the correct place for ccxt configurations. Parameters may differ from exchange to exchange and are documented in the ccxt documentation
Datatype: Dict
exchange.ccxt_sync_config Additional CCXT parameters passed to the regular (sync) ccxt instance. Parameters may differ from exchange to exchange and are documented in the ccxt documentation
Datatype: Dict
exchange.ccxt_async_config Additional CCXT parameters passed to the async ccxt instance. Parameters may differ from exchange to exchange and are documented in the ccxt documentation
Datatype: Dict
exchange.markets_refresh_interval The interval in minutes in which markets are reloaded.
Defaults to 60 minutes.
Datatype: Positive Integer
exchange.skip_pair_validation Skip pairlist validation on startup.
Defaults to false
Datatype:* Boolean
edge.* Please refer to edge configuration document for detailed explanation.
experimental.block_bad_exchanges Block exchanges known to not work with freqtrade. Leave on default unless you want to test if that exchange works now.
Defaults to true.
Datatype: Boolean
pairlists Define one or more pairlists to be used. More information below.
Defaults to StaticPairList.
Datatype: List of Dicts
protections Define one or more protections to be used. More information below. Strategy Override.
Datatype: List of Dicts
telegram.enabled Enable the usage of Telegram.
Datatype: Boolean
telegram.token Your Telegram bot token. Only required if telegram.enabled is true.
Keep it in secret, do not disclose publicly.
Datatype: String
telegram.chat_id Your personal Telegram account id. Only required if telegram.enabled is true.
Keep it in secret, do not disclose publicly.
Datatype: String
webhook.enabled Enable usage of Webhook notifications
Datatype: Boolean
webhook.url URL for the webhook. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
webhook.webhookbuy Payload to send on buy. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
webhook.webhookbuycancel Payload to send on buy order cancel. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
webhook.webhooksell Payload to send on sell. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
webhook.webhooksellcancel Payload to send on sell order cancel. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
webhook.webhookstatus Payload to send on status calls. Only required if webhook.enabled is true. See the webhook documentation for more details.
Datatype: String
api_server.enabled Enable usage of API Server. See the API Server documentation for more details.
Datatype: Boolean
api_server.listen_ip_address Bind IP address. See the API Server documentation for more details.
Datatype: IPv4
api_server.listen_port Bind Port. See the API Server documentation for more details.
Datatype: Integer between 1024 and 65535
api_server.verbosity Logging verbosity. info will print all RPC Calls, while "error" will only display errors.
Datatype: Enum, either info or error. Defaults to info.
api_server.username Username for API server. See the API Server documentation for more details.
Keep it in secret, do not disclose publicly.
Datatype: String
api_server.password Password for API server. See the API Server documentation for more details.
Keep it in secret, do not disclose publicly.
Datatype: String
db_url Declares database URL to use. NOTE: This defaults to sqlite:///tradesv3.dryrun.sqlite if dry_run is true, and to sqlite:///tradesv3.sqlite for production instances.
Datatype: String, SQLAlchemy connect string
initial_state Defines the initial application state. More information below.
Defaults to stopped.
Datatype: Enum, either stopped or running
forcebuy_enable Enables the RPC Commands to force a buy. More information below.
Datatype: Boolean
disable_dataframe_checks Disable checking the OHLCV dataframe returned from the strategy methods for correctness. Only use when intentionally changing the dataframe and understand what you are doing. Strategy Override.
Defaults to False.
Datatype: Boolean
strategy Required Defines Strategy class to use. Recommended to be set via --strategy NAME.
Datatype: ClassName
strategy_path Adds an additional strategy lookup path (must be a directory).
Datatype: String
internals.process_throttle_secs Set the process throttle. Value in second.
Defaults to 5 seconds.
Datatype: Positive Integer
internals.heartbeat_interval Print heartbeat message every N seconds. Set to 0 to disable heartbeat messages.
Defaults to 60 seconds.
Datatype: Positive Integer or 0
internals.sd_notify Enables use of the sd_notify protocol to tell systemd service manager about changes in the bot state and issue keep-alive pings. See here for more details.
Datatype: Boolean
logfile Specifies logfile name. Uses a rolling strategy for log file rotation for 10 files with the 1MB limit per file.
Datatype: String
user_data_dir Directory containing user data.
Defaults to ./user_data/.
Datatype: String
dataformat_ohlcv Data format to use to store historical candle (OHLCV) data.
Defaults to json.
Datatype: String
dataformat_trades Data format to use to store historical trades data.
Defaults to jsongz.
Datatype: String

Parameters in the strategy

The following parameters can be set in either configuration file or strategy. Values set in the configuration file always overwrite values set in the strategy.

  • minimal_roi
  • timeframe
  • stoploss
  • trailing_stop
  • trailing_stop_positive
  • trailing_stop_positive_offset
  • trailing_only_offset_is_reached
  • process_only_new_candles
  • order_types
  • order_time_in_force
  • stake_currency
  • stake_amount
  • unfilledtimeout
  • disable_dataframe_checks
  • protections
  • use_sell_signal (ask_strategy)
  • sell_profit_only (ask_strategy)
  • ignore_roi_if_buy_signal (ask_strategy)
  • ignore_buying_expired_candle_after (ask_strategy)

Configuring amount per trade

There are several methods to configure how much of the stake currency the bot will use to enter a trade. All methods respect the available balance configuration as explained below.

Available balance

By default, the bot assumes that the complete amount - 1% is at it's disposal, and when using dynamic stake amount, it will split the complete balance into max_open_trades buckets per trade. Freqtrade will reserve 1% for eventual fees when entering a trade and will therefore not touch that by default.

You can configure the "untouched" amount by using the tradable_balance_ratio setting.

For example, if you have 10 ETH available in your wallet on the exchange and tradable_balance_ratio=0.5 (which is 50%), then the bot will use a maximum amount of 5 ETH for trading and considers this as available balance. The rest of the wallet is untouched by the trades.

Warning

The tradable_balance_ratio setting applies to the current balance (free balance + tied up in trades). Therefore, assuming the starting balance of 1000, a configuration with tradable_balance_ratio=0.99 will not guarantee that 10 currency units will always remain available on the exchange. For example, the free amount may reduce to 5 units if the total balance is reduced to 500 (either by a losing streak, or by withdrawing balance).

Amend last stake amount

Assuming we have the tradable balance of 1000 USDT, stake_amount=400, and max_open_trades=3. The bot would open 2 trades, and will be unable to fill the last trading slot, since the requested 400 USDT are no longer available, since 800 USDT are already tied in other trades.

To overcome this, the option amend_last_stake_amount can be set to True, which will enable the bot to reduce stake_amount to the available balance in order to fill the last trade slot.

In the example above this would mean:

  • Trade1: 400 USDT
  • Trade2: 400 USDT
  • Trade3: 200 USDT

Note

This option only applies with Static stake amount - since Dynamic stake amount divides the balances evenly.

Note

The minimum last stake amount can be configured using last_stake_amount_min_ratio - which defaults to 0.5 (50%). This means that the minimum stake amount that's ever used is stake_amount * 0.5. This avoids very low stake amounts, that are close to the minimum tradable amount for the pair and can be refused by the exchange.

Static stake amount

The stake_amount configuration statically configures the amount of stake-currency your bot will use for each trade.

The minimal configuration value is 0.0001, however, please check your exchange's trading minimums for the stake currency you're using to avoid problems.

This setting works in combination with max_open_trades. The maximum capital engaged in trades is stake_amount * max_open_trades. For example, the bot will at most use (0.05 BTC x 3) = 0.15 BTC, assuming a configuration of max_open_trades=3 and stake_amount=0.05.

Note

This setting respects the available balance configuration.

Dynamic stake amount

Alternatively, you can use a dynamic stake amount, which will use the available balance on the exchange, and divide that equally by the amount of allowed trades (max_open_trades).

To configure this, set stake_amount="unlimited". We also recommend to set tradable_balance_ratio=0.99 (99%) - to keep a minimum balance for eventual fees.

In this case a trade amount is calculated as:

currency_balance / (max_open_trades - current_open_trades)

To allow the bot to trade all the available stake_currency in your account (minus tradable_balance_ratio) set

"stake_amount" : "unlimited",
"tradable_balance_ratio": 0.99,

Note

This configuration will allow increasing / decreasing stakes depending on the performance of the bot (lower stake if bot is loosing, higher stakes if the bot has a winning record, since higher balances are available).

When using Dry-Run Mode

When using "stake_amount" : "unlimited", in combination with Dry-Run, the balance will be simulated starting with a stake of dry_run_wallet which will evolve over time. It is therefore important to set dry_run_wallet to a sensible value (like 0.05 or 0.01 for BTC and 1000 or 100 for USDT, for example), otherwise it may simulate trades with 100 BTC (or more) or 0.05 USDT (or less) at once - which may not correspond to your real available balance or is less than the exchange minimal limit for the order amount for the stake currency.

Understand minimal_roi

The minimal_roi configuration parameter is a JSON object where the key is a duration in minutes and the value is the minimum ROI as ratio. See the example below:

"minimal_roi": {
    "40": 0.0,    # Sell after 40 minutes if the profit is not negative
    "30": 0.01,   # Sell after 30 minutes if there is at least 1% profit
    "20": 0.02,   # Sell after 20 minutes if there is at least 2% profit
    "0":  0.04    # Sell immediately if there is at least 4% profit
},

Most of the strategy files already include the optimal minimal_roi value. This parameter can be set in either Strategy or Configuration file. If you use it in the configuration file, it will override the minimal_roi value from the strategy file. If it is not set in either Strategy or Configuration, a default of 1000% {"0": 10} is used, and minimal roi is disabled unless your trade generates 1000% profit.

Special case to forcesell after a specific time

A special case presents using "<N>": -1 as ROI. This forces the bot to sell a trade after N Minutes, no matter if it's positive or negative, so represents a time-limited force-sell.

Understand stoploss

Go to the stoploss documentation for more details.

Understand trailing stoploss

Go to the trailing stoploss Documentation for details on trailing stoploss.

Understand initial_state

The initial_state configuration parameter is an optional field that defines the initial application state. Possible values are running or stopped. (default=running) If the value is stopped the bot has to be started with /start first.

Understand forcebuy_enable

The forcebuy_enable configuration parameter enables the usage of forcebuy commands via Telegram. This is disabled for security reasons by default, and will show a warning message on startup if enabled. For example, you can send /forcebuy ETH/BTC Telegram command when this feature if enabled to the bot, who then buys the pair and holds it until a regular sell-signal (ROI, stoploss, /forcesell) appears.

This can be dangerous with some strategies, so use with care.

See the telegram documentation for details on usage.

Understand process_throttle_secs

The process_throttle_secs configuration parameter is an optional field that defines in seconds how long the bot should wait before asking the strategy if we should buy or a sell an asset. After each wait period, the strategy is asked again for every opened trade wether or not we should sell, and for all the remaining pairs (either the dynamic list of pairs or the static list of pairs) if we should buy.

Understand order_types

The order_types configuration parameter maps actions (buy, sell, stoploss, emergencysell) to order-types (market, limit, ...) as well as configures stoploss to be on the exchange and defines stoploss on exchange update interval in seconds.

This allows to buy using limit orders, sell using limit-orders, and create stoplosses using market orders. It also allows to set the stoploss "on exchange" which means stoploss order would be placed immediately once the buy order is fulfilled.

order_types set in the configuration file overwrites values set in the strategy as a whole, so you need to configure the whole order_types dictionary in one place.

If this is configured, the following 4 values (buy, sell, stoploss and stoploss_on_exchange) need to be present, otherwise the bot will fail to start.

For information on (emergencysell,stoploss_on_exchange,stoploss_on_exchange_interval,stoploss_on_exchange_limit_ratio) please see stop loss documentation stop loss on exchange

Syntax for Strategy:

order_types = {
    "buy": "limit",
    "sell": "limit",
    "emergencysell": "market",
    "stoploss": "market",
    "stoploss_on_exchange": False,
    "stoploss_on_exchange_interval": 60,
    "stoploss_on_exchange_limit_ratio": 0.99,
}

Configuration:

"order_types": {
    "buy": "limit",
    "sell": "limit",
    "emergencysell": "market",
    "stoploss": "market",
    "stoploss_on_exchange": false,
    "stoploss_on_exchange_interval": 60
}

Market order support

Not all exchanges support "market" orders. The following message will be shown if your exchange does not support market orders: "Exchange <yourexchange> does not support market orders." and the bot will refuse to start.

Using market orders

Please carefully read the section Market order pricing section when using market orders.

Stoploss on exchange

stoploss_on_exchange_interval is not mandatory. Do not change its value if you are unsure of what you are doing. For more information about how stoploss works please refer to the stoploss documentation.

If stoploss_on_exchange is enabled and the stoploss is cancelled manually on the exchange, then the bot will create a new stoploss order.

Warning: stoploss_on_exchange failures

If stoploss on exchange creation fails for some reason, then an "emergency sell" is initiated. By default, this will sell the asset using a market order. The order-type for the emergency-sell can be changed by setting the emergencysell value in the order_types dictionary - however this is not advised.

Understand order_time_in_force

The order_time_in_force configuration parameter defines the policy by which the order is executed on the exchange. Three commonly used time in force are:

GTC (Good Till Canceled):

This is most of the time the default time in force. It means the order will remain on exchange till it is canceled by user. It can be fully or partially fulfilled. If partially fulfilled, the remaining will stay on the exchange till cancelled.

FOK (Fill Or Kill):

It means if the order is not executed immediately AND fully then it is canceled by the exchange.

IOC (Immediate Or Canceled):

It is the same as FOK (above) except it can be partially fulfilled. The remaining part is automatically cancelled by the exchange.

The order_time_in_force parameter contains a dict with buy and sell time in force policy values. This can be set in the configuration file or in the strategy. Values set in the configuration file overwrites values set in the strategy.

The possible values are: gtc (default), fok or ioc.

"order_time_in_force": {
    "buy": "gtc",
    "sell": "gtc"
},

Warning

This is an ongoing work. For now it is supported only for binance and only for buy orders. Please don't change the default value unless you know what you are doing.

Exchange configuration

Freqtrade is based on CCXT library that supports over 100 cryptocurrency exchange markets and trading APIs. The complete up-to-date list can be found in the CCXT repo homepage. However, the bot was tested by the development team with only Bittrex, Binance and Kraken, so the these are the only officially supported exchanges:

Feel free to test other exchanges and submit your PR to improve the bot.

Some exchanges require special configuration, which can be found on the Exchange-specific Notes documentation page.

Sample exchange configuration

A exchange configuration for "binance" would look as follows:

"exchange": {
    "name": "binance",
    "key": "your_exchange_key",
    "secret": "your_exchange_secret",
    "ccxt_config": {"enableRateLimit": true},
    "ccxt_async_config": {
        "enableRateLimit": true,
        "rateLimit": 200
    },

This configuration enables binance, as well as rate limiting to avoid bans from the exchange. "rateLimit": 200 defines a wait-event of 0.2s between each call. This can also be completely disabled by setting "enableRateLimit" to false.

Note

Optimal settings for rate limiting depend on the exchange and the size of the whitelist, so an ideal parameter will vary on many other settings. We try to provide sensible defaults per exchange where possible, if you encounter bans please make sure that "enableRateLimit" is enabled and increase the "rateLimit" parameter step by step.

Advanced Freqtrade Exchange configuration

Advanced options can be configured using the _ft_has_params setting, which will override Defaults and exchange-specific behaviours.

Available options are listed in the exchange-class as _ft_has_default.

For example, to test the order type FOK with Kraken, and modify candle limit to 200 (so you only get 200 candles per API call):

"exchange": {
    "name": "kraken",
    "_ft_has_params": {
        "order_time_in_force": ["gtc", "fok"],
        "ohlcv_candle_limit": 200
        }

Warning

Please make sure to fully understand the impacts of these settings before modifying them.

What values can be used for fiat_display_currency?

The fiat_display_currency configuration parameter sets the base currency to use for the conversion from coin to fiat in the bot Telegram reports.

The valid values are:

"AUD", "BRL", "CAD", "CHF", "CLP", "CNY", "CZK", "DKK", "EUR", "GBP", "HKD", "HUF", "IDR", "ILS", "INR", "JPY", "KRW", "MXN", "MYR", "NOK", "NZD", "PHP", "PKR", "PLN", "RUB", "SEK", "SGD", "THB", "TRY", "TWD", "ZAR", "USD"

In addition to fiat currencies, a range of cryto currencies are supported.

The valid values are:

"BTC", "ETH", "XRP", "LTC", "BCH", "USDT"

Prices used for orders

Prices for regular orders can be controlled via the parameter structures bid_strategy for buying and ask_strategy for selling. Prices are always retrieved right before an order is placed, either by querying the exchange tickers or by using the orderbook data.

Note

Orderbook data used by Freqtrade are the data retrieved from exchange by the ccxt's function fetch_order_book(), i.e. are usually data from the L2-aggregated orderbook, while the ticker data are the structures returned by the ccxt's fetch_ticker()/fetch_tickers() functions. Refer to the ccxt library documentation for more details.

Using market orders

Please read the section Market order pricing section when using market orders.

Buy price

Check depth of market

When check depth of market is enabled (bid_strategy.check_depth_of_market.enabled=True), the buy signals are filtered based on the orderbook depth (sum of all amounts) for each orderbook side.

Orderbook bid (buy) side depth is then divided by the orderbook ask (sell) side depth and the resulting delta is compared to the value of the bid_strategy.check_depth_of_market.bids_to_ask_delta parameter. The buy order is only executed if the orderbook delta is greater than or equal to the configured delta value.

Note

A delta value below 1 means that ask (sell) orderbook side depth is greater than the depth of the bid (buy) orderbook side, while a value greater than 1 means opposite (depth of the buy side is higher than the depth of the sell side).

Buy price side

The configuration setting bid_strategy.price_side defines the side of the spread the bot looks for when buying.

The following displays an orderbook.

...
103
102
101  # ask
-------------Current spread
99   # bid
98
97
...

If bid_strategy.price_side is set to "bid", then the bot will use 99 as buying price.
In line with that, if bid_strategy.price_side is set to "ask", then the bot will use 101 as buying price.

Using ask price often guarantees quicker filled orders, but the bot can also end up paying more than what would have been necessary. Taker fees instead of maker fees will most likely apply even when using limit buy orders. Also, prices at the "ask" side of the spread are higher than prices at the "bid" side in the orderbook, so the order behaves similar to a market order (however with a maximum price).

Buy price with Orderbook enabled

When buying with the orderbook enabled (bid_strategy.use_order_book=True), Freqtrade fetches the bid_strategy.order_book_top entries from the orderbook and then uses the entry specified as bid_strategy.order_book_top on the configured side (bid_strategy.price_side) of the orderbook. 1 specifies the topmost entry in the orderbook, while 2 would use the 2nd entry in the orderbook, and so on.

Buy price without Orderbook enabled

The following section uses side as the configured bid_strategy.price_side.

When not using orderbook (bid_strategy.use_order_book=False), Freqtrade uses the best side price from the ticker if it's below the last traded price from the ticker. Otherwise (when the side price is above the last price), it calculates a rate between side and last price.

The bid_strategy.ask_last_balance configuration parameter controls this. A value of 0.0 will use side price, while 1.0 will use the last price and values between those interpolate between ask and last price.

Sell price

Sell price side

The configuration setting ask_strategy.price_side defines the side of the spread the bot looks for when selling.

The following displays an orderbook:

...
103
102
101  # ask
-------------Current spread
99   # bid
98
97
...

If ask_strategy.price_side is set to "ask", then the bot will use 101 as selling price.
In line with that, if ask_strategy.price_side is set to "bid", then the bot will use 99 as selling price.

Sell price with Orderbook enabled

When selling with the orderbook enabled (ask_strategy.use_order_book=True), Freqtrade fetches the ask_strategy.order_book_max entries in the orderbook. Then each of the orderbook steps between ask_strategy.order_book_min and ask_strategy.order_book_max on the configured orderbook side are validated for a profitable sell-possibility based on the strategy configuration (minimal_roi conditions) and the sell order is placed at the first profitable spot.

Note

Using order_book_max higher than order_book_min only makes sense when ask_strategy.price_side is set to "ask".

The idea here is to place the sell order early, to be ahead in the queue.

A fixed slot (mirroring bid_strategy.order_book_top) can be defined by setting ask_strategy.order_book_min and ask_strategy.order_book_max to the same number.

Order_book_max > 1 - increased risks for stoplosses!

Using ask_strategy.order_book_max higher than 1 will increase the risk the stoploss on exchange is cancelled too early, since an eventual stoploss on exchange will be cancelled as soon as the order is placed. Also, the sell order will remain on the exchange for unfilledtimeout.sell (or until it's filled) - which can lead to missed stoplosses (with or without using stoploss on exchange).

Order_book_max > 1 in dry-run

Using ask_strategy.order_book_max higher than 1 will result in improper dry-run results (significantly better than real orders executed on exchange), since dry-run assumes orders to be filled almost instantly. It is therefore advised to not use this setting for dry-runs.

Sell price without Orderbook enabled

When not using orderbook (ask_strategy.use_order_book=False), the price at the ask_strategy.price_side side (defaults to "ask") from the ticker will be used as the sell price.

Market order pricing

When using market orders, prices should be configured to use the "correct" side of the orderbook to allow realistic pricing detection. Assuming both buy and sell are using market orders, a configuration similar to the following might be used

  "order_types": {
    "buy": "market",
    "sell": "market"
    // ...
  },
  "bid_strategy": {
    "price_side": "ask",
    // ...
  },
  "ask_strategy":{
    "price_side": "bid",
    // ...
  },

Obviously, if only one side is using limit orders, different pricing combinations can be used.

Pairlists and Pairlist Handlers

Pairlist Handlers define the list of pairs (pairlist) that the bot should trade. They are configured in the pairlists section of the configuration settings.

In your configuration, you can use Static Pairlist (defined by the StaticPairList Pairlist Handler) and Dynamic Pairlist (defined by the VolumePairList Pairlist Handler).

Additionally, AgeFilter, PrecisionFilter, PriceFilter, ShuffleFilter and SpreadFilter act as Pairlist Filters, removing certain pairs and/or moving their positions in the pairlist.

If multiple Pairlist Handlers are used, they are chained and a combination of all Pairlist Handlers forms the resulting pairlist the bot uses for trading and backtesting. Pairlist Handlers are executed in the sequence they are configured. You should always configure either StaticPairList or VolumePairList as the starting Pairlist Handler.

Inactive markets are always removed from the resulting pairlist. Explicitly blacklisted pairs (those in the pair_blacklist configuration setting) are also always removed from the resulting pairlist.

Pair blacklist

The pair blacklist (configured via exchange.pair_blacklist in the configuration) disallows certain pairs from trading. This can be as simple as excluding DOGE/BTC - which will remove exactly this pair.

The pair-blacklist does also support wildcards (in regex-style) - so BNB/.* will exclude ALL pairs that start with BNB. You may also use something like .*DOWN/BTC or .*UP/BTC to exclude leveraged tokens (check Pair naming conventions for your exchange!)

Available Pairlist Handlers

Testing pairlists

Pairlist configurations can be quite tricky to get right. Best use the test-pairlist utility sub-command to test your configuration quickly.

Static Pair List

By default, the StaticPairList method is used, which uses a statically defined pair whitelist from the configuration. The pairlist also supports wildcards (in regex-style) - so .*/BTC will include all pairs with BTC as a stake.

It uses configuration from exchange.pair_whitelist and exchange.pair_blacklist.

"pairlists": [
    {"method": "StaticPairList"}
    ],

By default, only currently enabled pairs are allowed. To skip pair validation against active markets, set "allow_inactive": true within the StaticPairList configuration. This can be useful for backtesting expired pairs (like quarterly spot-markets). This option must be configured along with exchange.skip_pair_validation in the exchange configuration.

Volume Pair List

VolumePairList employs sorting/filtering of pairs by their trading volume. It selects number_assets top pairs with sorting based on the sort_key (which can only be quoteVolume).

When used in the chain of Pairlist Handlers in a non-leading position (after StaticPairList and other Pairlist Filters), VolumePairList considers outputs of previous Pairlist Handlers, adding its sorting/selection of the pairs by the trading volume.

When used on the leading position of the chain of Pairlist Handlers, it does not consider pair_whitelist configuration setting, but selects the top assets from all available markets (with matching stake-currency) on the exchange.

The refresh_period setting allows to define the period (in seconds), at which the pairlist will be refreshed. Defaults to 1800s (30 minutes).

VolumePairList is based on the ticker data from exchange, as reported by the ccxt library:

  • The quoteVolume is the amount of quote (stake) currency traded (bought or sold) in last 24 hours.
"pairlists": [{
        "method": "VolumePairList",
        "number_assets": 20,
        "sort_key": "quoteVolume",
        "refresh_period": 1800
}],

Note

VolumePairList does not support backtesting mode.

AgeFilter

Removes pairs that have been listed on the exchange for less than min_days_listed days (defaults to 10).

When pairs are first listed on an exchange they can suffer huge price drops and volatility in the first few days while the pair goes through its price-discovery period. Bots can often be caught out buying before the pair has finished dropping in price.

This filter allows freqtrade to ignore pairs until they have been listed for at least min_days_listed days.

PerformanceFilter

Sorts pairs by past trade performance, as follows: 1. Positive performance. 2. No closed trades yet. 3. Negative performance.

Trade count is used as a tie breaker.

Note

PerformanceFilter does not support backtesting mode.

PrecisionFilter

Filters low-value coins which would not allow setting stoplosses.

PriceFilter

The PriceFilter allows filtering of pairs by price. Currently the following price filters are supported:

  • min_price
  • max_price
  • low_price_ratio

The min_price setting removes pairs where the price is below the specified price. This is useful if you wish to avoid trading very low-priced pairs. This option is disabled by default, and will only apply if set to > 0.

The max_price setting removes pairs where the price is above the specified price. This is useful if you wish to trade only low-priced pairs. This option is disabled by default, and will only apply if set to > 0.

The low_price_ratio setting removes pairs where a raise of 1 price unit (pip) is above the low_price_ratio ratio. This option is disabled by default, and will only apply if set to > 0.

For PriceFiler at least one of its min_price, max_price or low_price_ratio settings must be applied.

Calculation example:

Min price precision for SHITCOIN/BTC is 8 decimals. If its price is 0.00000011 - one price step above would be 0.00000012, which is ~9% higher than the previous price value. You may filter out this pair by using PriceFilter with low_price_ratio set to 0.09 (9%) or with min_price set to 0.00000011, correspondingly.

Low priced pairs

Low priced pairs with high "1 pip movements" are dangerous since they are often illiquid and it may also be impossible to place the desired stoploss, which can often result in high losses since price needs to be rounded to the next tradable price - so instead of having a stoploss of -5%, you could end up with a stoploss of -9% simply due to price rounding.

ShuffleFilter

Shuffles (randomizes) pairs in the pairlist. It can be used for preventing the bot from trading some of the pairs more frequently then others when you want all pairs be treated with the same priority.

Tip

You may set the seed value for this Pairlist to obtain reproducible results, which can be useful for repeated backtesting sessions. If seed is not set, the pairs are shuffled in the non-repeatable random order.

SpreadFilter

Removes pairs that have a difference between asks and bids above the specified ratio, max_spread_ratio (defaults to 0.005).

Example:

If DOGE/BTC maximum bid is 0.00000026 and minimum ask is 0.00000027, the ratio is calculated as: 1 - bid/ask ~= 0.037 which is > 0.005 and this pair will be filtered out.

RangeStabilityFilter

Removes pairs where the difference between lowest low and highest high over lookback_days days is below min_rate_of_change. Since this is a filter that requires additional data, the results are cached for refresh_period.

In the below example: If the trading range over the last 10 days is <1%, remove the pair from the whitelist.

"pairlists": [
    {
        "method": "RangeStabilityFilter",
        "lookback_days": 10,
        "min_rate_of_change": 0.01,
        "refresh_period": 1440
    }
]

Tip

This Filter can be used to automatically remove stable coin pairs, which have a very low trading range, and are therefore extremely difficult to trade with profit.

Full example of Pairlist Handlers

The below example blacklists BNB/BTC, uses VolumePairList with 20 assets, sorting pairs by quoteVolume and applies both PrecisionFilter and PriceFilter, filtering all assets where 1 price unit is > 1%. Then the SpreadFilter is applied and pairs are finally shuffled with the random seed set to some predefined value.

"exchange": {
    "pair_whitelist": [],
    "pair_blacklist": ["BNB/BTC"]
},
"pairlists": [
    {
        "method": "VolumePairList",
        "number_assets": 20,
        "sort_key": "quoteVolume",
    },
    {"method": "AgeFilter", "min_days_listed": 10},
    {"method": "PrecisionFilter"},
    {"method": "PriceFilter", "low_price_ratio": 0.01},
    {"method": "SpreadFilter", "max_spread_ratio": 0.005},
    {
        "method": "RangeStabilityFilter",
        "lookback_days": 10,
        "min_rate_of_change": 0.01,
        "refresh_period": 1440
    },
    {"method": "ShuffleFilter", "seed": 42}
    ],

Protections

Beta feature

This feature is still in it's testing phase. Should you notice something you think is wrong please let us know via Discord, Slack or via Github Issue.

Protections will protect your strategy from unexpected events and market conditions by temporarily stop trading for either one pair, or for all pairs. All protection end times are rounded up to the next candle to avoid sudden, unexpected intra-candle buys.

Note

Not all Protections will work for all strategies, and parameters will need to be tuned for your strategy to improve performance.
To align your protection with your strategy, you can define protections in the strategy.

Tip

Each Protection can be configured multiple times with different parameters, to allow different levels of protection (short-term / long-term).

Backtesting

Protections are supported by backtesting and hyperopt, but must be explicitly enabled by using the --enable-protections flag.

Available Protections

Common settings to all Protections

Parameter Description
method Protection name to use.
Datatype: String, selected from available Protections
stop_duration_candles For how many candles should the lock be set?
Datatype: Positive integer (in candles)
stop_duration how many minutes should protections be locked.
Cannot be used together with stop_duration_candles.
Datatype: Float (in minutes)
lookback_period_candles Only trades that completed within the last lookback_period_candles candles will be considered. This setting may be ignored by some Protections.
Datatype: Positive integer (in candles).
lookback_period Only trades that completed after current_time - lookback_period will be considered.
Cannot be used together with lookback_period_candles.
This setting may be ignored by some Protections.
Datatype: Float (in minutes)
trade_limit Number of trades required at minimum (not used by all Protections).
Datatype: Positive integer

Durations

Durations (stop_duration* and lookback_period* can be defined in either minutes or candles). For more flexibility when testing different timeframes, all below examples will use the "candle" definition.

Stoploss Guard

StoplossGuard selects all trades within lookback_period in minutes (or in candles when using lookback_period_candles), and determines if the amount of trades that resulted in stoploss are above trade_limit - in which case trading will stop for stop_duration in minutes (or in candles when using stop_duration_candles). This applies across all pairs, unless only_per_pair is set to true, which will then only look at one pair at a time.

The below example stops trading for all pairs for 4 candles after the last trade if the bot hit stoploss 4 times within the last 24 candles.

"protections": [
    {
        "method": "StoplossGuard",
        "lookback_period_candles": 24,
        "trade_limit": 4,
        "stop_duration_candles": 4,
        "only_per_pair": false
    }
],

Note

StoplossGuard considers all trades with the results "stop_loss", "stoploss_on_exchange" and "trailing_stop_loss" if the resulting profit was negative. trade_limit and lookback_period will need to be tuned for your strategy.

MaxDrawdown

MaxDrawdown uses all trades within lookback_period in minutes (or in candles when using lookback_period_candles) to determine the maximum drawdown. If the drawdown is below max_allowed_drawdown, trading will stop for stop_duration in minutes (or in candles when using stop_duration_candles) after the last trade - assuming that the bot needs some time to let markets recover.

The below sample stops trading for 12 candles if max-drawdown is > 20% considering all trades within the last 48 candles. If desired, lookback_period and/or stop_duration can be used.

"protections": [
      {
        "method": "MaxDrawdown",
        "lookback_period_candles": 48,
        "trade_limit": 20,
        "stop_duration_candles": 12,
        "max_allowed_drawdown": 0.2
      },
],

Low Profit Pairs

LowProfitPairs uses all trades for a pair within lookback_period in minutes (or in candles when using lookback_period_candles) to determine the overall profit ratio. If that ratio is below required_profit, that pair will be locked for stop_duration in minutes (or in candles when using stop_duration_candles).

The below example will stop trading a pair for 60 minutes if the pair does not have a required profit of 2% (and a minimum of 2 trades) within the last 6 candles.

"protections": [
    {
        "method": "LowProfitPairs",
        "lookback_period_candles": 6,
        "trade_limit": 2,
        "stop_duration": 60,
        "required_profit": 0.02
    }
],

Cooldown Period

CooldownPeriod locks a pair for stop_duration in minutes (or in candles when using stop_duration_candles) after selling, avoiding a re-entry for this pair for stop_duration minutes.

The below example will stop trading a pair for 2 candles after closing a trade, allowing this pair to "cool down".

"protections": [
    {
        "method": "CooldownPeriod",
        "stop_duration_candles": 2
    }
],

Note

This Protection applies only at pair-level, and will never lock all pairs globally. This Protection does not consider lookback_period as it only looks at the latest trade.

Full example of Protections

All protections can be combined at will, also with different parameters, creating a increasing wall for under-performing pairs. All protections are evaluated in the sequence they are defined.

The below example assumes a timeframe of 1 hour:

  • Locks each pair after selling for an additional 5 candles (CooldownPeriod), giving other pairs a chance to get filled.
  • Stops trading for 4 hours (4 * 1h candles) if the last 2 days (48 * 1h candles) had 20 trades, which caused a max-drawdown of more than 20%. (MaxDrawdown).
  • Stops trading if more than 4 stoploss occur for all pairs within a 1 day (24 * 1h candles) limit (StoplossGuard).
  • Locks all pairs that had 4 Trades within the last 6 hours (6 * 1h candles) with a combined profit ratio of below 0.02 (<2%) (LowProfitPairs).
  • Locks all pairs for 2 candles that had a profit of below 0.01 (<1%) within the last 24h (24 * 1h candles), a minimum of 4 trades.
"timeframe": "1h",
"protections": [
    {
        "method": "CooldownPeriod",
        "stop_duration_candles": 5
    },
    {
        "method": "MaxDrawdown",
        "lookback_period_candles": 48,
        "trade_limit": 20,
        "stop_duration_candles": 4,
        "max_allowed_drawdown": 0.2
    },
    {
        "method": "StoplossGuard",
        "lookback_period_candles": 24,
        "trade_limit": 4,
        "stop_duration_candles": 2,
        "only_per_pair": false
    },
    {
        "method": "LowProfitPairs",
        "lookback_period_candles": 6,
        "trade_limit": 2,
        "stop_duration_candles": 60,
        "required_profit": 0.02
    },
    {
        "method": "LowProfitPairs",
        "lookback_period_candles": 24,
        "trade_limit": 4,
        "stop_duration_candles": 2,
        "required_profit": 0.01
    }
    ],

You can use the same in your strategy, the syntax is only slightly different:

from freqtrade.strategy import IStrategy

class AwesomeStrategy(IStrategy)
    timeframe = '1h'
    protections = [
        {
            "method": "CooldownPeriod",
            "stop_duration_candles": 5
        },
        {
            "method": "MaxDrawdown",
            "lookback_period_candles": 48,
            "trade_limit": 20,
            "stop_duration_candles": 4,
            "max_allowed_drawdown": 0.2
        },
        {
            "method": "StoplossGuard",
            "lookback_period_candles": 24,
            "trade_limit": 4,
            "stop_duration_candles": 2,
            "only_per_pair": False
        },
        {
            "method": "LowProfitPairs",
            "lookback_period_candles": 6,
            "trade_limit": 2,
            "stop_duration_candles": 60,
            "required_profit": 0.02
        },
        {
            "method": "LowProfitPairs",
            "lookback_period_candles": 24,
            "trade_limit": 4,
            "stop_duration_candles": 2,
            "required_profit": 0.01
        }
    ]
    # ...

Switch to Dry-run mode

We recommend starting the bot in the Dry-run mode to see how your bot will behave and what is the performance of your strategy. In the Dry-run mode the bot does not engage your money. It only runs a live simulation without creating trades on the exchange.

  1. Edit your config.json configuration file.
  2. Switch dry-run to true and specify db_url for a persistence database.
"dry_run": true,
"db_url": "sqlite:///tradesv3.dryrun.sqlite",
  1. Remove your Exchange API key and secret (change them by empty values or fake credentials):
"exchange": {
        "name": "bittrex",
        "key": "key",
        "secret": "secret",
        ...
}

Once you will be happy with your bot performance running in the Dry-run mode, you can switch it to production mode.

Note

A simulated wallet is available during dry-run mode, and will assume a starting capital of dry_run_wallet (defaults to 1000).

Considerations for dry-run

  • API-keys may or may not be provided. Only Read-Only operations (i.e. operations that do not alter account state) on the exchange are performed in the dry-run mode.
  • Wallets (/balance) are simulated.
  • Orders are simulated, and will not be posted to the exchange.
  • In combination with stoploss_on_exchange, the stop_loss price is assumed to be filled.
  • Open orders (not trades, which are stored in the database) are reset on bot restart.

Switch to production mode

In production mode, the bot will engage your money. Be careful, since a wrong strategy can lose all your money. Be aware of what you are doing when you run it in production mode.

Setup your exchange account

You will need to create API Keys (usually you get key and secret, some exchanges require an additional password) from the Exchange website and you'll need to insert this into the appropriate fields in the configuration or when asked by the freqtrade new-config command. API Keys are usually only required for live trading (trading for real money, bot running in "production mode", executing real orders on the exchange) and are not required for the bot running in dry-run (trade simulation) mode. When you setup the bot in dry-run mode, you may fill these fields with empty values.

To switch your bot in production mode

Edit your config.json file.

Switch dry-run to false and don't forget to adapt your database URL if set:

"dry_run": false,

Insert your Exchange API key (change them by fake api keys):

"exchange": {
        "name": "bittrex",
        "key": "af8ddd35195e9dc500b9a6f799f6f5c93d89193b",
        "secret": "08a9dc6db3d7b53e1acebd9275677f4b0a04f1a5",
        ...
}

You should also make sure to read the Exchanges section of the documentation to be aware of potential configuration details specific to your exchange.

Using proxy with Freqtrade

To use a proxy with freqtrade, add the kwarg "aiohttp_trust_env"=true to the "ccxt_async_kwargs" dict in the exchange section of the configuration.

An example for this can be found in config_full.json.example

"ccxt_async_config": {
    "aiohttp_trust_env": true
}

Then, export your proxy settings using the variables "HTTP_PROXY" and "HTTPS_PROXY" set to the appropriate values

export HTTP_PROXY="http://addr:port"
export HTTPS_PROXY="http://addr:port"
freqtrade

Ignoring expired candles

When working with larger timeframes (for example 1h or more) and using a low max_open_trades value, the last candle can be processed as soon as a trade slot becomes available. When processing the last candle, this can lead to a situation where it may not be desirable to use the buy signal on that candle. For example, when using a condition in your strategy where you use a cross-over, that point may have passed too long ago for you to start a trade on it.

In these situations, you can enable the functionality to ignore candles that are beyond a specified period by setting ask_strategy.ignore_buying_expired_candle_after to a positive number, indicating the number of seconds after which the buy signal becomes expired.

For example, if your strategy is using a 1h timeframe, and you only want to buy within the first 5 minutes when a new candle comes in, you can add the following configuration to your strategy:

  "ask_strategy":{
    "ignore_buying_expired_candle_after" = 300 # 5 minutes
    "price_side": "bid",
    // ...
  },

Embedding Strategies

Freqtrade provides you with with an easy way to embed the strategy into your configuration file. This is done by utilizing BASE64 encoding and providing this string at the strategy configuration field, in your chosen config file.

Encoding a string as BASE64

This is a quick example, how to generate the BASE64 string in python

from base64 import urlsafe_b64encode

with open(file, 'r') as f:
    content = f.read()
content = urlsafe_b64encode(content.encode('utf-8'))

The variable 'content', will contain the strategy file in a BASE64 encoded form. Which can now be set in your configurations file as following

"strategy": "NameOfStrategy:BASE64String"

Please ensure that 'NameOfStrategy' is identical to the strategy name!

Next step

Now you have configured your config.json, the next step is to start your bot.