Fazer-dxmbot-007


#1

Proposal Name:
fazer-dxmbot-007

Owner:
Fazer as @fazer on discord

Cost:
650 BLOCK(fazer) (development + 24/7 liquidity bot testing, debug, fix, collect stats + add more liquidity to small orders)

Voting:
vote 0df80bbe06533f63d060fff70ba4e79d8488c86ec3bc5375f047c1b64e6fc157 yes

Previous Work:

  • fazer-dxmbot-001
    – discussion and development dxmakerbot 001 has been already done.
    – dxmakerbot 001 can be found at https://github.com/nnmfnwl7/dxmakerbot/tree/fazer_dxmakerbot_update_001

  • fazer-dxmbot-002
    – working on slow development of upcoming features
    – doing support for ppl who are interested in dxmakerbot
    – div by zero bug fix

  • fazer-dxmbot-003
    – working on slow development of upcoming features
    – added add more validations and help messages https://github.com/nnmfnwl7/dxmakerbot/commit/3397670521c511a585beb5d329ab3935d4dec9a0
    – fix dxmakerbot exeption caused by balance-get in case when wallet disconnected https://github.com/nnmfnwl7/dxmakerbot/commit/3397670521c511a585beb5d329ab3935d4dec9a0
    – doing support for ppl who are interested in dxmakerbot
    – merging changes for upcoming dxmakerbot_v3
    – you can find latest version here: https://github.com/nnmfnwl7/dxmakerbot/tree/fazer_dxmakerbot_latest
    – you can find latest beta version here: https://github.com/nnmfnwl7/dxmakerbot/tree/fazer_dxmakerbot_latest_beta
    – dev add reopenfinishednum and reopenfinisheddelay config feature
    – dev add trading boundary config features boundary_*
    – dev upt delayinternal default value from 9 to 3 to increase timers accuracy

  • fazer-dxmbot-004 and fazer-dxmbot-005
    – research, development, testing, bugfixing, support, code refactoring, repeat
    – updated reopenfinished to reopenfinisheddelay and reopenfinishednum - finished orders will be reopened after specific number of filled orders or in specific timeout
    – added static/relative and asset-relative trading price boundaries
    – as easiest explanation, boundary features are very useful when you wanna from dxmakerbot to stop working when price of configured asset goes out of boundary (maximum minimum). Like to prevent selling BLOCK under specific or relative price.
    – all new stuff already in community testing pre-beta, details in commit https://github.com/nnmfnwl7/dxmakerbot/commit/7e164021d6a517b1825f49eb150601f4d4ff0e80

  • fazer-dxmbot-006
    – research, development, testing, bugfixing, support, code refactoring, repeat, 24/7 bot running and analysis, block dx liquidity support
    – working on dynamic spread(slide) feature fix and update. New params --slidedyntype ‘relative’/‘static’ and --slidedynzero for asymetric dynamic spread(slide) balance. Dynamic slide is functionality which can dynamically update slide when market center price still have no action but one side selling/buying already started. As bot detect unbalanced sells/buys it automatically move order price with dynamic slide as is it configured from +0 dynamic slide up to +max dynamic slide at specified amount.
    – updated internal balance measurement as total, reserved=locked by orders, available=left.

PLEASE READ
All next followed features list will be prioritized on the fly by research and development of dxmakerbot.
Updates of this “rolling up” proposal are market as (yyyy.mm)

