http://opentransactions.org/wiki/index.php?action=history&feed=atom&title=Reversed_DepositReversed Deposit - Revision history2026-05-06T00:03:33ZRevision history for this page on the wikiMediaWiki 1.32.2http://opentransactions.org/wiki/index.php?title=Reversed_Deposit&diff=2087&oldid=prevJustusranvier: Initial page creation2014-05-23T14:33:48Z<p>Initial page creation</p>
<p><b>New page</b></p><div>==Introduction==<br />
<br />
Although careful risk management can reduce the risk of a reversed deposit to extremely low levels, it’s never possible to reduce the risk to exactly zero.<br />
<br />
==Procedure==<br />
<br />
All members of the voting pool have a strong incentive to enforce the <code>[[Funds Available Policy (voting pools)|Funds Available Policy]]</code> because if they do not a reversed deposit could cause all members to become insolvent. [[Audit Server (voting pools)|Audit servers]] can enforce the <code>Funds Available Policy</code> by marking any server’s audit which credits too many early deposits as [[Auditing (voting pools)|degraded]].<br />
<br />
===Recoverable reversal===<br />
<br />
However as mentioned above, the risk of a reversal is still greater than zero. Assuming the <code>Funds Available Policy</code> is enforced, the service which experiences a reversal will have sufficient bitcoins to cover the loss without becoming insolvent. In this case, the service must transfer a portion of their balance from the [[service account]] to the [[issuer account]].<br />
<br />
At the moment any audit server detects the reversal of a deposit which has already been credited to a customer, the audit for the affected server is marked as <code>degraded</code> and remains in this state until the service makes the appropriate transaction to balance the ledger.<br />
<br />
===Unrecoverable reversal===<br />
<br />
There is an even lower non-zero probability that even if the pool does everything correctly, a deposit could be reversed after 100 confirmations that exceeds the amount which a single service can cover from their own funds. There is no automatic way to recover from this situation and it may represent a terminal event for the pool.<br />
<br />
In any case where a blockchain deposit has been reversed and the service account is not capable of covering the loss, the audit status of every server in the pool must be marked as <code>compromised</code> since the pool is no longer provably solvent. <br />
<br />
====Possible manual recovery steps====<br />
<br />
*It may be possible for the other servers in the pool to help cover the loss, in which case they must send bitcoins from their own service accounts to the issuer account.<br />
<br />
*An external source of Bitcoins could be sent to to the pool with a issuer account listed as the nym to be credited.<br />
<br />
[[Category:Type 1 events (voting pools)]]</div>Justusranvier