sample_trader.cfg

# Sample config file for the kelp bot

# the trading account, this is the account that "owns" the trades (GCB7WIQ3TILJLPOT4E7YMOYF6A5TKYRWK3ZHJ5UR6UKD7D7NJVWNWIQV)
TRADING_SECRET_SEED="SAOQ6IG2WWDEP47WEJNLIU27OBODMEWFDN6PVUR5KHYDOCVCL34J2CUD"
# (optional) the source account, this is the account used to deduct fees and consume the sequence number (GBHXGGUD3LIAWJHFO7737C4TFNDDDLZ74C6VBEPF5H53XNRCVIUWZA5I)
SOURCE_SECRET_SEED="SDDAHRX2JB663N3OLKZIBZPF33ZEKMHARX362S737JEJS2AX3GJZY5LU"

# the base asset and issuer.
ASSET_CODE_A="XLM"
# uncomment the ISSUER_A if your base asset is not XLM
#ISSUER_A=""

# the counter (or quote) asset and issuer
ASSET_CODE_B="COUPON"
ISSUER_B="GBMMZMK2DC4FFP4CAI6KCVNCQ7WLO5A7DQU7EC7WGHRDQBZB763X4OQI"
# Issuer seed: SANPCJHHXCPRN6IIZRBEQXS5M3L2LY7EYQLAVTYD56KL3V7ABO4I3ISZ

# how often you want the bot to run, specified in seconds (deprecated, use TICK_INTERVAL_MILLIS instead)
#TICK_INTERVAL_SECONDS=300
# how often you want the bot to run, specified in milliseconds. This allows us to be more precise than specifying in seconds
# (if TICK_INTERVAL_MILLIS is specified then it will override TICK_INTERVAL_SECONDS)
TICK_INTERVAL_MILLIS=300000
# randomized interval delay in millis
MAX_TICK_DELAY_MILLIS=0
# sleep mode is one of "begin" or "end".
#   - begin: sleeps at the beginning of each update (except first update, to avoid an initial run delay)
#   - end: sleeps at the end of each update (including first update)
# default value is "end", even if left unspecified
#SLEEP_MODE="end"

# the mode to use when submitting - maker_only, both (default)
# when trading on a non-SDEX exchange the only supported mode is "both"
SUBMIT_MODE="both"

# how many continuous errors in each update cycle can the bot accept before it will delete all offers to protect its exposure and then intentionally crash.
# the bot will continue running if it hits an error, but will crash if it reaches the condition to delete all offers.
#
# Note: this number has to be exceeded for all the offers to be deleted and any error will be counted only once per update cycle.
# any time the bot completes a full run successfully this counter will be reset.
#
# Note: the typical use case for this config value is to keep the orders on your orderbook intact if your price feed is unreachable for a small amount of time.
# example: use -1 if you never want to delete all offers (this is not recommended).
# example: use 0 if you want to delete all offers on any error.
# example: use 2 if you want to tolerate 2 continuous update cycles with errors, i.e. 3 continuous update cycles with errors will delete all offers.
DELETE_CYCLES_THRESHOLD=0

# how many milliseconds to sleep before checking for fills again, a value of 0 disables background fill tracking. Note that fill tracking can still be
# enabled before the update cycle with the SYNCHRONIZE_STATE_LOAD_ENABLE config field
# Note: in most cases you are probably better off tracking fills at the beginning of the update cycle only (by setting SYNCHRONIZE_STATE_LOAD_ENABLE to true)
#       although there is a valid use case to still want to track fills every X milliseconds in addition to using the new config, for example when you want a
#       faster response to trades, such as with the mirror strategy.
FILL_TRACKER_SLEEP_MILLIS=150000
# how many continuous errors in each fill-tracking cycle can the bot accept before it will delete all offers to protect its exposure.
# this number has to be exceeded for all the offers to be deleted and any error will be counted only once per cycle.
# any time the bot completes a full run successfully this counter will be reset.
# the bot will continue running even if it hits an error or deletes all offers.
# the typical use case for this config value is to keep the orders on your orderbook intact if you the endpoint to read fills is unreachable for a small amount of time.
# example: use -1 if you never want to delete all offers (this is not recommended).
# example: use 0 if you want to delete all offers on any error.
# example: use 2 if you want to tolerate 2 continuous cycles with errors, i.e. 3 continuous cycles with errors will delete all offers.
# Note that this will only fail the bot when running in background mode. If it fails when run before the update cycle (SYNCHRONIZE_STATE_LOAD_ENABLE=true) then the failure
# will be counted in the DELETE_CYCLES_THRESHOLD limit
FILL_TRACKER_DELETE_CYCLES_THRESHOLD=0
# enable this flag to perform a synchronization check when loading balances, offers, and trades at the beginning of every update cycle
# this requires explicitly setting the SYNCHRONIZE_STATE_LOAD_MAX_RETRIES config below
#SYNCHRONIZE_STATE_LOAD_ENABLE=true
# when SYNCHRONIZE_STATE_LOAD_ENABLE is set to true then this value will set the number of retry attempts before counting the update as a failure. This needs to be an integer >= 0
#SYNCHRONIZE_STATE_LOAD_MAX_RETRIES=1
# uncomment if we want to override what is used as the last trade cursor when loading filled trades
# Note that this is used as the optional override if SYNCHRONIZE_STATE_LOAD_ENABLE is set to true or if FILL_TRACKER_SLEEP_MILLIS is > 0
#FILL_TRACKER_LAST_TRADE_CURSOR_OVERRIDE="1570415431000"