Overview:

  • rolling up dxmakerbot research & development & testing & bugfixing & readme update & examples & info-graphics & support & repeat

  • there will be probably two dxmakerbots dxmakerbot.py and dxmakerbot_ng.py to stay with compatibility, than code can be merged into official blocknet git repository
    – (2019.12) updated readme for both versions v1 as dxmakerbot.py and v2 as dxmakerbot_v2.py merged at https://github.com/nnmfnwl7/dxmakerbot/tree/fazer_dxmakerbot_latest

  • add save and restore orders from file

  • save orders to db before exit, dxmakerbot session will be able to cancel only session specified orders on reconfig/exit/crash

  • add more dxmakerbot events(exit bot events, reset order events, reopen order events)
    – add trading boundaries, relative by % dxmakerbot session
    – (2020.02) added to alfa
    – add trading boundaries, by static value
    – (2020.02) added to alfa
    – add exit bot at events and cancel/notcancel orders on exit…
    – (2020.02) added to alfa as part of config of trading boundaries exit/noexit, cancel/notcancel orders
    – add --reopenafterfinishdelay, reopen finished orders after delay of last filled order
    – (2020.01 003) added to alfa
    – add --reopenafterfinishnum reopen finished orders after specific number of orders finished
    – (2020.01 003) added to alfa
    – (2020.04) all above in pre-beta and manual testing

  • update configuration verification
    – (2020.01) added add more validations and help messages https://github.com/nnmfnwl7/dxmakerbot/commit/3397670521c511a585beb5d329ab3935d4dec9a0

  • analyze update_balances_unspent() and update_balances_left() possibility

  • 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.

  • add configuration argument --strategy {{},{}}
    – 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}}

“name”:
“sellstart”:
“sellend”:
“selltype”: <float number between -1 and 1. -1 means maximum exponential to 0 means normal to 1 means maxium logarithmic>
“slidestart”:
“slideend”:
“slidetype”: <float number between -1 and 1. -1 means maximum exponential to 0 means normal to 1 means maxium logarithmic>
“maxopen”:
“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>
example of config arg --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}}

  • add configuration file per dxmakerbot instance by --cfg argument
    – Configuration file per bot is more useful
    – configuration files can have private permissions vs. running process arguments are by OS public
    – example of config file representing strategy argument

[strategy]
[[push some normal orders]]
sellstart = 10 # first order in sequence with amount
sellend = 1 # last order in sequence with amount
sellstartlimit = 10 # first made order in sequence can accept this amount
sellendlimit = 1 # last made order in sequence can accept this amount
selltype = 0 # orders amounts are evenly rising

slidestart = 1.10 # first order placed at 1.1 times more than actual price means +10%
slideend": 1.03 # last order placed at 1.03 times more than actual price means +3%
slidetype": 0 # orders prices are evenly rising

maxopen = 10 # including borders and range there will be placed this number of orders. <sell-start, sell-end> <slide-start, slide-end>

reopenfinished = false # <True/False, reopen finished orders or must wait for any reset event>
slide_dyn_enable= false # <True/False, include dynamic slide or not, very useful when not applied on pump orders>
[[push some big orders]]

[[push some pump orders]]

by having parallel staggered orders sequences, it will fix discord discussed “PROBLEM (2)” and also increases parallel market liquidity
PROBLEM (2) Problem related to partial order filing. For example someone have 100 BLOCK for sale, and he creates orders at 33+33+33 or 25 25 50 or he do not think about and creates one order at 100. Problem is that most of time here are thousands of people who are interested in to take that order but are not able to accept it because individuals have funds to buy only 10 10 10 20 20 20 and nobody of them can accept one whole order :frowning:

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

  • PUMP/DUMP auto management

  • autodetect and precompute possible next pump

  • dxtakerbot/dxmakerbot automatically selling all coins of wallet which is detected as going to dump…

  • feature is to automatically compute top price of next pump and cover it.

  • feature to opposite dxbot side to detect pump/dump to disable dxbot to not make a loss.

  • add log exp normal staggered mods
    – add logarithmic/exponential/normal staggered size of orders
    – add logarithmic/exponential/normal staggered price of orders

  • educational examples & info-graphics & video tutorials how to use dxmakerbot

Possible Next Work Expectations:
– Purpose of this proposal is to continue with dxmakerbot research, development, testing, bugfixing, support, code refactoring to finish all above features

I believe that i gives you many reasons to vote up this proposal to continue dxmakerbot development and all stuff around.
Thanks for your time & MTFBWY
Hopefully see you later on upcoming dxmakerbot development.