Future Development

WIP

Up to you. Fork it, make it your own. Things I'm considering:

• Understanding/addressing if exchange's min-trade quantity needs accounting for in coverage.
• There should be a way, even if reading from the db, to chill the trader during large downturns (determine 'no-trade' zones). It would come back in at lower prices where its stack would go further and per-trade profits would be higher. This may make coverage less meaningful as a funds protection mechanism, and could be somewhat of an overhaul.
• crypto-crypto trading
• Automate 'sell off' profit taking
• Dynamic PI, or BDI, or COVERAGE, or some combination of them. Could read from the db to see if the market is sideways by looking at the timestamp diff between sold orders(?). Maybe a 1 to 1 of time-as-percent to percent-increase/decrease-of-appetite. Increasing the profit interval as price is falling can stack per trade gains such that earlier sell orders at lower intervals execute prior to later ones.
• Data collection/Machine learning hooks on dynamic settings, or even static with multiple instances.
• Monthly closeout/archiving of db. Pending sells carry over. This can be manual at first.
• Looks like /fills is always accurate after /order/:id returns the order filled. Perhaps it's reasonable to update the code so the buy side is reconciled immediately after buy order execution is confirmed. A possible wrinkle is that the requested price - not the executed price - may need to be passed on the new reconciling logic so that the dip is smoothly bought.
• Modes for algorithms - 1) Set Q and Profit 2) Set BDI and PI (current)
• Modes for algorithm recalc - 1) Each buy 2) Each sell (current) 3) never
• No need to log no sells_executed (or even check if there are not pending sells)
• partial_fills aren't really partial fills anymore since Q is dynamic. Consider nomenclature change.