# the url for your horizon instance. If this url contains the string "test" then the bot assumes it is using the test network.
HORIZON_URL="https://horizon-testnet.stellar.org"

# the URL to use for your CCXT-rest instance. Defaults to http://localhost:3000 if unset
#CCXT_REST_URL="http://localhost:3000"

# uncomment both feeds below to enable single-unit denominated account value calculations (base asset, quote asset, and USD)
# (optional) establish a price for the base asset to be used when doing total account value calculations, should be denominated in USD
#DOLLAR_VALUE_FEED_BASE_ASSET="exchange:kraken/XXLM/ZUSD/mid"
# (optional) establish a price for the quote asset to be used when doing total account value calculations, should be denominated in USD
#DOLLAR_VALUE_FEED_QUOTE_ASSET="fixed:1.0"

# uncomment below to add support for monitoring.
# type of alerting system to use, currently only "PagerDuty" is supported.
#ALERT_TYPE="PagerDuty"
#ALERT_API_KEY=""

# the port that the monitoring server should run on. Uncomment the following line to add monitoring server.
#MONITORING_PORT=8081

# tls certificate for the server to use if HTTPS is desired. If left empty, then the monitoring server will default to
# HTTP. A valid certificate and key file can be obtained from a Certificate Authority - an example of one is Let's Encrypt.
# If you would like to generate one for local testing, you can run `mkcert localhost` (mkcert can be installed on MacOs and Linux).
# Note that this does NOT allow you to run a publicly-accessible TLS server and is for local development only.
#MONITORING_TLS_CERT="./localhost.pem"
# tls key for the cert. If left empty, then the server will default to HTTP.
#MONITORING_TLS_KEY="./localhost-key.pem"

# If you would like to use Google OAuth for the monitoring server, you have to register your app with Google
# and request a client ID and secret. For more info see: https://developers.google.com/identity/protocols/OAuth2.
# When you register, you MUST configure the Authorized redirect URIs to something of the
# form "https://[hostname]:[MONITORING_PORT]/_googleauth". For testing locally, you can set it to "https://localhost:[PORT]/_googleauth"
# This gives the ability to secure monitoring endpoints by forcing clients to sign in using their Google accounts,
# and only acceptable emails will be allowed access (see below).
#GOOGLE_CLIENT_ID=""
#GOOGLE_CLIENT_SECRET=""
# a comma-separated list of emails (Google accounts) that are allowed access to monitoring endpoints that require
# Google authentication.
#ACCEPTABLE_GOOGLE_EMAILS=""

# minimum values for Kraken: https://support.kraken.com/hc/en-us/articles/205893708-What-is-the-minimum-order-size-volume-
# minimum order value for Binance: https://support.binance.com/hc/en-us/articles/115000594711-Trading-Rule
# (optional) number of decimal units to be used for price, which is specified in units of the quote asset, to place an order on the non-sdex (centralized) exchange
#CENTRALIZED_PRICE_PRECISION_OVERRIDE=6
# (optional) number of decimal units to be used for volume, which is specified in units of the base asset, to place an order on the non-sdex (centralized) exchange
#CENTRALIZED_VOLUME_PRECISION_OVERRIDE=1
# (optional) minimum volume of base units needed to place an order on the non-sdex (centralized) exchange
#CENTRALIZED_MIN_BASE_VOLUME_OVERRIDE=30.0
# (optional) minimum volume of quote units needed to place an order on the non-sdex (centralized) exchange
#CENTRALIZED_MIN_QUOTE_VOLUME_OVERRIDE=10.0

# this is the account_id in the trades table of the database. This is required if you enable the POSTGRES_DB field below for tracking fills.
# On SDEX you can set this to the public key of the account above.
# For now we read this config to set the account_id for simplicity becasue we do not have any way from the API to fetch the account_id from centralized exchanges.
# For centralized exchanges we've considered using a hash of the EXCHANGE_API_KEY but two keys can point to the same account so it won't work for our purpose here.
# Important:
#   Do not change this field once set for a given trading account, otherwise there will be an inconsistency in the database which may break the trading algorithms
#   which depend on this field to function correctly.
#DB_OVERRIDE__ACCOUNT_ID="account1"

