39 lines
2.8 KiB
Plaintext
Executable File
39 lines
2.8 KiB
Plaintext
Executable File
Mandatory:
|
|
=========
|
|
0. Stats webpage.
|
|
1. Maintain local orderbooks for each trading pair, which enables:
|
|
2a. Smart order pricing: Prioritization of fill speed over instant profit or vice versa
|
|
2. Proper handling of order price too high/low in OKX (rare, it happens when under heavy volatility).
|
|
3. API documentation.
|
|
4. Implement api key hashing.
|
|
5. Dockerize.
|
|
6. Earn should be integrated into the instance, in order to be able to invest the idle funds from the short traders.
|
|
|
|
|
|
Would be nice to have:
|
|
=====================
|
|
0. Trader order: alphabetical; by uptime; by safety orders, by percentage_to_completion. (Although this may be more suitable for the web and mobile apps)
|
|
1. Local implementation of amount_to_precision, cost_to_precision and price_to_precision. (Unless the plan is to continue to use CCXT forever)
|
|
2. Instead of cancelling and resending the take profit order, edit it (Kucoin only supports editing on high frequency orders)
|
|
3. When autoswitching to long, instead of using a big market order, the last safety order should be a sell order of all the available funds.
|
|
4. Round-robin trading pairs: Instead of a fixed list of trading pairs, after n closed deals the trader is terminated and a new one spawns, picking the trading pair
|
|
from a pre-populated list (the trading pairs can be selected by using Yang-Zhang, Parkinson or another volatility indicator)
|
|
This could be very benefitial, since it limits the long time commitment to a small list of trading pairs, enabling the instance to react to market trends very
|
|
rapidly.
|
|
|
|
|
|
Maybe it's a good idea?:
|
|
=======================
|
|
0. A fraction of the take profit order is taken as the first order of the next deal.
|
|
* Starting at the second or third safety order?
|
|
* This would address the issue of big spreads making the first order very expensive.
|
|
* Can be problematic in parabolic runs, unless the take-profit order is not x% above the buy order, but above the current price.
|
|
1. DUSTERS. If a trade is interrupted but the take profit sell order is still open, open another trader (different type, dust-trader, it remembers the original trade)
|
|
that follows that order; when it closes, it takes note of the profit.
|
|
a. The ability to import the dusters after an interruption will be key.
|
|
b. The duster uses the order id as duster id
|
|
c. Order on screen: BASE/QUOTE | order_id followed | current_price | deal_close_price | total_volume_on_close | pct_to_profit | uptime
|
|
d. In status bar: Total funds to be released.
|
|
e. Change main screen: x traders online | y dusters online
|
|
f. Since they only need to monitor if one order is filled and the data is already locally available, there will be no extra API load.
|