The code which manages exchange datastore interactions is split into a set of useful interfaces:
SettlementEngine has two methods. One method checks whether or not a settlement execution could take place if it were executed (think of this as "can we credit this user X of an asset"). The second method actually executes the settlement execution(s).
AuctionEngine is the matching engine for auction orders. It has a place method, a cancel method, and a match method. The match method takes an auction ID as input, since orders cannot be matched cross-auction. This matches according to a clearing price based auction matching algorithm.
LimitEngine is the matching engine for limit orders. It has a place method, a cancel method, and a match method. This matches according to a price-time priority auction matching algorithm.
AuctionOrderbook gets updated by the auction matching engine, and is viewable by the user. This also has other methods that may be useful, for example methods to get orders by ID, pubkey, or auction.
LimitOrderbook is very similar to AuctionOrderbook except it does not have methods dependent on a specific auction, since limit orderbooks do not have auctions.
PuzzleStore is a simple store for storing timelock puzzles, as well as marking specific timelock puzzles to commit to or match.
DepositStore stores the mapping from pubkey to deposit address. This also keeps track of pending deposits. Pending deposits do not have a fixed number of confirmations, and can be set arbitrarily.
- SettlementEngine
- cxdbsql
- cxdbmemory
- cxdbredis
- AuctionEngine
- cxdbsql
- cxdbemory (partial)
- cxdbredis
- LimitEngine
- cxdbsql
- cxdbmemory
- cxdbredis
- AuctionOrderbook
- cxdbsql
- cxdbmemory
- cxdbredis
- LimitOrderbook
- cxdbsql
- cxdbmemory
- cxdbredis
- PuzzleStore
- cxdbsql
- cxdbmemory
- cxdbredis
- DepositStore
- cxdbsql
- cxdbmemory
- cxdbredis
Some old code still exists in cxdbmemory.
The issues related to refactoring cxdb are #16.