AutoConfig job types
Each job type serves a unique purpose. For instance, if you want to add pairs, you can use the addPairs
job type. If you need to modify settings for a running pair, you can use the manageOverrides
job type. It is important to select the appropriate job type based on the specific task you need to perform.
Gunbot provides different job types that grant access to various data points. Some job types are designed to scan markets for data related to trading pairs that Gunbot is not currently processing. For this purpose, they use ticker data. Other job types are intended for use with pairs that are already running in Gunbot. They utilize data that is already available internally and do not consume extra API usage.
The addPairs
, removePairs2
, and manageOverrides
job types are the most commonly used. These job types enable you to create a comprehensive workflow for adding pairs, managing their settings, and ultimately removing them. In most cases, these job types will suffice for your automation needs.
Job types overview​
Check out the table below for a list of job types. If a job type requests ticker data from the exchange, it's marked as using external data. On the other hand, if a job type uses internal data, it will be faster to execute and consume no API usage. It's best to choose a job type that uses internal data whenever possible for the task you want to automate.
Job types by data source​
External data | Internal data |
---|---|
addPairs | changeDelay |
backtesting | changeStrategy2 |
changeStrategy | manageBotSettings |
collectData | manageOverrides |
manageOverrides2 | removePairs2 |
removePairs |
For job types that require external data, the following exchanges are supported:
binance
binanceFutures
binanceus
bingx
bitget
bybit
cex
coinbase
cryptocom
futures_gunthy
gateio
hitbtc
huobi
kraken
kucoin
mex_gunthy
mexc
okex5
poloniex
Job types by primary function​
Job type | Primary function |
---|---|
addPairs | Add trading pairs to a specific exchange |
backtesting | Simulate an addPairs job using data collected with a collectData job |
changeDelay | Change exchange delay |
changeStrategy changeStrategy2 | Change assigned trading strategy for pairs |
collectData | Collect tickers data for use in a backtesting job |
manageBotSettings | Change Gunbot config.bot settings |
manageOverrides manageOverrides2 | Changes overrides for pairs |
removePairs removePairs2 | Remove active trading pairs |
Details per job type​
Each job type has a number of obligatory parameters, these are described below for each job type. Additionally, there are optional parameters you can use to extend the functionality of a job.
Adding pairs​
Type name in config: addPairs
This job type uses ticker filters.
Job output: add trading pairs to a specific exchange.
Pair options:
include: included pairs (processed first). Any pair on the exchange that matches any of the includes, will be processed. In case you also use the exclude option, the resulting pairs after processing the includes is the starting point for processing excludes, which will remove items from this list of pairs.
Included items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be included. Input as comma separated list, does not accept spaces between items. Can not be empty.
exclude: excluded pairs (processed last). Any pair on the exchange that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
maxPairs: maximum number of allowed pairs. In case a filter action would result in more pairs than this setting, the config will be filled up to the max number of allowed pairs. Only enabled pairs count towards maxPairs.
Other obligatory parameters:​
strategy: this defines the strategy that will be assigned to pairs added by this job. It must be the exact name of an existing strategy in your config.js
file.
snapshots: defines how many ticker snapshots are saved to perform calculations on. Relevant for filter types that include Interval
in their name.
For example: snapshots is set to 10, this means that the ticker data for the last 10 times the job runs are saved and some of the values in it are used for calculating average values over time.
Config example​
The example below shows a job that does the following:
- Scan Binance tickers every minute
- Automatically add BTC-x pairs (but not BTC-DOGE, which is excluded) that have a top 10 volume ranking and for which the bid/ask spread is below 0.2%
- Added pairs get the "gain" strategy assigned
- Allows for up to 25 active trading pairs on Binance
{
"addTopVolumePairs": {
"pairs": {
"exclude": "DOGE",
"include": "BTC-",
"maxPairs": 25,
"exchange": "binance"
},
"filters": {
"filter1": {
"type": "maxVolumeRank",
"max": 11
},
"filter2": {
"type": "maxSpreadPct",
"max": 0.2
}
},
"schedule": "* * * * *",
"snapshots": 1,
"type": "addPairs",
"strategy": "gain"
}
}
Removing pairs​
Type names in config: removePairs
(uses ticker filters) or removePairs2
(uses state filters).
You must have at least one pair set per exchange you use this job type on.
Job output: removes trading pairs from a specific exchange.
Pair options:
exclude: pairs that should not be scanned for possible removal. Any active pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
There is no include options for this filter type. Pairs in your config (that have already cycled in Gunbot) are basically the list of includes.
noBag (true/false): when true, only pairs with a balance below MIN_VOLUME_TO_SELL
that have no open orders and are not in reversal trading, are filtered for possible removal. When set to false, all pairs in config are filtered.
removeDisabled (true/false): when true, each time a removePairs job is ran it will remove all disabled pairs for the exchange the job runs on - regardless of filter settings. Useful, for example, when you use COUNT_SELL
.
Other obligatory parameters:​
snapshots: defines how many ticker snapshots are saved to perform calculations on. Relevant for filter types that include Interval
in their name.
For example: snapshots is set to 10, this means that the ticker data for the last 10 times the job runs are saved and some of the values in it are used for calculating average values over time.
Config example​
The example below shows a job that does the following:
- Scan Binance tickers every ten minutes
- Remove any pair that has has a volume ranking below 20, besides pairs containing BNB or XVG in their name.
- Additionally, remove all disabled pairs from the config.
{
"removeCrap": {
"pairs": {
"exclude": "BNB,XVG",
"noBag": false,
"removeDisabled": true,
"exchange": "binance"
},
"filters": {
"filter1": {
"type": "minVolumeRank",
"min": 20
}
},
"schedule": "*/10 * * * *",
"snapshots": 1,
"type": "removePairs"
}
}
Change strategy​
Type names in config: changeStrategy
(uses ticker filters) or changeStrategy2
(uses state filters).
This job type is basically the same as how removePairs works, but this one changes a pairs strategy instead of removing the pair.
You must have at least one pair set per exchange you use this job type on.
Job output: change assigned trading strategy for pairs on one exchange.
Pair options:
exclude: pairs that should not be scanned for possible removal. Any active pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
There is no include options for this filter type. Pairs in your config (that have already cycled in Gunbot) are basically the list of includes.
bag (true/false): when true, only pairs with a balance below MIN_VOLUME_TO_SELL
that have no open orders and are not in reversal trading, are filtered for possible removal. When set to false, all pairs in config are filtered.
Other obligatory parameters:
strategy: the target strategy to set for pairs matching all filters.
snapshots: defines how many ticker snapshots are saved to perform calculations on. Relevant for filter types that include Interval
in their name.
For example: snapshots is set to 10, this means that the ticker data for the last 10 times the job runs are saved and some of the values in it are used for calculating average values over time.
Config example​
The example below shows a job that does the following:
- Scan Binance tickers every 15 minutes
- Change the assigned strategy for any pair that has below median trading volume, except BTC-LTC
- Assign the strategy "baghandler" to these pairs
{
"changeStrat": {
"pairs": {
"exclude": "BNB-LTC",
"bag": true,
"exchange": "binance"
},
"filters": {
"filter1": {
"type": "belowMedianVolume"
}
},
"schedule": "*/15 * * * *",
"snapshots": 1,
"type": "changeStrategy",
"strategy": "baghandler"
}
}
Managing overrides​
Type name in config: manageOverrides
This job type uses state filters.
Job output: changes overrides for pairs on a specific exchange.
Pair options:
include: included pairs (processed first), can not be empty. Any active trading pair that matches any of the includes, will be processed. In case you also use the exclude option, the resulting pairs after processing the includes is the starting point for processing excludes, which will remove items from this list of pairs.
Included items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be included. Input as comma separated list, does not accept spaces between items. Can not be empty.
exclude: excluded pairs (processed last). Any active trading pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
Other obligatory parameters:
overrides: contain zero or more overrides, these will be set for each pair that passes all filters when a job is executed.
clearOverrides (true/false): when set to true, all existing overrides for a pair are removed before placing the new ones.
Config example​
The example below shows a job that does the following:
- Scan Binance pairs every minute, process filters on all active trading pairs that include "USDT" or "BNB" and do not include "DOGE" or "ETH" in their pair name.
- Set a
DU_BUYDOWN
override for all pairs that haveducount
1
{
"DynamicDU1": {
"pairs": {
"exclude": "DOGE,ETH",
"include": "USDT,BNB",
"exchange": "binance"
},
"filters": {
"ducount": {
"type": "exact",
"ducount": 1
}
},
"overrides": {
"DU_BUYDOWN": 3
},
"clearOverrides": false,
"schedule": "* * * * *",
"type": "manageOverrides"
}
}
Change exchange delay​
Type name in config: changeDelay
This job type uses state filters.
Job output: changes the exchange delay for a specific exchange.
Pair options:
include: included pairs (processed first), can not be empty. Any active trading pair that matches any of the includes, will be processed. In case you also use the exclude option, the resulting pairs after processing the includes is the starting point for processing excludes, which will remove items from this list of pairs.
Included items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be included. Input as comma separated list, does not accept spaces between items. Can not be empty.
exclude: excluded pairs (processed last). Any active trading pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
Other obligatory parameters:
delay: exchange delay in seconds, this value will be set when one or more pairs in the job pass all filters.
Config example​
The example below shows a job that does the following:
- Scan Binance pairs every minute, process filters on all active trading pairs that include "USDT" or "BNB" and do not include "DOGE" or "ETH" in their pair name.
- Set a the exchange delay for Binance to 10 in case at least one pair matches the filter
{
"DynamicDU1": {
"pairs": {
"exclude": "DOGE,ETH",
"include": "USDT,BNB",
"exchange": "binance"
},
"filters": {
"ducount": {
"type": "exact",
"ducount": 1
}
},
"delay": 10,
"schedule": "* * * * *",
"type": "changeDelay"
}
}
Manage bot settings​
Type names in config: manageBotSettings
(uses state filters).
This job type is basically the same as how changeStrategy works, but this type is able to change the global bot settings.
You must have at least one pair set per exchange you use this job type on.
Job output: change assigned parameters in the bot section. Happens when at least one pair passes all filters
Pair options:
exclude: pairs that should not be filtered. Any active pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
There is no include options for this filter type. Pairs in your config (that have already cycled in Gunbot) are basically the list of includes.
Other obligatory parameters:
bot: the target bot settings.
Config example​
{
"botsettings": {
"pairs": {
"exclude": "",
"include": "BTC-",
"exchange": "binance"
},
"filters": {
"price": {
"type": "biggerThan",
"Ask": 0.00000001
}
},
"bot": {
"BOT_DELAY": 20,
"BOT_CCLEAN": 9991
},
"schedule": "* * * * *",
"type": "manageBotSettings"
}
}
Hedge (for Gunbot)​
Type names in config: hedgeGB
(uses ticker filters) or hedgeGB2
(uses state filters).
You must have at least one pair set per exchange you use this job type on.
Job output:
You can define a "hedge pair" like USDT-BTC, between which Gunbot should hedge when the market conditions are right for it. If you prefer hedging between completely other currrencies, like BTC-ETH - you can do that too.
It works with two autoconfig jobs, in which you define when it should hedge and to which currency it should hedge.
- When a pair can be hedged without intermediate pair, autoconfig will change a pair like BTC-ETH to USDT-ETH and panic sell directly to ETH.
- When an intermediate pair is needed, the pair will be panic sold first and then traded on the defined hedge pair.
Pair options:
Pair filtering is hardcoded to the defined hedge pair.
exclude: used as placeholder
bag: used as placeholder
baseFrom: base currency to hedge away from
baseTo: base currency to hedge to
hedgePair: pair used for hedging, like USDT-BTC
Other obligatory parameters:
setVariable: hedging will only work when both hedging jobs set a variable with the currency it last hedged to, this makes sure that the direction can be tracked for the next hedging action.
Config example​
You'll need two jobs to do this, one for each hedging direction:
{
"hedging": {
"pairs": {
"exclude": "",
"exchange": "binance",
"bag": false,
"baseFrom": "BTC",
"baseTo": "USDT",
"hedgePair": "USDT-BTC"
},
"filters": {
"filter1": {
"type": "yourTickerFilter",
"min": "0.0000000001"
},
"filter2": {
"type": "variableNotExist",
"hegdedTo": "BTC"
}
},
"filters2": {
"filter1": {
"type": "yourTickerFilter",
"min": "0.0000000001"
},
"filter2": {
"type": "variableExact",
"hegdedTo": "BTC"
}
},
"setVariable": {
"hegdedTo": "USDT"
},
"strategy": "gain",
"schedule": "1 */4 * * *",
"type": "hedgeGB",
"debug": false
}
}
The second job would be a mirror job, with all hedge currencies reversed.
Two important notes:
- keep the hedge pair in your config at all times, prefably with buy/sell disabled to avoid crossover between base/quote.
- set the filter for "type": "variableNotExist", ONLY in the job that will take care of the next hedging action. For example, when you start out with BTC-x pairs only, add this filter to the job that hedges to USDT.
Hedge (for bitRage)​
Type name in config: hedge
This job type uses state filters.
Job output: initiates hedging in bitRage.
Pair options:
include: included pairs (processed first), can not be empty. Any active trading pair that matches any of the includes, will be processed. In case you also use the exclude option, the resulting pairs after processing the includes is the starting point for processing excludes, which will remove items from this list of pairs.
Included items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be included. Input as comma separated list, does not accept spaces between items. Can not be empty.
exclude: excluded pairs (processed last). Any active trading pair that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
Other obligatory parameters:
hedgeTo (USDT/BTC): defines which currency to start hedging to.
brStrat: defines which strategy is used for bitRage.
Config example​
The example below shows a job that does the following:
- Scan for a user variable, every minutes
- Once this variable is found, it places filteredBase, filteredQuote and filteredPair blocks as defined in the job, for kucoin (this part is optional)
- Once this variable is found, it makes the following changes in the strategy
bitrageStrat
, it sets/changes the following parameters so that hedging will start:
"AUTOSELL": true,
"MAIN_BASE": "USDT",
"BR_PANIC_SELL": true,
{
"Hedge_to_USDT": {
"pairs": {
"exclude": "",
"include": "",
"exchange": "kucoin",
"filteredBase": [
"TUSD",
"PAX",
"KCS",
"NUSD",
"ETH",
"DAI",
"USDC",
"TRX",
"NEO",
"BTC"
],
"filteredQuote": [
"GGC"
],
"filteredPair": [
"BTC-GGC",
"USDT-GGC",
"BTC-KCS",
"USDT-KCS",
"KCS-XRP",
"KCS-EOS",
"KCS-LTC",
"KCS-NEO",
"KCS-MTV",
"KCS-GO",
"KCS-CS",
"ETH-KCS",
"NEO-EOS",
"DAI-BTC",
"DAI-ETH",
"DAI-MKR",
"DAI-USDT"
]
},
"filters": {
"variable": {
"type": "variableExact",
"readyToHedge": "USDT"
}
},
"setVariable": {
"hedgingStarted": true
},
"schedule": "* * * * *",
"type": "hedge",
"hedgeTo": "USDT",
"brStrat": "bitrageStrat"
},
}
Filtered quote (for bitRage)​
Type name in config: filteredQuote
This job type uses ticker filters.
Job output: It adds the quote of each pair passing all filters to the filteredQuote list. Each time the job runs, the list gets completely replaced with the new results.
Pair options:
include: included pairs (processed first). Any pair on the exchange that matches any of the includes, will be processed. In case you also use the exclude option, the resulting pairs after processing the includes is the starting point for processing excludes, which will remove items from this list of pairs.
Included items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be included. Input as comma separated list, does not accept spaces between items. Can not be empty.
exclude: excluded pairs (processed last). Any pair on the exchange that matches any of the excludes, won't be processed.
Excluded items do not need to be whole pair names, as long as part of the string matches an actual pair, it will be excluded. Input as comma separated list, does not accept spaces between items. Can be empty.
Config example​
The example below would do the following:
- scan all binance BTC-x pairs
- find pairs with a bid/ask spread higher than 0.7%
- save the quote coins from these pairs in the filteredQuote list.
{
"filteredQuote": {
"pairs": {
"include": "BTC-",
"exclude": "",
"exchange": "binance"
},
"filters": {
"spread": {
"type": "minSpreadPct",
"min": 0.7
},
"schedule": "* * * * *",
"type": "filteredQuote",
"debug": false
}
}
Optional parameters​
Optional Parameter | Possible Values | Job Type(s) | Description |
---|---|---|---|
enabled | true/false | All job types | When false, the job is disabled and won't be executed. |
debug | true/false | All job types | When true, the job generates detailed logs in the console for each filter. |
settings for user variables | - | All job types | Allows for configuration of user-defined variables. |
brStrat | - | All job types (specifically for bitRage) | Defines which strategy is used for bitRage. Only needed if you use Autoconfig to automate hedging for bitRage. |
resume | true/false | Jobs using ticker filters | When true, saved ticker snapshots are loaded from file after Gunbot restarts. When false, history needs to be built up again after restarting. |
history | - | Jobs using ticker filters | Defines how many ticker entries should be kept in storage. |
historyInterval | - | Jobs using ticker filters | Defines the minimum interval in minutes between history entries. |
setITB | true/false | addPairs and manageOverrides | When true, each pair matching all filters will get an additional IGNORE_TRADES_BEFORE override, the value being the timestamp for the time the job ran. For manageOverrides only. |
delay | time in seconds | manageOverrides | When set, the exchange delay gets adjusted to the specified value when at least one pair passes all filters. |
overrides | - | addPairs | This job type can also add overrides when it adds new pairs. To do so, add a section with overrides to the job, just like you would in a manageOverrides job. |
noCrossOver | true/false | addPairs (specifically for bitRage) | When set, Autoconfig will never add two pairs with different Base but the same Quote currency. |
removeBase | - | removePairs | Can be used to remove all pairs from a specified base currency that use the bitRage strategy specified in brStrat. This is useful to clean out pairs from a specific base after hedging. |
notRemoveBefore | value in minutes | removePairs | Don't remove pairs from config if it's not in the config longer than specified. |
Bitrage filters | - | hedge | When used for Bitrage, you can have an addPairs job replace the contents of the exchange filter settings. To do so, add the filteredQuote, filteredPair and filteredBase filters in the pair section of the job. |
Backtesting for addPairs jobs​
Results for addPairs jobs can be simulated using ticker data you've collected yourself. Self-collection is needed because the type of historic data AutoConfig uses is not publicly available.
Before you can backtest, you need to collect a dataset with a "collectData" job. This is a simple autoconfig job that collects and saves ticker data according to the job schedule and exchange.
"30-secs": {
"pairs": {
"exchange": "binance"
},
"schedule": "*/30 * * * * *",
"type": "collectData",
"snapshots": 1000,
"enabled": true,
"debug": false
}
The schedule in this job should be the same as the schedule you'd use in an addPairs
job. It will collect up to 5 ticker snapshots and removes older snapshots in case they exist.
You can use any number of snapshots in this job type. If you omit the snapshots parameter, it will collect ticker snapshots for as long as your system has free disk space.
Ticker data for this collection job is saved in /30-secs-tickers (#jobname#-tickers). Do make sure you never save any other files in this folder.
As long as the collectData
job runs, it keeps collecting tickers. It is not recommended to permanently collect tickers while also running other autoconfig jobs that use tickers: API usage weight is relatively high, and it will slow down Gunbot performance slightly.
To backtest using the collected data, run a job with type backtesting
. Do this while you have Gunbot core and other autoconfig jobs disabled, because it's very cpu intensive and you don't want other jobs to interrupt.
A backtesting job is basically the same as an addPairs job, you can use all available filter / filterset options. Collected ticker data is replayed as if it were live data, the results should 100% match the results from a regular addPairs job. Results are logged the same way as regular jobs, the debug option for jobs is also available. "History" ticker snapshots can be used as well, these are built up in RAM while running through a backtest.
Results are saved to a .csv file that lists when pairs would have been added, and what the ask price was at that moment.
Backtesting jobs also use the autoconfig scheduler, although it's kind of pointless. It's recommended to set a silly schedule that will almost never execute and use the "onStart": true
option so that the job runs as soon as it gets enabled.
Backtesting does not take maxPairs
into consideration (and will not in the future), results are purely based on the filters you use.
Job example for backtesting:
"30-secs": {
"pairs": {
"exclude": "",
"include": "BTC-",
"exchange": "binance"
},
"filters": {
"slope": {
"type": "minSlopePctInterval",
"min": 0.02
},
"volume": {
"type": "minVolume24h",
"min": 75
},
"pricehistory0": {
"type": "maxPricePctChangeIntervalHistory",
"max": 5,
"historySource": 9
}
},
"schedule": "1 1 1 1 1",
"type": "backtesting",
"tickersFolder": "30-secs-tickers",
"enabled": true,
"onStart": true,
"history": 10,
"historyInterval": 2,
"debug": false,
"snapshots": 10
}
The data source for backtesting is set with the "tickersFolder"
parameter. Set it to the exact folder name where your collected ticker files are. i
Various​
- You can schedule multiple jobs for the same time, but if more than one job causes a configuration change, only the first to finish will apply its changes. The others must wait for another chance.
- Each job updates the config.js file, which always triggers a Gunbot restart.
- If you need detailed console log output for your filters, you can add
debug: true
to your job. However, use this option sparingly because it can significantly slow down Gunbot performance due to the large amount of data logged to the console. - AutoConfig may crash if you change the exchange for a ticker filtering job while using
resume: true
, or if you use a non-existent key in a state filter, among other things. - Pair state data for filtering is available from either exchange tickers or internal Gunbot memory. You can find information about which pair state data to filter on in the pairs state file located in the Gunbot /json folder.
- If you don't want Telegram notifications for a specific job, include
muteTG: true
in that job. - You can filter almost any key/value pair in pair state files as long as they're on the first level and not inside additional arrays or objects. Use a custom filter if you need to access nested values.