[bisq-network/proposals] "One Cancels Other (OCO)" option to reduce reserved BTC requirements (Issue #370)

Mon Mar 14 03:47:21 CET 2022

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://bisq.wiki/Proposals)._

This proposal is a follow on from:
- #201 
- #288 

### Background

Bisq operates as a highly fragmented market in terms of liquidity. You have many currency pairs and within each currency pair you have many different payment methods. None of these offers are fungible or linked in any way. If a liquidity provider on Bisq wants to provide maximum liquidity, they will want to be able to post buy and sell offers, across all combinations of currency pairs and payment methods they have enabled in their account.

Currently if a liquidity provider wanted to do that on Bisq, they would be required to reserve their deposit amount (+fees) for each and every combination of currency and payment method in an additive fashion. This incentivises only putting offers on the most popular currency and payment methods, so you can trade quickly and re-deploy capital. If you put offers in less popular currency and payment methods, your capital will be tied up for extended periods, and unable to be re-deployed to provide liquidity in the more active markets.

I would like to propose a way to link offers via a "One Cancels Other (OCO)" option to reduce required Reserved BTC, and reduce the penalty for posting liquidity in less active markets.

### Description

The initial version I would like to propose would be an advanced setting in the preferences page "Make all offers OCO":
![image](https://user-images.githubusercontent.com/99969638/158021022-87215705-d005-4cde-8d3e-3762bbdd39c3.png)

If an advanced user enables this feature, then all subsequent offers would be linked such that, if one of them traded, all of the rest of them would automatically cancel. This would allow the sharing of fee & reserve requirements of these offers. Additional fees and reserves would only be required if the new offer exceeded the maximum fee and reserves of all the previous offers.

This should not require any major change to the UI and would be presented as an advanced feature. With this feature, we are assuming the user is educated enough to understand the effects of shared offers disappearing when one is taken.

### Further Iterations

This first version is a blunt instrument. Further iterations should consider the ability to create offer groups, as opposed to forcing all offers to become OCO. The most basic group would be to group all buy offers together, and all sell offers together, separately. Then when you got taken on a buy offer, your sell offer would not immediately cancel (and vice versa).

The next iteration would be to introduce general grouping. This would assign a custom group label per offer in the offer creation page. Re-using that label on subsequent offers would link the offers together with each other, and share the fee and reserve requirements of these offers.

If you introduce custom labelling in the offer creation page, then you should remove the OCO setting in the preferences page, as this might add confusion to the process. The default behaviour should be an empty label which should result in "OCO off" behaviour.

### Notes on Implementation

I am not familiar with the codebase of Bisq and have only recently started using the application, so I will have to depend on the established community members to comment on the implementation of this proposal. I would be more than happy to work with the team in any testing that might be required.

### Notes on Altcoins

The above proposal was written from the perspective of Fiat/BTC markets, but the scope of it is general enough in my opinion to also apply to Altcoin markets. I lack any familiarity with the Altcoin markets though, so I would defer to other community members with experience in these markets to comment.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/370
You are receiving this because you are subscribed to this thread.

Message ID: <bisq-network/proposals/issues/370 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20220313/722ebd05/attachment.htm>