Difference between revisions of "Notary (voting pools)"

From Open Transactions
Jump to navigation Jump to search
(use new terminology, add section)
Line 13: Line 13:
 
The Notary is also responsible for passing [[PaymentRequests]] from the [[Auditor (voting pools)|Auditor]] to the customer, crediting customer balances after the successful receipt of a blockchain deposit, and passing withdrawal requests to the rest of the voting pool via the audit servers.
 
The Notary is also responsible for passing [[PaymentRequests]] from the [[Auditor (voting pools)|Auditor]] to the customer, crediting customer balances after the successful receipt of a blockchain deposit, and passing withdrawal requests to the rest of the voting pool via the audit servers.
  
The transaction server must maintain a permanent deposit database containing each PaymentRequest generated for that server and its associated status (number of blockchain confirmations and the OT receipt crediting the appropriate Nym with the deposit)
+
The Notary must maintain a permanent deposit database containing each PaymentRequest generated for that server and its associated status (number of blockchain confirmations and the OT receipt crediting the appropriate Nym with the deposit)
 +
 
 +
== Audit Stream ==
  
 
The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.
 
The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.
Line 21: Line 23:
 
# Update to an outbox
 
# Update to an outbox
 
# Update to an account balance file
 
# Update to an account balance file
# Update to a nym box file
+
# Update to a Nym box file
# All server replies to transaction requests.
+
# All Notary replies to transaction requests.
  
 
[[Category:Voting Pool Components]]
 
[[Category:Voting Pool Components]]

Revision as of 06:10, 8 October 2014

Introduction

When a Notary is operates as part of a voting pool, it additional requirements apply on top of its existing functionality.

Responsibilities

The Notary must keep track of all blockchain-denominated balances via OT receipts. In addition to the separate account(s) for each customer, the server must track a service account to hold the blockchain-denominated balance owned by the service itself.

If necessary, the server should also maintain an application account to hold the balance of any funds which are being manipulated by an external system.

For example, in the case of a high-frequency exchange, the application account would belong to the order matching engine. When a customer enters a trade, the exchange front-end will call the applicable OT functions to transfer the appropriate balance from the selling customer’s OT account to the application OT account, and also from the application account back to the the appropriate purchasing customer’s OT account. Any trade fees that the exchange earns would be sent to the service account as part of the transaction. This separation of application account, service account, and customer account, prevents the mingling of funds.

The Notary is also responsible for passing PaymentRequests from the Auditor to the customer, crediting customer balances after the successful receipt of a blockchain deposit, and passing withdrawal requests to the rest of the voting pool via the audit servers.

The Notary must maintain a permanent deposit database containing each PaymentRequest generated for that server and its associated status (number of blockchain confirmations and the OT receipt crediting the appropriate Nym with the deposit)

Audit Stream

The Notary must broadcast five types of messages in an indexed and hash-chained sequence which form an Audit Stream.

The five types of messages are:

  1. Update to an inbox
  2. Update to an outbox
  3. Update to an account balance file
  4. Update to a Nym box file
  5. All Notary replies to transaction requests.