Plugins

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, SpreadFilter and VolatilityFilter 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 can define either StaticPairList, VolumePairList, ProducerPairList, RemotePairList or MarketCapPairList 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

• StaticPairList (default, if not configured differently)
• VolumePairList
• ProducerPairList
• RemotePairList
• MarketCapPairList
• AgeFilter
• FullTradesFilter
• OffsetFilter
• PerformanceFilter
• PrecisionFilter
• PriceFilter
• ShuffleFilter
• SpreadFilter
• RangeStabilityFilter
• VolatilityFilter

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.

When used in a "follow-up" position (e.g. after VolumePairlist), all pairs in 'pair_whitelist' will be added to the end of the pairlist.

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 in the leading position of the chain of Pairlist Handlers, the pair_whitelist configuration setting is ignored. Instead, VolumePairList 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). The pairlist cache (refresh_period) on VolumePairList is only applicable to generating pairlists. Filtering instances (not the first position in the list) will not apply any cache (beyond caching candles for the duration of the candle in advanced mode) and will always use up-to-date data.

VolumePairList is per default 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",
        "min_value": 0,
        "refresh_period": 1800
    }
],

You can define a minimum volume with min_value - which will filter out pairs with a volume lower than the specified value in the specified timerange.

VolumePairList Advanced mode

VolumePairList can also operate in an advanced mode to build volume over a given timerange of specified candle size. It utilizes exchange historical candle data, builds a typical price (calculated by (open+high+low)/3) and multiplies the typical price with every candle's volume. The sum is the quoteVolume over the given range. This allows different scenarios, for a more smoothened volume, when using longer ranges with larger candle sizes, or the opposite when using a short range with small candles.

For convenience lookback_days can be specified, which will imply that 1d candles will be used for the lookback. In the example below the pairlist would be created based on the last 7 days:

"pairlists": [
    {
        "method": "VolumePairList",
        "number_assets": 20,
        "sort_key": "quoteVolume",
        "min_value": 0,
        "refresh_period": 86400,
        "lookback_days": 7
    }
],

Range look back and refresh period

When used in conjunction with lookback_days and lookback_timeframe the refresh_period can not be smaller than the candle size in seconds. As this will result in unnecessary requests to the exchanges API.

Performance implications when using lookback range

If used in first position in combination with lookback, the computation of the range based volume can be time and resource consuming, as it downloads candles for all tradable pairs. Hence it's highly advised to use the standard approach with VolumeFilter to narrow the pairlist down for further range volume calculation.

Unsupported exchanges

On some exchanges (like Gemini), regular VolumePairList does not work as the api does not natively provide 24h volume. This can be worked around by using candle data to build the volume. To roughly simulate 24h volume, you can use the following configuration. Please note that These pairlists will only refresh once per day.

"pairlists": [
    {
        "method": "VolumePairList",
        "number_assets": 20,
        "sort_key": "quoteVolume",
        "min_value": 0,
        "refresh_period": 86400,
        "lookback_days": 1
    }
],

More sophisticated approach can be used, by using lookback_timeframe for candle size and lookback_period which specifies the amount of candles. This example will build the volume pairs based on a rolling period of 3 days of 1h candles:

"pairlists": [
    {
        "method": "VolumePairList",
        "number_assets": 20,
        "sort_key": "quoteVolume",
        "min_value": 0,
        "refresh_period": 3600,
        "lookback_timeframe": "1h",
        "lookback_period": 72
    }
],

Note

VolumePairList does not support backtesting mode.

ProducerPairList

With ProducerPairList, you can reuse the pairlist from a Producer without explicitly defining the pairlist on each consumer.

Consumer mode is required for this pairlist to work.

The pairlist will perform a check on active pairs against the current exchange configuration to avoid attempting to trade on invalid markets.

You can limit the length of the pairlist with the optional parameter number_assets. Using "number_assets"=0 or omitting this key will result in the reuse of all producer pairs valid for the current setup.

"pairlists": [
    {
        "method": "ProducerPairList",
        "number_assets": 5,
        "producer_name": "default",
    }
],

