Closed martonp closed 11 months ago
I'm working on this.
This is one aspect I'm not entirely sure about. Generally a Core instance would have a single consumer that can use all the funds core says it has in the wallets. So a different way to do this that would not bother the Core API would be to have helper accounting type that sits adjacent to the bots that the bots query before trying to fund an order (or send funds out to an external address like a CEX). EDIT: But a single bot is a better way to approach this as it isolates the bot concerns and minimizes the complexity at higher levels where it shouldn't be IMO.
So a different way to do this that would not bother the Core API would be to have helper accounting type that sits adjacent to the bots that the bots query before trying to fund an order (or send funds out to an external address like a CEX).
That is, if it's this really cannot be done a single bot. I've been uncomfortable with the idea of multiple bots running in one Core. I think a better approach would be a single bot running a hybrid (e.g. arb + mm) program. Related issue: https://github.com/decred/dcrdex/issues/2302
I'm working on the helper account type now.
I still see the need for some core/wallet changes, but nothing as invasive as I was proposing before. The issue with UTXO assets is that even if a bot places an order that requires less than the amount allocated to that bot, it may reserve more than is allocated to it. The idea I have for a solution is something along the lines of having Trade
accept multiple prices and quantities to trade on a single market, and then the wallet would fund them all in one shot. I don't mean sharing funding coins, but potentially a split tx would be done with multiple outputs, to fund each of the trades. If these outputs have a bit of a buffer, then price movements wouldn't cause the need for another split tx later on.
Market maker bots need to be able to reserve funds exclusively for their own use. In order to achieve this, wallets need to implement a function such as
ReserveFundsFor(id string, amt uint64)
where the id would is the id of bot. ThenFundOrder
needs to be updated to take the id.Also, when the bot makes a trade, the redeemed/refunded funds need to go back into the bot's reserves.