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.
All members of the voting pool have a strong incentive to enforce the
Funds Available Policy because if they do not a reversed deposit could cause all members to become insolvent. Audit servers can enforce the
Funds Available Policy by marking any server’s audit which credits too many early deposits as degraded.
However as mentioned above, the risk of a reversal is still greater than zero. Assuming the
Funds Available Policy 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.
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
degraded and remains in this state until the service makes the appropriate transaction to balance the ledger.
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.
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
compromised since the pool is no longer provably solvent.
Possible manual recovery steps
- 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.
- An external source of Bitcoins could be sent to to the pool with a issuer account listed as the nym to be credited.