Reversed Deposit

From Open Transactions
Revision as of 14:33, 23 May 2014 by Justusranvier (talk | contribs) (Initial page creation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

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.

Procedure

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.

Recoverable reversal

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.

Unrecoverable reversal

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.