ctubio / Krypto-trading-bot

Self-hosted crypto trading bot (automated high frequency market making) written in C++

Home Page:https://127.0.0.1:3000

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Backtesting

Lazarth opened this issue Β· comments

Hello!

I really like this project, but before trying it on a live market, I would like to backtest it on a demo account/testnet.

I tried to set it up for the HitBtc demo environment, but I did not find a way for it.

Could you please explain to me how can I backtest this bot?
Also, did anyone use this bot to trade, if so, was it worth it?

commented

I used this bot to trade and with some experience it can be quite successful. It takes manual tuning. The issue I ran into is that the exchange APIs kept changing the details of their interface, and the bot couldn't always keep up. I also ran into data that seemed incorrect being delivered to my client via the apis. Due to how licensing is done, it can become expensive to use this bot to trade many different cryptocurrencies or exchanges.

I believe the policy of the project is that backtesting is not to be implemented, and my understanding is that requests for backtesting and additions providing backtesting are to be closed. I do not see any reason for that. Backtesting is a basic feature of a trading bot.

However, the bot uses relatively simple algorithms, and it should be reasonable for one to do manual backtesting to tune some of the parameters.

🐨 looking at https://api.demo.hitbtc.com/v2, should be (im not into sandboxes so i never tested it) with args:

--http https://api.demo.hitbtc.com/api/2 --ws wss://api.demo.hitbtc.com/api/2/ws/public

the main reason for not implementing backtesting is because it requires to duplicate (some) sources or to hijack time/loop functions to work in real and in fake mode

performance is a priority so i dont wanna wrap functions that are called thousands of times a second just to allow fake trading

buuut, now we can have different bots (not just one), so starts to make sense to create a separated bot from the real one with slower backtesting wrappings

By the way, Ctubio, I see that you update this repo frequently. Do you use this program personally? If so, could you please share your settings?

Also, is this really a HFT system? I'm trying to get as close as possible to trading like HFT-using institutions as an individual

im on coinbase since forever but im just a developer not a financial guy

mm i dont think there is any higher frequency system (nor smaller in size) than this; the bots are just extended curl tools with additional args (correct me if im wrong, but other projects are just bloated piles of useless libraries that barely work together).

(:koala: hope you were not referring to another financial term; thats what i understand by high frequency)

i never shared the settings because if i did i would do using source code not comments on issues; the default settings of the bot are mean to help were possible in the understanding of the functionality of the setting itself, not to trade on any specific market (so feel free to change all as you consider).

I see
I'll try to get the demo account working, I want to test it to see how it works and etc, but I'm really looking forward to using this program. I might try using it with a small capital if I can't get the demo environment working.

🐨 a for sure working sandbox is the one of coinbase, with args:

    --http https://api-public.sandbox.pro.coinbase.com
    --ws wss://ws-feed-public.sandbox.pro.coinbase.com
    --fix fix-public.sandbox.pro.coinbase.com:4198

i use to run and fix bots there after testing a bad idea and getting a ban in the real api

Nice! But where do I have to change the API links? I'm having trouble finding the file containing them

🐨 i would put it inside the OPTIONAL_ARGUMENTS var of the K.sh config file (created after make install), the distributed one looks like:

# β–ˆβ–ˆβ–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„
# β–Œ____ .
# β–Œ II ▐_______________________________________________.
# β–ŒΒ―Β―Β―Β― .
# β–ˆ OPTIONAL_ARGUMENTS .
# β–ˆβ–ˆ - Allows a list of arguments (see usage at --help).
# β–ˆβ–ˆ (to avoid to write it always in the command-line).
# β–ˆβ–ˆ .
#OPTIONAL_ARGUMENTS="--colors --autobot --port 3000"
OPTIONAL_ARGUMENTS="--colors --naked --heartbeat"
# β–ˆβ–ˆ .
# β–ˆβ–ˆβ–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„β–„

commented

the main reason for not implementing backtesting is because it requires to duplicate (some) sources or to hijack time/loop functions to work in real and in fake mode

performance is a priority so i dont wanna wrap functions that are called thousands of times a second just to allow fake trading

there's usually a way to use templates or macros to resolve situations like the one you describe, although I understand you've refactored the code to open better approaches

thats for the idea @xloem, im considering currently how to do it (but will take a while yet xD)

🐨 im not sure also from where to grab the historical market data to be used as inputs for the backtesting (appart from allowing user defined custom data); ima search for sources..

commented

The most basic approach to historical data might be to simply log the data the client receives.

Additionally most exchanges I've worked with have an api call for historical data.