<p></p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/invertedbobb/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/invertedbobb">@invertedbobb</a><br>
I agree that the exchange rate risk adds more risks to either party (one lose, one wins).<br>
That is one reason why I tried to avoid to include BSQ in the calculation as we get another exchange rate and volatility risk with it.</p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/wiz/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/wiz">@wiz</a><br>
Why not use the victims themselves to make the reimbursement request? Adding another centralized, trusted (and bonded) role seems not necessary and should be avoided if there are other options IMO.</p>
<p>The volatility risk is considerable. BTC/USD moved from 3000 to 14 000 USD over the last year and in currently troubled times it could be even higher. BSQ/BTC had also a high volatility over the past 6 months. I think we should sketch out all the extreme scenarios and see how the model works in such situations. BSQ got into a deadly negative spiral recently (and luckily recovered now) and the refund agent made a quite big loss (maybe the main reason why he is leaving now) because of volatility risks (and his lack of accounting). So we should not underestimate that risk.</p>
<p>Using BTC itself could cause severe problems as well. If the total BTC amount of the loss is 30 BTC now but BTC goes up to 100K USD in 6 months (not unreasonable if USD will crash) Bisq will have a hard time to pay that as revenues in BTC will go down (users trade smaller amounts). If on the other hand BTC price crashes to 1000 USD because governments restrict exchanges to not get BTC as competitor for a dying USD (more reasonable scenario IMO) the victims get only a portion of their todays loss. As USD itself might become very volatile soon that would not be a good alternative as well.<br>
The only solution to volatility risk is to shorten time exposure. So if we reimburse it on one go but achieve a mechanism that the victims cannot sell it at once and therefore crash the BSQ market we could avoid the risk. It still would add some risk to the victims as they are forced to wait to convert BSQ to BTC (and then maybe to XMR or USD). But I think there is likely no perfect solution here.<br>
One alternative might be a "basket" of currencies and use that as kind of "stable" orientation value. But thats probably too complex and hard to find the right balances.</p>
<p>For doing the reimbursement on one go but avoid an instant sell-off there are 2 potential solutions:</p>
<ul>
<li>One special role (like your SRA) makes the reimbursement and then transfers each months a part of the BSQ to the victims. Downside: Trusted role, uncertain legal implications (he acts as custodial)</li>
<li>Maybe its possible to hack a reimbursement request where the output is locked and the address is the victims address. This would not need a code change to be rolled out, only one dev make that requests with the target address and lock. Not sure if its doable and adds some risk to the DAO.</li>
</ul>
<p>A middle ground could be that the reimbursement happens in 3 parts and after the BSQ is received the victim need to promise to lock up the BSQ as agreed. If he does not do it he will not be accepted for the remaining reimbursements. The last reimbursement will lack that "soft enforcement" power but then the max. damage from sell off is likely limited to 1 or 2 defaulting victims with 30% of their funds.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/206#issuecomment-612074621">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNSXPVKNAVF7GV2GSYTRL42EPANCNFSM4ME5WJXQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNUBQURUVZ2YQIHUT6DRL42EPA5CNFSM4ME5WJX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOER5YI7I.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/206#issuecomment-612074621",
"url": "https://github.com/bisq-network/proposals/issues/206#issuecomment-612074621",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>