Combining pairlists

This pairlist can be combined with all other pairlists and filters for further pairlist reduction, and can also act as an "additional" pairlist, on top of already defined pairs. ProducerPairList can also be used multiple times in sequence, combining the pairs from multiple producers. Obviously in complex such configurations, the Producer may not provide data for all pairs, so the strategy must be fit for this.

RemotePairList

It allows the user to fetch a pairlist from a remote server or a locally stored json file within the freqtrade directory, enabling dynamic updates and customization of the trading pairlist.

The RemotePairList is defined in the pairlists section of the configuration settings. It uses the following configuration options:

"pairlists": [
    {
        "method": "RemotePairList",
        "mode": "whitelist",
        "processing_mode": "filter",
        "pairlist_url": "https://example.com/pairlist",
        "number_assets": 10,
        "refresh_period": 1800,
        "keep_pairlist_on_failure": true,
        "read_timeout": 60,
        "bearer_token": "my-bearer-token",
        "save_to_file": "user_data/filename.json" 
    }
]

The optional mode option specifies if the pairlist should be used as a blacklist or as a whitelist. The default value is "whitelist".

The optional processing_mode option in the RemotePairList configuration determines how the retrieved pairlist is processed. It can have two values: "filter" or "append". The default value is "filter".

In "filter" mode, the retrieved pairlist is used as a filter. Only the pairs present in both the original pairlist and the retrieved pairlist are included in the final pairlist. Other pairs are filtered out.

In "append" mode, the retrieved pairlist is added to the original pairlist. All pairs from both lists are included in the final pairlist without any filtering.

