diff options
| -rw-r--r-- | design-documents/013-peer-to-peer-payments.rst | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst index 9b1f2636..df0fc51b 100644 --- a/design-documents/013-peer-to-peer-payments.rst +++ b/design-documents/013-peer-to-peer-payments.rst @@ -55,6 +55,8 @@ Requirements high-performance in terms of CPU, bandwidth, latency, storage requirements, and the ability to levy fees on every operation that is costly for the exchange) need to be preserved. +* The system must handle the case where a customer no longer intends to + use the KYCed account (due to disuse, death, or key compromise). @@ -125,6 +127,26 @@ Account creation and withdrawal from long polling acceleration. +Account deletion +---------------- + +1. The account owner can delete an account by signing a deletion message + with the account private key. +2. This basically resets the KYC data at the exchange, preventing further use of + the account. This is helpful in case a user is concerned about having + accidentally disclosed the account private key to a third party. +3. If funds remain in the account, an error message is generated instead. The + user can pass an extra override parameter to delete accounts even if + they still contain funds. +4. A related endpoint should exist for the exchange operator, possibly + using messages signed with the exchange offline key. This could be + useful in case customers died or are otherwise in need for manual + intervention that requires an account to be deleted. In this case, + remaining funds in the account should be wired to a bank account + designated in the message with the offline signature. The audit + report should contain a special note for all of these account deletions. + + Payment into an unknown account ------------------------------- |