decred / dcrdex

The Decred Decentralized Exchange (DEX), powered by atomic-swaps.
Other
186 stars 92 forks source link

Market maker inventory management #2301

Closed martonp closed 11 months ago

martonp commented 1 year ago

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 asReserveFundsFor(id string, amt uint64) where the id would is the id of bot. Then FundOrder 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.

martonp commented 1 year ago

I'm working on this.

chappjc commented 1 year ago

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.

chappjc commented 1 year ago

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

martonp commented 1 year ago

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.