-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow multiple orders per coin via configuration #158
Comments
Hmm, interesting. But wouldn't be really risky? If the coin is falling continuously, then you end up using all your money to the single coin, rather than buying multiple coins to ease the risk. What do you think? |
I don't think it will be risky and of course the user is in control. As I said, I think that in-between BUY-SELL cycle there are opportunities that are lost and we can prevent this with multiple orders per coin. I would really like to have this option and congrats for your work. |
Hmm... This feature will be very interesting. Let's say, the bot purchased the coin because it reached the lowest price I can add a cool time for the next buy, but it also should automatically disable stop-loss. Hmm, will this feature be required by many people since you can do it manually? |
I support this idea, for example, im holding BNB, and it has a $ 100,00 as max purchase, but it's used as transaction discount, and I wanna keep buying it even if I already have $ 90,00, if the price drops, buy another $ 10,00 |
Sometimes I find myself doing this manually. This is, once the bot has executed a buy order, I place a manual order directly on Binance and then override the buy price on the bot with the new average. If you really think the coin (or whatever you're trading for that matter) will go up in price eventually, then it is not uncommon to keep buying the dips to average down. I'm not sure if I'd like the bot to do this fully automated though, but it would be cool to have a button or something to place an additional order (perhaps with an option to override the amount) where the bot will repeat the process of chasing down the price and, once executed, then automate the calculation of the new average as I described above. |
@elvishp2006 @piscui @domnuprofesor
I do have a plan to add a manual buy/sell feature - #100
Interesting, so basically you calculate the last buy price manually or just leave it to the last buy price as the initial buy price?
If the feature is added, then it would be optional. I just have few concerns to develop this feature.
Should the interval trading options be multiple? or just single? I will need more advice from you guys. |
@chrisleekr I believe what you're referring to is also called grid trading. Binance has this built in for futures, but with other services like Bitsgap you can do it with spot as well. I've actually been playing with it a bit (you get a 14 day trial) and although it is more hands off, it may take a much longer time to get any significant profits. It makes tons of very small transactions and requires you to allocate greater amounts of money since it places a whole bunch of limit orders (both buy and sell) when the bot starts; anything less than $500 per bot/pair is not really worth it. For me, honestly, your bot works much better. I don't let it run completely in auto-pilot but with a little supervision you can get better results in my opinion. Also:
Probably not. You already track the last buy price, and you know the quantity. With that, plus the new buy's price and quantity you can calculate the overall price average. For example say you initially bought 100 coins at 1.50 USDT.
The only way it wouldn't work is if you added manual buys from the binance interface like I outlined in my previous comment (which I would no longer do if I could do it from within the bot, of course). I hope that helps. |
First, thank you for your great work. It's amazing and very useful.
You could request Trigger percentage, Purchase amount and Number of grids. That last one would be the number of times that trigger will be executed, and Purchase amount could be per grid or total buying amount for all the grids (it should be divided by number of grids to place each order). Maybe you can include this same behavior for selling orders. Requesting Trigger percentage, Selling amount and Number of grids. It would work as buying case, but Selling amount (or total amount for the grid) should be reserved or locked to be able to sell something. I realized that selling orders are for the total amount you have in that currency (limit isn't respected). Of course this options should be optional. |
@piscui @andferno Thanks for your input, guys.
This sounds right. Even for manual recording the last buy price, I can save the balance of the time you record the last buy price.
Good good. So by setting
Things to consider would be:
Sounds right? Let me know if I misunderstood. I will list up all Todo list and make a vote for the next development once I merge in PR 77. |
Happy to contribute @chrisleekr .
That's more advanced that my proposal, but awesome. I was thinking in arithmetic or geometric slicing of the grid, so a number of grids are provided and total amount reserved for the grid is divided automatically into pieces. Percentage used could be the same for all grids (the lower the price is, more cryptos are bought for the same money) or customizable. But being able to edit each grid amount and percentage is great.
As I said, sounds awesome. You have my vote for this. |
I agree with @andferno, this really sounds awesome. It's similar to Bitsgap but with a different approach which in my opinion works better and brings the better of both worlds.
Thank YOU @chrisleekr for you hard work. I can't wait to try all the goodies you have lined up. By the way I've been running #77 for a while and it's looking great. I had to stop using it at first because it crashed a few times and was using a ton of CPU, but whatever you did on the last update fixed both and it's been smooth sailing since. |
Thanks for your input, guys. I really appreciated it. @piscui Interesting. The last commit was just updating the frontend for showing API limit. But hey, it is fixed :yay: |
@chrisleekr I'm sorry it probably wasn't the very last commit, but several commits back. The crashy version didn't have the stop-loss feature so it must have been a commit somewhere between before and after that feature was added that fixed the issues I was having. |
Hey guys, I am still trying to design how to implement this strategy. I did some brainstorming as below. I tried to think easier way to implement, I guess it should be complex because the strategy itself is complex. If you find any issue with the below calculation, please let me know. BuySetting UI
Validation
ScenarioYour 1st grid trading for buying is configured as below:
To make it easier understand, I will use Let's assume the current price is
When the current price is down to the lowest price ($100) and lower than ATH(All Time High) restricted price if enabled, the bot will place new STOP-LOSS-LIMIT order for buying.
Let's assume the market changes as below:
Then the bot will follow the price fall and place new STOP-LOSS-LIMIT order as below:
Let's assume the market changes as below:
Then the bot will execute 1st purchase for the coin. The last buy price will be recorded as Once the coin is purchased, the bot will start monitoring the sell signal or the next grid trading for buying. Your 2nd grid trading for buying is configured as below:
And if the current price is continuously falling to Let's assume the market changes as below:
Then the bot will follow the price fall and place new STOP-LOSS-LIMT order as below:
Let's assume the market changes as below:
Then the bot will execute 2nd purchase for the coin. The last buy price will be automatically re-calculated as below:
SellSetting UI
Unlike buy, the sell setting will use the percentage of a quantity. If you want to sell all of your coin quantity, then simply configure it as 100. Validation
Sell ScenarioFrom the last buy actions, you now have the following balances:
Your 1st grid trading for selling is configured as below:
Let's assume the market changes as below:
As the price is higher than the sell trigger price($87.99), then the bot will place new STOP-LOSS-LIMIT order for selling.
Let's assume the market changes as below:
Then the bot will follow the price rise and place new STOP-LOSS-LIMIT order as below:
Let's assume the market changes as below:
Then the bot will execute 1st sell for the coin. Then the bot will now wait for 2nd selling trigger price ($83.80 * 1.08 = $90.504).
Let's assume the market changes as below:
Then the current price($91) is higher than 2nd selling trigger price ($90.504), the bot will place new STOP-LOSS-LIMIT order as below:
Let's assume the market changes as below:
Then the bot will follow the price rise and place new STOP-LOSS-LIMT order as below:
Let's assume the market changes as below:
Then the bot will execute 2nd sell for the coin. The final profit would be
Symbol configuration
|
@chrisleekr sorry for the late reply, it seems good to me, we can implement like this and test. Since the market is falling, my last buy was more that 14 days ago, and none sell since that, I think with that strategy we can make some profit even with a falling market |
I finished development and I am currently testing the feature. I will push the commit once I think fairly stable. |
@chrisleekr I believe its a very good description of this feature. We'll have to test. I was thinking about some improvements like filling buying and selling table automatically. The only needed information for this would be number of grids, starting percentage, final percentage/spacing/common ratio and arithmetic or geometrical spacing between grids. So if arithmetic, it will calculate percentage this way startPercentage+((finalPercentage-startPercentage)/numGrids)(gridNumber-1) or spacing(commonRatio) could be provided and it will calculate startPercentage+commonRatio(gridNumber-1). If geometric, calculating commonRatio (exp(finalPercentage/startPercentage, numGrids-1)) and multiplying it by current grid percentage (actually it would be the difference from 1 or current price). It's numGrids-1 because we already have startPercentage and finalPercentage values. Don't know if my explanation has any sense. Please comment. |
Hi guys, I have committed the feature to PR #248. Note that when you use this branch, there is a migration running over your current configuration. All the details are described in the PR. |
Let's discuss your strategy after this feature is merged. |
right now the bot operates with only one BUY order per coin followed by an immediate SELL order. If the SELL order gets stuck then potential BUY opportunities may be missed because the bot waits to SELL the previous BUY order.
So I propose to allow for multiple concurrent BUY|SELL orders per coin.
Looking forward to your opinion.
Thanks,
Francisc
The text was updated successfully, but these errors were encountered: