[bisq-network/bisq] Recurring offers to support dollar cost averaging (DCA) use cases (#5165)

Chris Beams notifications at github.com
Sun Feb 7 12:15:58 CET 2021


One of the things that makes it hard to recommend Bisq to newcomers is that there's no way to set up recurring, e.g. monthly bitcoin buys. This an area where centralized exchanges excel, and a number of newer services like Swan Bitcoin and River Financial are specializing in this so-called [dollar cost averaging](https://www.investopedia.com/terms/d/dollarcostaveraging.asp) or _DCA_ approach. Though it would be challenging for several reasons, I don't any fundamental reason why Bisq couldn't support this use case as well.

## The basic idea
Allow users to specify a _recurring buy offer_. They would indicate how often they want the offer to recur, and the amount of bitcoin they'd like to purchase, expressed in fiat, e.g. USD. For example:

- on the 1st of every month
- offer to buy 200 USD worth of BTC
- at 1% above market price

Assuming the offer gets taken, a new offer with the same details will be created on the 1st of the following month. If the offer does not get taken, no new offer will be created, and the old one will stick around until it gets taken. Policies could become configurable here, but we could start with something simple like this.

This could be implemented at the UI level in a minimal way with an option in the existing `Create Offer` screen to "make this offer recurring" and, if enabled, allow the user to enter their desired interval.

## Challenges

### Fee management
A naive approach to implementing this feature would sometimes result in users paying very high fees during a mempool spike. We would need to implement a policy to defer offer creation until the fee rate falls under a user-specified threshold. **This feature would be very useful even outside of the context of recurring offers.** In the `Create Offer` screen, we would see this implemented as something like an option to "Publish this offer when the fee rate is less than or equal to ___ sat/byte". (This could also be implemented as a global "Max transaction fee" setting in `Settings > General Preferences` next to the existing "Withdrawal transaction fee" setting.)

## Future directions
### Limit offers
Once we have the ability to defer offer publication as described above, we wouldn't be far off from more general support for [limit offers](https://www.investopedia.com/terms/b/buy-limit-order.asp). It's basically the same functionality, but instead of making offer publication conditional on the fee rate falling under a certain limit, this option would make offer publication conditional on the market price falling under a certain limit (and would disable the offer when the price rises back above that limit). 

### Recurring _orders_
Today, Bisq deals only in _offers_ to buy or sell, distinct from the idea of _orders_, because there is no centralized matching engine. However, if we implement recurring _offers_ as described above, it wouldn't be a big leap to extend that to a more general recurring _order_ that allows the user to say _"I want to buy X USD worth of BTC on the first of every month. I'll take an existing offer to sell if one exists that satisfies my requirements, and if a suitable offer doesn't exist, then please create an offer to buy on my behalf."_ In this way, it's like the user is "ordering" their Bisq node to buy a certain amount of bitcoin, whether than means taking or making an offer.

## Thoughts please

I'm sure there will be many other nuances to consider, but I in general I think DCA support would be very compelling. Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/discussions/5165
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210207/b02523ce/attachment.htm>


More information about the bisq-github mailing list