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. Proper handling of order price too high/low in OKX (rare, it happens when under heavy volatility).
4. Multiple safety orders open at the same time (to catch big volatility spikes more effectively)
5. Things that should be objects (it's not 1994):
    * Orders.
    * Config (Mostly done).
    * Status (Mostly done).
6. API documentation.
7. Implement api key hashing.
8. Dockerize.
9. Cache generated status strings, only recalculate when prices change.


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.