The pairlist_url option specifies the URL of the remote server where the pairlist is located, or the path to a local file (if file:/// is prepended). This allows the user to use either a remote server or a local file as the source for the pairlist.

The save_to_file option, when provided with a valid filename, saves the processed pairlist to that file in JSON format. This option is optional, and by default, the pairlist is not saved to a file.

Multi bot with shared pairlist example

save_to_file can be used to save the pairlist to a file with Bot1:

"pairlists": [
    {
        "method": "RemotePairList",
        "mode": "whitelist",
        "pairlist_url": "https://example.com/pairlist",
        "number_assets": 10,
        "refresh_period": 1800,
        "keep_pairlist_on_failure": true,
        "read_timeout": 60,
        "save_to_file": "user_data/filename.json" 
    }
]

This saved pairlist file can be loaded by Bot2, or any additional bot with this configuration:

"pairlists": [
    {
        "method": "RemotePairList",
        "mode": "whitelist",
        "pairlist_url": "file:///user_data/filename.json",
        "number_assets": 10,
        "refresh_period": 10,
        "keep_pairlist_on_failure": true,
    }
]

The user is responsible for providing a server or local file that returns a JSON object with the following structure:

{
    "pairs": ["XRP/USDT", "ETH/USDT", "LTC/USDT"],
    "refresh_period": 1800
}

The pairs property should contain a list of strings with the trading pairs to be used by the bot. The refresh_period property is optional and specifies the number of seconds that the pairlist should be cached before being refreshed.

The optional keep_pairlist_on_failure specifies whether the previous received pairlist should be used if the remote server is not reachable or returns an error. The default value is true.

The optional read_timeout specifies the maximum amount of time (in seconds) to wait for a response from the remote source, The default value is 60.

The optional bearer_token will be included in the requests Authorization Header.

Note

In case of a server error the last received pairlist will be kept if keep_pairlist_on_failure is set to true, when set to false a empty pairlist is returned.

MarketCapPairList

MarketCapPairList employs sorting/filtering of pairs by their marketcap rank based of CoinGecko. It will only recognize coins up to the coin placed at rank 250. The returned pairlist will be sorted based of their marketcap ranks.

"pairlists": [
    {
        "method": "MarketCapPairList",
        "number_assets": 20,
        "max_rank": 50,
        "refresh_period": 86400
    }
]

number_assets defines the maximum number of pairs returned by the pairlist. max_rank will determine the maximum rank used in creating/filtering the pairlist. It's expected that some coins within the top max_rank marketcap will not be included in the resulting pairlist since not all pairs will have active trading pairs in your preferred market/stake/exchange combination.

refresh_period setting defines the period (in seconds) at which the marketcap rank data will be refreshed. Defaults to 86,400s (1 day). The pairlist cache (refresh_period) is applicable on both generating pairlists (first position in the list) and filtering instances (not the first position in the list).

AgeFilter

Removes pairs that have been listed on the exchange for less than min_days_listed days (defaults to 10) or more than max_days_listed days (defaults None mean infinity).

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 and listed before max_days_listed.

FullTradesFilter

Shrink whitelist to consist only in-trade pairs when the trade slots are full (when max_open_trades isn't being set to -1 in the config).

When the trade slots are full, there is no need to calculate indicators of the rest of the pairs (except informative pairs) since no new trade can be opened. By shrinking the whitelist to just the in-trade pairs, you can improve calculation speeds and reduce CPU usage. When a trade slot is free (either a trade is closed or max_open_trades value in config is increased), then the whitelist will return to normal state.

When multiple pairlist filters are being used, it's recommended to put this filter at second position directly below the primary pairlist, so when the trade slots are full, the bot doesn't have to download data for the rest of the filters.

Backtesting

FullTradesFilter does not support backtesting mode.

OffsetFilter

Offsets an incoming pairlist by a given offset value.

As an example it can be used in conjunction with VolumeFilter to remove the top X volume pairs. Or to split a larger pairlist on two bot instances.

Example to remove the first 10 pairs from the pairlist, and takes the next 20 (taking items 10-30 of the initial list):

"pairlists": [
    // ...
    {
        "method": "OffsetFilter",
        "offset": 10,
        "number_assets": 20
    }
],

Warning

When OffsetFilter is used to split a larger pairlist among multiple bots in combination with VolumeFilter it can not be guaranteed that pairs won't overlap due to slightly different refresh intervals for the VolumeFilter.

Note

An offset larger than the total length of the incoming pairlist will result in an empty pairlist.

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.

You can use the minutes parameter to only consider performance of the past X minutes (rolling window). Not defining this parameter (or setting it to 0) will use all-time performance.

The optional min_profit (as ratio -> a setting of 0.01 corresponds to 1%) parameter defines the minimum profit a pair must have to be considered. Pairs below this level will be filtered out. Using this parameter without minutes is highly discouraged, as it can lead to an empty pairlist without a way to recover.

"pairlists": [
    // ...
    {
        "method": "PerformanceFilter",
        "minutes": 1440,  // rolling 24h
        "min_profit": 0.01  // minimal profit 1%
    }
],

As this Filter uses past performance of the bot, it'll have some startup-period - and should only be used after the bot has a few 100 trades in the database.

Backtesting

PerformanceFilter does not support backtesting mode.

PrecisionFilter

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

Backtesting

PrecisionFilter does not support backtesting mode using multiple strategies.

PriceFilter

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

• min_price
• max_price
• max_value
• 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 max_value setting removes pairs where the minimum value change is above a specified value. This is useful when an exchange has unbalanced limits. For example, if step-size = 1 (so you can only buy 1, or 2, or 3, but not 1.1 Coins) - and the price is pretty high (like 20$) as the coin has risen sharply since the last limit adaption. As a result of the above, you can only buy for 20$, or 40$ - but not for 25$. On exchanges that deduct fees from the receiving currency (e.g. binance) - this can result in high value coins / amounts that are unsellable as the amount is slightly below the limit.

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 PriceFilter 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.

By default, ShuffleFilter will shuffle pairs once per candle. To shuffle on every iteration, set "shuffle_frequency" to "iteration" instead of the default of "candle".

    {
        "method": "ShuffleFilter", 
        "shuffle_frequency": "candle",
        "seed": 42
    }

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. ShuffleFilter will automatically detect runmodes and apply the seed only for backtesting modes - if a seed value is set.

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 or above max_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% or >99%, remove the pair from the whitelist.

"pairlists": [
    {
        "method": "RangeStabilityFilter",
        "lookback_days": 10,
        "min_rate_of_change": 0.01,
        "max_rate_of_change": 0.99,
        "refresh_period": 86400
    }
]

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. Additionally, it can also be used to automatically remove pairs with extreme high/low variance over a given amount of time.

VolatilityFilter

Volatility is the degree of historical variation of a pairs over time, it is measured by the standard deviation of logarithmic daily returns. Returns are assumed to be normally distributed, although actual distribution might be different. In a normal distribution, 68% of observations fall within one standard deviation and 95% of observations fall within two standard deviations. Assuming a volatility of 0.05 means that the expected returns for 20 out of 30 days is expected to be less than 5% (one standard deviation). Volatility is a positive ratio of the expected deviation of return and can be greater than 1.00. Please refer to the wikipedia definition of volatility.

This filter removes pairs if the average volatility over a lookback_days days is below min_volatility or above max_volatility. Since this is a filter that requires additional data, the results are cached for refresh_period.

This filter can be used to narrow down your pairs to a certain volatility or avoid very volatile pairs.

In the below example: If the volatility over the last 10 days is not in the range of 0.05-0.50, remove the pair from the whitelist. The filter is applied every 24h.

"pairlists": [
    {
        "method": "VolatilityFilter",
        "lookback_days": 10,
        "min_volatility": 0.05,
        "max_volatility": 0.50,
        "refresh_period": 86400
    }
]

Full example of Pairlist Handlers

The below example blacklists BNB/BTC, uses VolumePairList with 20 assets, sorting pairs by quoteVolume and applies PrecisionFilter and PriceFilter, filtering all assets where 1 price unit is > 1%. Then the SpreadFilter and VolatilityFilter 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": 86400
    },
    {
        "method": "VolatilityFilter",
        "lookback_days": 10,
        "min_volatility": 0.05,
        "max_volatility": 0.50,
        "refresh_period": 86400
    },
    {"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 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.

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.

Setting protections from the configuration

Setting protections from the configuration via "protections": [], key should be considered deprecated and will be removed in a future version. It is also no longer guaranteed that your protections apply to the strategy in cases where the strategy defines protections as property.

Available Protections

• StoplossGuard Stop trading if a certain amount of stoploss occurred within a certain time window.
• MaxDrawdown Stop trading if max-drawdown is reached.
• LowProfitPairs Lock pairs with low profits
• CooldownPeriod Don't enter a trade right after selling a trade.

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). If trade_limit or more trades resulted in stoploss, 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.

Similarly, this protection will by default look at all trades (long and short). For futures bots, setting only_per_side will make the bot only consider one side, and will then only lock this one side, allowing for example shorts to continue after a series of long stoplosses.

required_profit will determine the required relative profit (or loss) for stoplosses to consider. This should normally not be set and defaults to 0.0 - which means all losing stoplosses will be triggering a block.

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.

@property
def protections(self):
    return [
        {
            "method": "StoplossGuard",
            "lookback_period_candles": 24,
            "trade_limit": 4,
            "stop_duration_candles": 4,
            "required_profit": 0.0,
            "only_per_pair": False,
            "only_per_side": 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 pairs - with a minimum of trade_limit trades - within the last 48 candles. If desired, lookback_period and/or stop_duration can be used.

@property
def protections(self):
    return  [
        {
            "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).

For futures bots, setting only_per_side will make the bot only consider one side, and will then only lock this one side, allowing for example shorts to continue after a series of long losses.

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.

@property
def protections(self):
    return [
        {
            "method": "LowProfitPairs",
            "lookback_period_candles": 6,
            "trade_limit": 2,
            "stop_duration": 60,
            "required_profit": 0.02,
            "only_per_pair": False,
        }
    ]

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".

@property
def protections(self):
    return  [
        {
            "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 2 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.

from freqtrade.strategy import IStrategy

class AwesomeStrategy(IStrategy)
    timeframe = '1h'

    @property
    def protections(self):
        return [
            {
                "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
            }
        ]
    # ...