[FEATURE REQUEST]: Multi-tickers maker orders

[tonymorony]

Lets say I have RICK and my wish as a maker is to sell each for 0.1$ (or equialent in another fiat currency) and lets say I'm ready to exchange it on any liquid crypto (multiple tickers by my select).

Right now if I want to place such order in multiple markets (for example BCH, LTC, RVN and DOGE) I have to multiple amount of RICK I'm selling on 0.1$, then divide on USD price of BCH and place order, then divide on USD price of LTC and place order and so on (same with canceling - I'll need to click a lot)

So we can just create "multi-orders" instread - I set desired USD price, selecting multiple rel tickers, GUI using CEX prices endpoint for USD prices and then after user confirmation placing multiple orders on desired markets untied in GUI as single "multi-order".

Actually, it might be a first step for grandma-friendly liquidity providing - next steps might be order "refreshment" after desired preiod of time after USD prices re-fresh, also margin param to automagically setup orders with desired margin. Similar logic was implemented in mmbot_qt gui by @smk762

Just to visualize the problem it solves. I have a wish: sell 400 DEX for 18 USD each in liquid crypto, I've spent like a 10 minutes with calculator to place orders like on screenshot:

[smk762]

Being able to set against BTC value, USD value, or percentage over market would be great.

E.g. An "update interval" for maker orders, where every 60 sec -

1. Run my_orders to get existing pairs
2. Get updated API prices, and calculate volume adjustment (via set BTC/USD price or market price + %)
3. Run loop to place orders with updated volumes for existing pairs (with cancel_previous set to True)

The logic I used was to set each activated coin as either View, Buy only, Sell only, or Buy & Sell (via a dropdown next to the coin on the activation tab).

This returned a list of buy coins and a list of sell coins, which was used for the automated update order loop.

for buy_coin in buy_coins:
    for sell_coin in sell_coins:
        if buycoin != sell_coin:
            place_order(buy_coin, sell_coin)

I step further (which I did not yet implement) would be to allow for coins in the buy or sell lists to automatically update based on another external event, such as "If ZEC has dropped 5% in the last 24hrs, put it on the buy list".

[ca333]

I have a wish: sell 400 DEX for 18 USD each in liquid crypto - This works as long as your max balance for DEX is 400 if not you might well end up selling more than your initial wish. Thus this feature request requires a new AtomicDEX-API method setprice_multi, buy_multi, sell_multi since in case of more available user-funds a multi-order can lead to multiple orders being matched and executed. So mm2 has to tag this "multi-orders" and treat them as "one order" - in case of a match it must be ensured the others are cancelled automagically.

For the time being and to still have a "litemode liquidity multiplier" i propose a simple and yet comfortable and time-saving feature in the order/swap view which matches with elements of this feature request:

(1) user is able to activate "Multi-Order" slider - this feature shall only function with MAX balance swaps for now.
(2) swap menu unfolds and shows a scroll list with additional assets for order creation - each asset item shall show price per base coin and base volume (amount user would receive) - in this order creation view actual swap price shall be calculated by AtomicDEX-PRO to match FIAT sell price per rel-asset of initial order - for user comfort.
(3) atomicDEX PRO now simply creates additional orders with equivalent rel-volume.

[tonymorony]

Thanks for thoughts/mockup @ca333 that looks great !

Just had discussion regards this feature (and such algotrading oriented things in general) with @artemii235 To make it reliable and consistent across all interfaces, test-covered and with additonal features such as auto-balancing (automatical adjusting after fiat prices of assets change) and etc. integration into API is needed (and as a first step fiat prices data integration into API) - it can be done after the stress test.

I think on this widget desired price input should be in fiat currency and then atomicdex pro automagically calculate amounts in different cryptos based on fiat/crypto rate (right now on Sell/Buy widget price input is in another crypto). So imo in case of multi-order selection top widget inputs should disable and bottom widget needs additional desired fiat price input field.

[ca333]

Thanks for thoughts/mockup @ca333 that looks great !

Just had discussion regards this feature (and such algotrading oriented things in general) with @artemii235 To make it reliable and consistent across all interfaces, test-covered and with additonal features such as auto-balancing (automatical adjusting after fiat prices of assets change) and etc. integration into API is needed (and as a first step fiat prices data integration into API) - it can be done after the stress test.

thanks, after stress-test is fine - we can use this simplified version for now. For API side multi-order feature a direct fiat price fetch integration (in DEX API) is actually not required. Things like price fetcher from centralized endpoints, et cetera fit more the GUI logic side - hopefully soon there will be super reliable and production-ready decentralized fiat price endpoints/oracles available for DEX API integration.
In this current situation I believe it is sufficient to have a setprice_multi(userpass, base, [orders]) on API where orders array element contains the actual trade params {rel, vol, price},...- such a multi-order orders array could contain N orders and DEX-API would "automagicancel" the other orders if one of them matches/goes beyond specific swap step. The rest should be handled by GUIs logic or command line interface user.

I think on this widget desired price input should be in fiat currency and then atomicdex pro automagically calculate amounts in different cryptos based on fiat/crypto rate (right now on Sell/Buy widget price input is in another crypto). So imo in case of multi-order selection top widget inputs should disable and

I envision it different and without fiat value input - the user can create the order just as usual. This first order we will call "parent-order" and the multi-orders we call "child-orders" - and the GUI is always aware of the actual fiat values unless user is selling an asset (with or without fiat-price endpoint) for another asset without fiat-price endpoint - this rule apply for parent and child-orders. And only in this specific cases we would require a manual volume input from the user since we don't know how much actual fiat value we receiving. In simple term it means whenever on the rel side (asset i want to buy/receive) we have no fiat-price information we require manual volume input by user.

bottom widget needs additional desired fiat price input field.

yes - but only for assets without a fiat price endpoint - e.g. for tokens like DEX it would be indeed mandatory to provide the base volume as outlined in the new updated mockup.

For other �rel� assets with valid fiat price endpoint we don't need any additional user-input exempt "yes/no".
In such case our user-journey for multi-order creation starts when user creates a new order as always and then sets the slider button active for additional order creation - and based on this first "parent-order" we/app will know how much (fiat value) the user wants to receive for his coins. In last step and end of user-journey this same fiat value is automagically (by GUI) applied to the other wanted orders to match same fiat-value on the rel side regardless of the asset.

[tonymorony]

initial version of describen feature implemented in #476