where is the actual strategy defined?
The strategy is defined essentially by how you configure the bot, and stored in the mariadb database (note: Mariadb is required, MySQL is not supported due to reliance on SHOW VARIABLES LIKE "in_transaction" which is not available in MySQL).
The trade_repeater table has the following columns:
+----------------------+---------------------+------+-----+---------------------+-------------------------------+ | Field | Type | Null | Key | Default | Extra | +----------------------+---------------------+------+-----+---------------------+-------------------------------+ | id | int(10) unsigned | NO | PRI | NULL | auto_increment | | is_enabled | tinyint(1) unsigned | NO | MUL | 0 | | | is_error | tinyint(1) unsigned | NO | MUL | 0 | | | status | varchar(25) | NO | MUL | NULL | | | symbol | varchar(12) | NO | | NULL | | | buy_client_order_id | varchar(100) | YES | | NULL | | | buy_order_id | varchar(30) | YES | | NULL | | | buy_amount | varchar(50) | NO | | NULL | | | buy_price | varchar(50) | NO | | NULL | | | sell_client_order_id | varchar(100) | YES | | NULL | | | sell_order_id | varchar(30) | YES | | NULL | | | sell_amount | varchar(50) | NO | | NULL | | | sell_price | varchar(50) | NO | | NULL | | | note | text | YES | | NULL | | | meta | text | YES | | NULL | | | updated_at | timestamp | NO | | current_timestamp() | on update current_timestamp() | +----------------------+---------------------+------+-----+---------------------+-------------------------------+ At a high level, the bot will: - place buy orders for the given symbol, purchasing the given buy_amount at the given buy_price. - once that buy order fills, it turns around and places a corresponding sell order, selling given sell_amount at sell_price - once that sell order fills, it turns around and simply does repeats the process over again.
I'm handwaving at certain details. For example there is defensive logic checks in place in the event that the HTTP message to the exchange is sent, and by chance your power goes out (or any other problem for that matter) before the exchange responds and informs the bot that the order was succesffully placed.
How well does it perform over HODL?
This is entirely dependent on market conditions and your own configuration choices. If (insert coin name here) doubles in price in a short timeframe, the bot probably wouldn't win out over HODLing. If (insert coin name here) bounces up and down within a given price range for months on end, this is exactly what the bot was made for and will perform quite well.
However, I can say that my personal strategy is kinda "do a bit of both". Going back to the table description above, we notice there is both buy_amount and sell_amount. The reason being, is we can configure the bot to walk away with 100% Quote currency for profits in a sale, or (as close as we can get to) 100% Base currency for profits in a given sale.
I'll explain in a hypothetical scenario:
- Buy 1 BTC @ $50,000 BTC/USD
- Sell 1 BTC @ $60,000 BTC/USD
- Gemini's fee for maker orders at lowest volumn trading tier is 0.001% (10 Base Percentage Points)
- Profit: $9,890 USD, 0 BTC
OR we could have configured the bot to walk away with BTC (for the purpose of HODLing) as profits, maximum amount of BTC we can keep in the above scenario has to:
- Sell enough to still cover fees on the buy order
- Sell enough to still cover fees on the sell order
- Sell enough to recover the original amount necessary for the buy order (so we can keep trading)
Therefore, if we're aiming to HODL as much BTC as we can, and keep trading, we can (in the above scenario) keep up to 0.16499833 BTC and still recover all the costs of the transactions plus repeat the original buy to keep on wave-trading. This would yield the following profits:
- 0.16499833 BTC
- 0.0000998 USD (Gemini does not round anything, ever, they retain your full balance to the exact amount, so yes we did in fact earn a fraction of a cent)
Obviously inserting a much of orders into this table would be a pain in the ass. So there's a command to help facilitate generating these records:
./bin/gemini repeater:ppg -- {symbol} {amount_to_buy} {start_price} {end_price} {amount_to_increase_in_price_between_each_buy_order} {percentage_of_price_increase_for_sell_order} {amount_to_save_from_original_buy_order}
(PPG = "Price Point Generator")
Regarding the {amount_to_increase_in_price_between_each_buy_order} argument, this can be configured to be either a hard amount, or by percentage (I prefer to use percentages). Example (the -i 1 is the flag to use percentage price increase between buy orders):
./bin/gemini repeater:ppg -i 1 -- btcusd 0.0001 20000 70000 0.01 1.05 0.000002
The above command yields the following summary for what it would create (there's a "confirm" param to actually insert the records into the db)
+----------------------+----------+ | First Order | +----------------------+----------+ | Price (Buy) | 20000 | | Price (Sell) | 21000 | | Amount (Buy) | 0.0001 | | Required usd for Buy | 2.007 | | Amount (Sell) | 0.000098 | | Profit BTC | 0.000002 | | Profit USD | 0.053942 | +----------------------+----------+ +----------------------+--------------+ | Last Order | +----------------------+--------------+ | Price (Buy) | 69373.66 | | Price (Sell) | 72842.35 | | Amount (Buy) | 0.0001 | | Required usd for Buy | 6.961646781 | | Amount (Sell) | 0.000098 | | Profit BTC | 0.000002 | | Profit USD | 0.1871083837 | +----------------------+--------------+ +--------------------+----------------+ | Price Point Summary | +--------------------+----------------+ | Buy Amount | 0.0001 | | Buy Price Start | 20000 | | Buy Price End | 70000 | | Sell After Gain | 1.05 | | Save Amount | 0.000002 | | Increment Config | 0.01 | | Order Count | 126 | | BTC Buy Amount | 0.0126 | | USD Amount w/ Fees | 502.4323187865 | | BTC Sell Amount | 0.012348 | | BTC Total Profits | 0.000252 | | USD Total Profits | 13.50389938296 | +--------------------+----------------+ So with roughly $500, we'd create - 126 individual orders - between the buy price of $20,000 BTC/USD, up to $70,000 BTC/USD. - Each buy order would initially be for 0.0001 BTC - Each sell order would be for 0.000098 BTC - We'd profit 0.000002 BTC with every sell order - The amount of USD we'd profit with each sell order always varies, but for the above would be anywhere between 5 cents and 18 cents per sell order.
There is other variances here as well. For example Bitcoin has never reached $69K (the buy price of the last order). But the bot would go ahead and purchase the 0.0001 necessary for this record at whatever the price the market is currently at since the market is currently below this. Therefore, at the time that order sells, there's actually more USD profit than that 18 cents.
Now, if the price were to (in a single move) drop from 70K to 20K, and jump back up to 73K (roughly the price of the last sell order), obviously there is a LOT more money to be had than what this bot would make. Like a stupid amount more could be made. But that's simply not what this bot is intended for. It dumbly wave trades volatile assests as their price flows up and down in a given range. Since computers have infinite patience, this takes human emotions out of the decision making process of when to sell. Also since computers can easily run 24/7, it can also place thousands of orders a day where a human cannot.
I started the bot up in production for the first time on Jan 9th. Since then, I've executed close to 50,000 individual sell orders accross 24 trading pairs. Sometimes I earn maybe 25 cents a sell order. Sometimes I earn half a cent. Always also stashing away a little bit of the coin traded to for long term HODL plans.
I like to think of it as the program from the movie office space on sterioids. Collecting those fractions of a cent :)
Wow... I should slap all this above on the repo's README lol...
No comments:
Post a Comment