Exchange-wide Budget Allocation Management

[nasaWelder]

Should there be an object to that manages balances of each currency, per exchange?

Cases:

1. I already have a bot using 50% of my BTC for XMR, --> budget-object would not let me use 55% for new LTC/BTC merkato.

2. if markato's are set up by relative budget allocation, then this hypothetical budget-object would monitor and rebalance absolute budets for each merkato on it's exchange. As in, merkato1 has produced a surplus .5 BTC, --> divvy it up to other merkatos according to original relative budget allocation on this exchange.

this is where OOP based bid/ask profiles make this possible

[livinginformation]

Things get really messy if we let different merkatos intermingle. I don't have the first clue how I would start trying to tackle that. For now, merkatos should have a defined BTC/alt reserve (that changes as the price moves), not a % reference to held balances.

[nasaWelder]

absolutes might break rebooting

hypothetically what about this:

(tux_budget_object) ... def update_allocations(self): ____for crypto in self.possible_coins: ____this_balance = self.get_balances(crypto) # API call to exchange ____for bot in self.active_bots: ____if bot.coin == crypto: ____bot.ask_budget = this_balance (bot.relative_ask_budget / 100.0) ____elif bot.base == crypto: ____bot.bid_budget = this_balance (bot.relative_bid_budget / 100.0)

[nasaWelder]

@livinginformation with absolute balances, (GUI) User will most likely not know their balance on startup (or reboot)

So, what about change the merkato init to only accept private keys and coin pair, and grab balances.

Then to add MM params, use the already stubbed modify_settings method.

This would allow a "login" step to the GUI where keys are checked, then user is shown balance when deciding budget allocation.

[livinginformation]

Im still not really seeing the issue, on reboot there are still orders on the books that can be tallied up to get the outstanding balance, and a marker to the last known trade executed, which lets you see trades that occurred since it was last run.

[livinginformation]

Ill be on Discord later today, perhaps you and @15chrjef (and @evdc if he isn't at work) can hop on with me and talk structure.

[nasaWelder]

What time-ish? I'm thinking of orders getting executed while bot is down so DB is stale.

[livinginformation]

Yeah, with a marker of the last order executed stored in the db, the bot can query all orders executed since it was shut down. There's no issues with a stale db that I can see.

I'll hop on within 15 minutes, and probably be in and out all day. Should be able to get to a computer with 30 minutes notice if I'm not around.

[livinginformation]

I'm on now, will be for a while.

[livinginformation]

Coming back to this issue now that the structure is a bit more fleshed out.

When a new Merkato object is initialized with a particular budget, we need to query all existing merkatos to make sure that the sum of all budgets (including the new one) do not exceed the user's held balance. If the sum is less than the balance, allow the new Merkato to be created. That functionality, once implemented, should let this issue be closed.

Note: I am ignoring the situation that a user withdraws from the exchange during active operation, causing their available balance to contradict their allocated budgets. We still need to edgecase that (or just tell the user that if they do that without using internal functions, the behavior is undefined)

[livinginformation]

@15chrjef is this done with reserves implemented, or do we have more to do?