Clearing/Settlement Re-Hardcode/Generalization

[patrickdugan]

To change the hardcoing, we must change the contract id referenced in the settlement block for the VWAP/TWAP settlement pricing/interest rate data, this is around lines 2700 in tradelayer.cpp - make sure the path_elef used to build the M_File is built from the trade history of that contract (kind of the hard part) and change the hardcoding reference also in the Settlement_Fifo function at lines 269 and 273 in clearing.cpp. Additionally there is hardcoding at lines 759, 762, 763, 765 and 766. Finally we need to expand on the PNL_function on lines 838-841, include a flag for whether the contract in question involves the numerator or the denominator as a collateral currency. Right now it is using the 1/entry-1/exit logic for inverse-quoting, where the numerator is the collateral. If the collateral is the denominator, e.g. a BTC/USD oracle contract with a dollar coin as collateral, then the formula should involve simply entry - exit.

The confusing part is about the construction of path_elef. Basically is is meant to encapsulate trade data from block N to N+ S where S is the settlement period. Since we are erring on the side of having all settlements happen at the same block, it's simpler to grab the right trades perhaps. A generalized solution would construct or pull up a path vector of raw trades for contract id N through a function that returns the correct vector, and the function would go deeper to pull up the relevant trade data from LevelDB.

[patrickdugan]

Additionally, beyond the parts of clearing.cpp and the settlement block in the tx handler in tradelayer.cpp, up at the top of the settlement block we deal in the datastructure that fuels the settelement algo:

pt_ndatabase = new MatrixTLS(path_elef.size(), n_cols); MatrixTLS &ndatabase = *pt_ndatabase; MatrixTLS M_file(path_elef.size(), n_cols); fillingMatrix(M_file, ndatabase, path_elef); n_rows = size(M_file, 0);

It looks like we just need to add an index to LevelDB of path_elef vectors and pull them up here, the find where path_elef is created and have it pledge the vector to the associated index# in LevelDB. Investigating that now. n_cols can be constant because the protocol's conceptions are fixed as far as the number of data fields in a single trade.

[patrickdugan]

Lines 4147-4180 aprox. in TradeLayer.cpp, each trade that is recorded gets pushed into the path_elef vector as an edge-type data structure. Perhaps instead of path_elef being a global variable, we can pull up the relevant contractID for a given trade, query the DB with low latency, make a local variable called path_elef equal to that value, the trade's edges updates it, we go through again. Of course the cleanest way to do this, assuming the DB queries add lag, is to have the trade parsing loop through one contract at a time, build the path elef for that entity, then chuck it in. But it seems like we aren't architected for that and optimizing to reduce DB queries is another ticket (which can be left for the future). We can benchmark how bad the lag is to estimate the overheads.

RecordMatchedTrade is called on line 1057 or mdex.cpp and in the function relating to parsing instant contract trade transactions in tradelayer.cpp on line 5863.

Probably the easiest thing to do is reference the contract id (not the underlying collateral id) inside the RecordMatchedTrade function, have that pull up the relevant Path_elef for that contract, everything else flows as normal, write the modified Path_elef to the DB. Then when it gets loaded inside the settlement block, it'll be the right one.

[patrickdugan]

Closing this as the Lihki global vectors ostensibly include all trades which are collate by propertyid, now to QA/audit.