# uncomment lines below to use kraken. Can use "sdex" or leave out to trade on the Stellar Decentralized Exchange.
# can alternatively use any of the ccxt-exchanges marked as "Trading" (run `kelp exchanges` for full list)
# You will likely need to enable the EXCHANGE_PARAMS and EXCHANGE_HEADERS fields below, depending on the exchange
#TRADING_EXCHANGE="kraken"

####################################################################################################
############################## ALL LISTS AND OBJECTS BELOW THIS LINE ###############################
####################################################################################################

# uncomment to include these filters in order (these filters only work with sell strategy for now)
# these are the only filters available for now via this new filtration method and any new filters added will include a
# corresponding sample entry with an explanation.
# the best way to use these filters is to uncomment the one you want to use and update the price (last param) accordingly.
#FILTERS = [
#    # The first param can be "volume" or "price" or "priceFeed". Below we descrive the details of the "volume" filter.
#    # The second param for a volume filter can only be "daily", since we only support daily limits for now. Daily limits start the
#    #     count at 00:00:00 UTC. This is independent of your locale, i.e. the local time of your machine is not considered since we
#    #     use the time in UTC format when calculating the day cutoff.
#    #     See below for details and examples on adding modifiers to the "daily" param.
#    # The third param can be either "sell" or "buy":
#    #     - "sell" indicates that we constrain against offers that sell the base asset. This is the total sold amount and is not
#    #        netted against buys. i.e. if you sell 5 units of the base asset and buy 2 units of the base asset then the limit is
#    #        on 5 and NOT on 3 (5 - 2 = 3).
#    #     - "buy" indicates that we constrain against offers that buy the base asset. This is the total bought amount and is not
#    #        netted against sells. i.e. if you buy 5 units of the base asset and sell 2 units of the base asset then the limit is
#    #        on 5 and NOT on 3 (5 - 2 = 3).
#    # The fourth param can be either "base" or "quote". See https://github.com/stellar/kelp/issues/623 for more details:
#    #     - "base" indicates that we keep count in terms of the base asset value. So selling 5 units of the base asset at a price
#    #        of 2.5 equals a count of 5. Similarly, buying 5 units of the base asset at a price of 2.5 equals a count of 5.
#    #     - "quote" indicates that we keep count in terms of the quote asset value. So selling 5 units of the base asset at a price
#    #        of 2.5 equals a count of 12.5 (5 * 2.5). Similarly, buying 5 units of the base asset at a price of 2.5 equals a count
#    #        of 12.5 (5 * 2.5).
#    # The fifth param is the limit. The limit is treated based on the previous params as described above.
#    # The sixth param can be either "exact" or "ignore" ("exact" is recommended):
#    #     - "exact" indicates that the volume filter should modify the amount of the offer that will cause the capacity limit
#    #        to be exceeded (when daily sold amounts are close to the limit). This will result in the exact number of units of
#    #        the asset to be sold for the given day.
#    #     - "ignore" indicates that the volume filter should not modify the values of any offer and the offer which will cause
#    #        the capacity limit to be exceeded should be dropped or ignored. This will result in a less than or equal amount
#    #        of the asset to be sold for the given day.
#    # the example below limits the amount of the base asset that is traded every day, denominated in units of the base asset (needs POSTGRES_DB)
#    "volume/daily/sell/base/3500.0/exact",
#
#    # the example below limits the amount of the base asset that is sold every day, denominated in units of the quote asset (needs POSTGRES_DB)
#    "volume/daily/sell/quote/1000.0/exact",
#
#    # the example below includes additional markets in the filter
#    #        market_ids is an array whose values are market_ids from the postgres database.
#    #        in the example below, we will consider the daily volume from the markets 4c19915f47 and db4531d586, in addition to the local
#    #        market, and limit the sum of the total across these markets to the limit specified in the filter string.
#    #        It's the user's responsibility to ensure that each market_id corresponds to the asset pair and exchange they want included.
#    #        You can query the "markets" table in Postgres with `SELECT * from markets;` to get the list of registered markets.
#    "volume/daily:market_ids=[4c19915f47,db4531d586]/sell/base/3500.0/exact",
#
#    # the example below includes specific accountIDs in the filter.
#    #        account_ids is an array whose values are account_ids from the postgres database.
#    #        in the example below, we will consider the daily volume from the accounts 'account1' and 'account2' only. If this is left
#    #        unspecified or empty then it includes all accounts.
#    #        It's the user's responsibility to ensure that each account_id corresponds to the asset pair and exchange they want included.
#    "volume/daily:account_ids=[account1,account2]/sell/base/3500.0/exact",
#
#    # the example below includes the markets AND accountsIDs modifier in the filter. Same explanation for the above examples apply here
#    #        This functions as an AND operation across both modifiers
#    "volume/daily:market_ids=[4c19915f47,db4531d586]:account_ids=[account1,account2]/sell/base/3500.0/exact",
#
#    # This is an example of the "price" filter. The price filter with the second param as "min" limits orders based on a minimim price requirement
#    #    - this is the minimum price at which to sell. By setting this filter you do not want to sell at a LOWER (i.e. WORSE) price than this.
#    #    - this is the minimum price at which you are willing to buy. By setting this filter you do not want to buy at a LOWER (i.e. BETTER) price than this, whatever your reason may be.
#    "price/min/0.04",
#
#    # This is an example of the "price" filter. The price filter with the second param as "max" limits orders based on a maximum price requirement
#    #    - this is the maximum price at which to sell. By setting this filter you do not want to sell at a HIGHER (i.e. BETTER) price than this, whatever your reason may be.
#    #    - this is the maximum price at which you are willing to buy. By setting this filter you do not want to buy at HIGHER (i.e. WORSE) price than this.
#    "price/max/1.00",
#
#    # This is an example of the "priceFeed" filter. The priceFeed filter limits orders based on a reference price from any priceFeed.
#    # this "priceFeed" filter uses the format: priceFeed/<comparisonMode>/<feedDataType>/<feedURL>
#    # and only allows prices "outside" the reference price.
#    # i.e. gte/gt for sell offers or lte/lt for buy offers based on the comparisonModes options defined:
#    #     - "outside-exclude" - keeps offers that are greater than the reference price for sell offers;
#    #                           keeps offers that are less than the reference price for buy offers.
#    #     - "outside-include" - keeps offers that are greater than or equal to the reference price for sell offers;
#    #                           keeps offers that are less than or equal to the reference price for buy offers.
#    # Note: the feedURL specified at the end of this filter may have its own "/" delimiters which is ok.
#    "priceFeed/outside-exclude/exchange/kraken/XXLM/ZUSD/mid",
#    "priceFeed/outside-include/exchange/kraken/XXLM/ZUSD/mid",
#]

