Fazer-dxmbot-002


#1

Introduction:
At first sorry for my English, probably some mistakes in text.

I’m thinking and working little bit on next iteration of dxmakerbot development 002.

Proposal Name:
fazer-dxmbot-002

mnbudget vote yes

Owner:
Fazer as @fazer on discord

Cost:
BLOCK(fazer)

Previous Work:
discussion and development dxmakerbot 001 has been already done.

Overview:

  • dxmakerbot.py code needs more research & development:
  • manual testing new features
  • readme file update
  • update dxmakerbot and XBridge API to handle UTXOs
  • add configuration argument --strategy {{},{}}
  • configuration file per dxmakerbot instance implementation
  • save and restore orders from file
  • autodetect and precompute possible next pump
  • educational video tutorials how to use dxmakerbot.
  • exit bot at events and cancel/notcancel orders on exit…

More Details:

  • dxmakerbot.py code needs more research & development
    – there is always something to do

  • manual testing new features
    – new implemented features should be tested before relase

  • readme file update
    – readme file update to correspond new development update

  • update dxmakerbot and XBridge API to handle UTXOs:
    – update XBridge API to work with UTXOs than update dxmakerbot to be more effective to uses whole UTXO with coop of “–sellstart” and “–sellend”
    – We are not sure about if exactly this API calls need, or something like that API calls, this needs more discussion in before proposal:
    First needed XBridge API update is, to dxMakeOrder() be able to create order only from funds specified by dxMakeOrder(…makeraddress…) or THE BEST solution to use funds only from specified UTXO txid like this API call: dxMakeOrder(…makeraddress… txidlist[‘txid1’,‘txid2’]). For this case also new XBridge API call is needed to get ‘listunspent’ from specified coin. This call can be added for example as dxGetTokenBalancesUnspentList(maker, makeraddress) or only maker parameter. Because if dxmakerbot wanna use specific UTXO from XXX-COIN wallet to create order it needs to know UTXOs first. By this API can dxmakerbot be updated to be more specific and also effective by using always whole UTXO values. Also there are more reasons, that you can read in draft of planned proposal below.
    As long as you want to run multiple makerbots with same maker and you wanna save hardware resource by running only one full-wallet from pair, coin addresses needs to be specified separated by makerbot-instance.

  • added configuration argument --strategy {{},{}}
    – this feature adds possibility of bot been configured as staggered hill/valley mods
    – dxmakerbot argument “–strategy” is json-style formated argument specifying sequence of orders.
    This configuration way strategy can be specified like this:
    –strategy {{pump and dump orders place first}, { than push some normal orders}, {at the end strategy with some small orders}}
    – json arguments:
    “name”: <string stratedy name>
    “sellstart”: <float first order amount>
    “sellend”: <float last order amount>
    “selltype”: <float number between -1 and 1. -1 means maximum exponential to 0 means normal to 1 means maxium logarithmic>
    “slidestart”: <float>
    “slideend”: <float>
    “slidetype”: <float number between -1 and 1. -1 means maximum exponential to 0 means normal to 1 means maxium logarithmic>
    “maxopen”: <number>
    “reopenfinished”: <True/False, reopen finished orders or must wait for any reset event>
    “slide_dyn_enable”: <True/False, include dynamic slide or not, very useful when not applied on pump orders>
    – usage example:
    –strategy{{“name”:‘normal’, “sellstart”:3, “sellend”:5, “selltype”:-0.5, “slidestart”:1.02, “slideend”:1.25, “slidetype”:0.6, “maxopen”:10, “reopenfinished”:True, “slide_dyn_enable”:True}, {“name”:‘pump’, “sellstart”:20, “sellend”:50, “selltype”:-0.2, “slidestart”:1.3, “slideend”:10, “slidetype”:0, “maxopen”:10, “reopenfinished”:False, “slide_dyn_enable”:False}}

  • configuration file per dxmakerbot instance implementation
    – Configuration file per bot is more usefull
    – configuration files can have private permissions vs. running process arguments are by OS public

  • save and restore orders from file
    – In case of bot quit/crash to be able to restore

  • autodetect and precompute possible next pump
    – As long as you want to cover price pumps/dumps, there will be “–slidepump” parameter which can be used to specify special “out of range slide” that can cover possible price pumps. Or opposite side bot dumps.
    – Possible next development if this feature is to automatically compute top price of next pump and cover it. Also oposite side to disable bot to not make a loss.

Possible Next Work Expectations:

  • TODO

I believe that i gives you many reasons to vote up this proposal to support this dxmakerbot update 002.
Thanks for your time & MTFBWY
Hopefully see you later on upcoming dxmakerbot development.