Proposal for One Cancels the Other Offer Cloning in Haveno [3 XMR]

[apemithrandir]

I made a similar proposal for Bisq which was implemented:

• Bisq Proposal OCO
• Bisq Proposal
• Bisq PR
• Bisq Wiki
• Bisq UI/UX

This was proposed on Haveno already here but I don't think it was given justice.

Proposal Outline

Short Version

If I am a maker on Haveno the biggest restriction to me posting multiple offers is the escrow requirement for each offer. Supposing I have access to 3 different currencies and 2 different payment methods for each currency. then if I wanted to create a buy offer for each of these I would have to escrow a minimum of 15% deposit + fees for each of the 6 offers. If I am a seller this is even more restrictive as I will have to escrow a minimum of 115% deposit + fees for each of the 6 offers.

I would like to propose a solution to this problem whereby you would clone an existing maker offer as many times as you would like (within some spam limit) and create special one-cancels the other maker offers under additional payment methods and/or currency pairs.

Long Version

Heavily borrowed from here

Trades on Haveno currently requires each offer to be associated with one payment method and one currency pair using a single reserved amount of XMR. This is a limiting factor to liquidity. A trader wishing to place multiple buy (or sell) offers of the same amount across multiple payment methods or currency pairs, needs to create multiple offers and commit new reserved amounts of XMR for escrow each time.

Displayed Liquidity on Haveno would be increased if an offer for a specific amount of XMR could reuse the same escrow amount to make offers across multiple markets / payment methods.

Increasing Displayed Liquidity

Allowing the cloning of an existing maker offer to other payment methods and currency pairs, allows for multiple ways for traders to take the offer. This would increase perceived liquidity for any takers in Haveno.

Currently in Haveno Alice can make an offer to sell 2 XMR with a 2.3 XMR security deposit on ONE market using ONE payment method. This adds 2 XMR to the displayed liquidity on ONE market.

This proposal would allow Alice to make an offer to sell 2 XMR with a 2.3 XMR security deposit and then clone that maker offer on MULTIPLE markets with MULTIPLE payment methods. This would add a displayed liquidity of 2 XMR to MULTIPLE payment methods on MULTIPLE markets. As each maker offer can still only be taken the once the actual liquidity (XMR available for trade) would remain unchanged.

The limit to the above would only be the number of available payment methods and the number of compatible markets (plus some predetermined spam limit).

This would have the potential to dramatically increase the displayed liquidity of Haveno across payment types and currencies.

Liquidity Definitions

Let us define two terms which post proposal will now differ.

• Actual Liquidity: Amount of XMR on offer as calculated from the reserved XMR in makers offers. This is easily calculable by the platform at any given moment. For buyer offers it would be the sum of reserved amount divided by deposit percentage. For seller offers it would be the sum of the reserved amount divided by 1 plus the deposit percentage.
• Displayed Liquidity: The sum of the amount of XMR shown to be available on each market. Should this proposal be implemented, perceived liquidity would be greater than Actual liquidity by the sum of the number of cloned offers, and will always be greater than or equal to Actual Liquidity.

Example:

Alice is based in Switzerland she can now sell 2 XMR using the following markets / payment methods:

CHF; National Bank Transfer [Bank 1], National Bank Transfer [Bank 2], Revolut, TransferWise
GBP; Faster Payments, Revolut, TransferWise
EUR; SEPA [Bank 1], SEPA [Bank 2], SEPA Instant [Bank 1], SEPA Instant [Bank 2], Revolut, TransferWise
USD; National bank transfer, Revolut

Alice could clone an offer in every single available market on Revolut and TransferWise

Using this strategy Alice could turn her one offer appear anywhere up to 30 times without much effort.

How can this be achieved

This can be achieved though allowing traders with an existing offer to right-click and clone that offer. The cloning of the offer will bring up a create offer screen where they can then modify the payment method and currency. They will also still be able to control deviation from market price for each offer independently.

I will make a few points of clarity in addition:

• There should be a shared on-chain escrow transactions for all cloned offers.
• This escrow tx is created when an initial offer is made.
• This implies each offer has the same deposit % and bitcoin amount to trade.
• These offers will thus share the on-chain escrow amount.
• When one cloned offer is taken all others will disappear.

