46 lines
3.2 KiB
Plaintext
Executable File
46 lines
3.2 KiB
Plaintext
Executable File
Mandatory:
|
|
=========
|
|
1. Stats webpage.
|
|
2. Maintain local orderbooks for each trading pair, which enables:
|
|
2a. Smart order pricing: Prioritization of fill speed over instant profit or vice versa
|
|
3. Consolidate vocabulary (trader, pair and bot; instance & trader)
|
|
4. Base add for short traders.
|
|
5. Proper handling of order price too high/low in OKX (rare, it happens when under heavy volatility).
|
|
6. Multiple safety orders open at the same time (to catch big volatility spikes more effectively)
|
|
7. Things that should be objects (it's not 1994):
|
|
* Orders.
|
|
* Config (parameter validation remains to be implemented).
|
|
* Status (parameter validation remains to be implemented).
|
|
8. Implement the ability to add safety orders to a short trader depending on the amount of free funds available, not just any number of orders.
|
|
9. API documentation.
|
|
10. Bug when switching quote currency: when switching from USDT to USDC, status script keeps querying for base/USDT.
|
|
|
|
|
|
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, you could just edit it (Kucoin only supports editing on high frequency orders)
|
|
3. 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.
|
|
4. Earn should also use funds from short traders.
|
|
4b. Should Earn be integrated to the instance?
|
|
|
|
|
|
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.
|