# specify parameters for how we compute the operation fee from the /fee_stats endpoint
[FEE]
# trigger when "ledger_capacity_usage" in /fee_stats is >= this value
CAPACITY_TRIGGER=0.8
# percentile computation to use from /fee_stats (10, 20, ..., 90, 95, 99)
PERCENTILE=90
# max fee in stroops per operation to use
MAX_OP_FEE_STROOPS=5000

# uncomment if you want to track fills in a postgres db (this requires the DB_OVERRIDE__ACCOUNT_ID config field above)
# if you want to enable fill tracking then the FILL_TRACKER_SLEEP_MILLIS should be non-zero
#[POSTGRES_DB]
#HOST="localhost"
#PORT=5432
#DB_NAME="kelp"
#USER=""
#PASSWORD=""
#SSL_ENABLE=false

# you can use multiple API keys to overcome rate limit concerns for kraken
#[[EXCHANGE_API_KEYS]]
#KEY=""
#SECRET=""
#[[EXCHANGE_API_KEYS]]
#KEY=""
#SECRET=""

# if your ccxt based exchange requires additional parameters during initialization, list them here
# Note that this is only used during initialization of the ccxt instance
# Note that some CCXT exchanges require additional parameters
#     e.g. coinbase pro requires a "password"
#[[EXCHANGE_PARAMS]]
#PARAM="password"
#VALUE="<coinbasepro-api-passphrase-here>"
#[[EXCHANGE_PARAMS]]
#PARAM=""
#VALUE=""

# if your exchange requires additional parameters as http headers, list them here (only ccxt supported currently)
# e.g., coinbase pro requires CB-ACCESS-KEY, CB-ACCESS-SIGN, CB-ACCESS-TIMESTAMP, and CB-ACCESS-PASSPHRASE
#[[EXCHANGE_HEADERS]]
#HEADER="CB-ACCESS-KEY"
#VALUE="STATIC:<coinbasepro-api-key-here>"
#[[EXCHANGE_HEADERS]]
#HEADER="CB-ACCESS-SIGN"
#VALUE="COINBASEPRO__CB-ACCESS-SIGN:<coinbasepro-api-secret-here>"
#[[EXCHANGE_HEADERS]]
#HEADER="CB-ACCESS-TIMESTAMP"
#VALUE="TIMESTAMP:"             # leave the value as "TIMESTAMP:" for coinbasepro
#[[EXCHANGE_HEADERS]]
#HEADER="CB-ACCESS-PASSPHRASE"
#VALUE="STATIC:<coinbasepro-passphrase-here>"
#[[EXCHANGE_HEADERS]]
#HEADER=""
#VALUE=""