A UI/UX description here

Technical Notes

I am not qualified to implement this proposal, and this proposal will require feedback from technically minded individuals in the community.

Much of the coding has already been done in the Bisq implementation but I don't know what differences exist in Haveno vs Bisq for the parts of the UI/UX and messaging protocols that this feature would interact with.

From the Bisq discussion on there were several technical comments made the Bisq devs which may be relevant:

• Comment 1
• Comment 2

Anyone seeking to implement this for Haveno should read through all the relevant comments in the Bisq discussion as well as the Bisq PR or simply the current Bisq codebase.

Further Motivations

I am proposing this because when this was implemented in Bisq it was perceived as a good feature to help bootstrap liquidity in smaller markets/less popular payment methods. Bisq has gotten feedback from users of this feature that it has allowed them to get filled on maker offers at both better price levels and also with lower wait times.

As Haveno currently has roughly 10% of the volume of Bisq, the need for features which increase displayed liquidity is even more important than it was on Bisq when this feature was implemented.
Nostr post on Heveno Volumes

In the discussion here, several respected community members voiced concerns about the increase in displayed liquidity vs actual liquidity (which they disparagingly called fractional reserve offers). Let me explain further some motivations for this feature.

Example:
I want to sell 5 XMR with 15% deposit, this requires 5.75 XMR to be locked up. Now if I have the ability to sell via a total of 10 different payment method across multiple currencies. Without this feature in place, I have to make a choice.
Choice 1:
I have plenty of XMR and I lock up 57.5 XMR which is 5.75 XMR each across every payment method I have. Then I have to closely monitor all my offers and the second one of them gets filled, manually cancel all the other 9, otherwise I will end up selling more than my desired quantity of 5 XMR. This in affect has the same impact as our OCO cloned offers, except that the trader has to manually implement the logic to get the desired outcome. Also when trade fees eventually get implemented I will have to forgo 9x the trade fee when I cancel the other 9 offers.
Choice 2:
I don't have a large amount of XMR at my disposal. I look at the methods and markets available to me and select the most liquid market+payment method, to maximize the probability of getting filled. This has the effect of concentrating liquidity in the already liquid markets.

A somewhat related concern to fractional reserve offers is the concern over fake liquidity in the order book. The idea being that allowing OCO offers generates a false sense of the order book liquidity, due to having orders that can never possibly trade simultaneously. This idea might have merit, but the above example should illustrate that the addition of this feature does not in fact create fake liquidity in practice.

In Choice 1 from the above example, the trader will cancel all the other 9 offers manually once one get fills, so the other 9 offers, while completely reserved are not desired to trade simultaneously.

In Choice 2 we see that we actually end up with a worse reflection of what the trade desires to do, since they would gladly trade through any of their available payment methods but lack the funds to enter all 10 offers.

In general order books will always include fake liquidity, this is already the case with any offers which include the optional trigger prices which turn off the offer once the price breaches a certain level. Also anyone can already cancel any offer in the book at anytime, is this also fake liquidity?

Bounty

I am also willing to put my money where my mouth is and offer a 3 XMR bounty for this feature getting implemented in Haveno. Though I want to stipulate a 12 month expiration on this bounty (12 months from the date of this proposal). If anyone else also sees the value in this proposal, I would encourage them to add to this bounty (@HardenedSteel).

[github-actions]

There is a bounty on this issue. The amount is in the title. The reward will be awarded to the first person or group of people whose solution is accepted and merged.

In some cases, we may assign the issue to specific contributors. We expect contributors to provide a PR in a reasonable time frame or, in case of an extensive work, updates on their progress. We will unassign the issue if we feel the assignee is not responsive or has abandoned the task.

Read the full conditions and details of our bounty system.

[woodser]

There should be a shared on-chain escrow transactions for all cloned offers.

This would be adapted to Haveno which does not create an on-chain transaction until the offer is taken.

Until the offer is taken, funds are reserved locally in the user's wallet. The network can observe if the reserved funds are spent by checking its key images. Cloned offers can be automatically disabled when any of the key images are spent for any of the offers.

[woodser]

I'm looking into this and experimenting with porting the work over from Bisq, adapted to Haveno.