At first sorry for my English, probably some mistakes in text.
As you may already know, we spend some time with dxmakerbot research & development & also in development using some know how from previous bots. As long as bitshares network is going to be completely KYC’ed, we rather move bot development to project which have potential to grow. As you know we want to give this bot to Blocknet community and also continue with bot development later, implementing new features and also maybe development dxtakerbot. But as you know this takes our energy and time and this equals money and BlockDEX is now at low liquidity, and if there is someone who wants to increase liquidity or wanna just trade to make some profit he must use bots which have some logic and useful features. And here our ideas come.
If we continue with development, we had previous research that XBridge API is not enough compatible with logic we want to implement to dxmakerbot. This is our first proposal that is enough compatible with actual XBridge API, but in next proposal we need some more Blocknet dev cooperation.
Possible next development and next proposal needs XBridge api call update or new API calls. There only 2 needed:
We are not sure about if exactly this API calls need, or something like that API calls, this needs more discussion in next 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.
If you see this as possible please continue reading with proposal draft, otherwise thanks for your time
We are not sure but in draft we also marked atsecure, because previous communication, also nice from him would be to do some “code review” and “commit” into github.
As we already done some development and running/testing dxmakerbot, right after proposal pass will be accessible to public as beta also alfa updates by mega.co.nz service.
[Proposal(Draft) to improve dxmakerbot #1]
mnbudget vote 77f1310aea23cdae36ef6bebfb2f0b9cf86e2192b3fd331f4b3d57c46736e640 yes
Fazer as @fazer on discord
Some develppment/discussion has been already done.
dxmakerbot.py code needs more research & development & testing:
-dxmakerbot refactoring to make code reusable and as easy to understand as it can be for next development.
-some new basic features implement
-manual testing new features
-readme file update
-dxmakerbot.py and other dependency python/readme files delivery to blocknet team.
All Features by arguments:
- –makeraddress (added to specify address by dxmakerbot session)
- –makeraddress (added to specify address by dxmakerbot session)
- –sellmin (using only this value of order size)
- –sellmax (temporary disabled)
- –slidestart (slide min and max were deleted and replaced by this)
- –slideend (slide min and max were deleted and replaced by this)
- –maxopen (just little bit updated)
- –reopenfinished (added)
- –balancesavenumber (added)
- –balancesavepercent (added)
- –slidedynpositive (added)
- –slidedynnegative (added)
- –slidedynzoneignore (added)
- –slidedynzonemax (added)
- –slidepump (added)
- –resetonpricechangepositive (added)
- –resetonpricechangenegative (added)
- –resetafterdelay (added)
- –resetafterorderfinishnumber (added)
- –resetafterorderfinishdelay (added)
- –delayinternal (added)
- –delaycheckprice (added)
Makerbot is just piece of simple source code now. It does not use logic, but only simple random generation of orders.
Let me explain case-by-case/feature-by-feature why this proposal is needed, why to update dxmakerbot as hybrid special featured bot.
By hybrid meaning staggered, static + dynamic spreads(slide), pump/dump covering, reset orders events and…
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.
For example you wanna run BLOC->BTC and BLOCK-LTC bot, for this case there will be “–makeraddress” and “–takeraddress” config argument.
For this case XBridge API must be somehow updated. First needed XBridge API update is, to dxMakeOrder() be able to create order only from funds specified by dxMakeOrder(…makeraddress…) or better solution to use funds only from specified UTXO txid like 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. Fully suport of this feature comes with Proposal to improve dxmakerbot #2
As long as you wanna run multiple makerbots like in previous case (BLOC->BTC and BLOCK-LTC), there are many reasons why every bot instance must know which orders belong and not belong to running instance.
To fix this, virtual orders internal database per dxbot is needed. This feature is also preparing bot for next features like to save running open orders in case of bot quit/crash.
Bot previously uses “–slidemin” and “–slidemax” and was placing orders-price randomly in that range.
For been bot more flexible this two parameters has been renamed to “–slidestart” and “–slideend”.
Let me explain how this works. Start dna End can be used in conjunction if your bot have or not have enough funds to place all “–maxopen” orders count. As long as you specify slidestart higher value, bot will place higher orders first.
For example “–slidemin 10 --slidemax 1 --maxopen 5”: first order placed at price 10, than middle equally spaced orders and last order at price 1.
As long as you want or do not want to finished orders be reopened or not, there will be “–reopenfinished” config argument. This can be useful when uptrend is expected and staggered bot.
As long as you want to always save same minimal specific amount of your coins, there will be “–balancesavenumber” config argument.
As long as you want to save profit made by makerbot as percentual meaning of both pairs, there will be “–balancesavepercent” config argument.
As long as makerbot needs to dynamically react on uptrend and downtrend of your pair, by selling with higher and more higher slide on price going up, with expectation that every uptrend is followed by at least small downtrend,
there was special algorithm developed and previously privately long-term used on bitshares network by patched DEXBOT by us. And now coming to Blocknet makerbot. This features were called “custom dynamic parameters”, and one of these features was
“custom dynamic spread”(or you want to call it custom dynamic slide) based on maker/taker balance. By this feature some new config arguments has been added to dxmakerbot: “slidedynpositive” “slidedynnegative” “slidedynzoneignore” “slidedynzonemax”.
slidedynzoneignore parameter means is percent meaning when custom dynamic slide is not applied.
slidedynzonemax parameter means is percent meaning when custom dynamic slide is applied at maximum
slidedynpositive uptrend applied dynamic slide
slidedynnegative oposite side bot applied dynamic slide, that expects following downtrend
Be aware of: if you using this feature you need to start 1:1 value of your trading pair or you must be 100% sure what you are doing.
Default parameters means this feature is disabled.
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.
As long as you want to reset all orders when price changes in percentual meaning, there will be “–resetonpricechangepositive” and “–resetonpricechangenegative” config argument.
Two asymmetric on price change configuration are very useful if you expect price goes only up or only down or very little corrections in price gonna happen.
As long as you want to reset all orders on specific timeout, there will be “–resetafterdelay” config argument.
As long as you want to reset all orders after bot reaching some finished orders, there will be “–resetafterorderfinishnumber” config argument. Very usefull if you have multiple staggered orders with conjunction with next “–resetafterorderfinishdelay”.
As long as you want to run timer after last finished order and than reset all orders, there will be “–resetafterorderfinishdelay” config argument. If your staggered orders start to pass, you can set em timeout to wait for next pass or reset orders.
As long as have internet connection or some other latency problems you want to wait for internal bot operations processing, there will be “–delayinternal” config argument.
As long as you wanna specify how often to check pricing also case to price provider not thread you like spammer, there will be “–delaycheckprice” config argument.
All this new features makes dxmakerbot less limited to be configured as your many wishes are.
Example of dxmakerbot usecases:
liquidity/trading bots -> to increate liquidity of blockdx decentralized exchnage and earn some coins
automatically selling all staked/mined coins
custom bots configured by external financial analysis systems…
I believe that i gives you many reasons for vote up this proposal to support this new dxmakerbot update.
Possible Next Work Expectations:
Possible next development:
- as this is research&development do more code refactoring
- configuration file per dxmakerbot instance implementation
- save orders to db before exit, dxmakerbot session will be able to cancel only session specified orders on reconfig/exit/crash
- update XBridge API to work with UTXOs than update dxmakerbot to be more effective to uses whole UTXO with coop of “–sellmin” and “–sellmax”
- 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.
- staggered hill/valley mods
- educational video tutorials how to use dxmakerbot.
- exit bot at events and cancel/notcancel orders on exit…
Thanks for your time & MTFBWY
Hopefully see you later on upcoming dxmakerbot development.