[bisq-network/proposals] Increase security deposits to avoid future trades and mediation. (#155)

chimp1984 notifications at github.com
Tue Dec 17 19:28:25 UTC 2019


## We have currently following values for the security deposits:

### For buyer (he can do the chargeback, so it is higher here - maker can define between the min-max):
Default: 5%
Min. 0.5% for Altcoin, 5% for Fiat
Max. 20% for Altcoin, 50% for Fiat
Absolute min. deposit in BTC: 0.001 BTC (currently 7 USD)

For Seller:
Fixed: 5%
Absolute min. deposit in BTC: 0.005 BTC (currently 33 USD)


### I would suggest to change to  following values:
For buyer:
Default: 20%
Min. 15% for Altcoin, 10% for Fiat
Max. 50% for Altcoin, 50% for Fiat
Absolute min. deposit in BTC: 0.003 BTC (currently 20 USD)

For Seller:
Fixed: 15%
Absolute min. deposit in BTC: 0.005 BTC (currently 33 USD)
    
I don't remember the motivation why Altcoin buyer deposits have been so much lower as fiat. I think volatility risk is higher with altcoins and should be reflected in the buyer sec. deposit.
A motivation to keep buyers deposit low was to not increase too much the problem that you need BTC to buy BTC. Another one for both buyer and seller was to not require too much BTC to make a small test trade to try out Bisq. But I think the problem of "future trades" and not responding traders is a bigger one than the risk to increase the burden to try out Bisq. Specially if you end up in dispute because the peer has not enough skin in the game to follow the trade protocol at such a "demo" trade the intended effect would be contrary.

I am not sure if the suggested changes are too radical and if we should make smaller iterations to see how much effect they have. But I fear market volatility is a major factor which will overload any of our decisions, so it might be if there is low volatility over the next months that we assume we are fine with a moderate increase, but once a higher volatility hits the market get ger overloaded with future trade disputes and with the refund agent that becomes risky for Bisq (BSQ volatility) and expensive. So maybe its better to play on the safe side and if we see that the higher requirements cause too much opposition we can lower it again.


I tested the changes and tested between old and new client version and all worked without backward compatibility issues. Still would require proper testing but changing those values seems to have no risk.        



-- 
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/proposals/issues/155#issuecomment-566712668
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191217/1d254d5a/attachment.html>


More information about the bisq-github mailing list